Public-draft deployment runbook

Runbook ID: LL-FDE-OPS-RUN-001
Target: existing Netlify site 21114b18-5610-49bd-bd52-6d4a62b0c226
Origin: https://fdebenchmark.org (canonical since 2026-09-03; benchmark.lockedinlabs.ai and every other benchmark domain redirect here permanently)
Authorized posture: indexable v0.1 Public Draft; official scoring disabled

0. Delivery credential

The deploy workflow authenticates with a Netlify personal access token held as the NETLIFY_AUTH_TOKEN secret on the production-draft GitHub environment (and on assessment-preview for the synthetic studio). If the step that publishes to Netlify exits immediately with an empty token, the secret is missing or expired: set it before rerunning, and never publish from a workstation to work around it. A manual command-line deploy attaches no commit to the Netlify record, which is why the deploys published before 2026-09-02 carry a null commit_ref and can only be tied to source through their deploy title.

1. Preconditions

The operator must confirm all of the following:

• the candidate is an exact 40-character commit reachable from origin/main;
• the GitHub production-draft environment has an authorized reviewer;
• the NETLIFY_AUTH_TOKEN environment secret is active and scoped to the recorded existing site;
• the draft source manifest was regenerated after the final source change;
• official numeric output, real-person intake, and unsupported claims remain disabled; public pages remain indexable with canonical metadata;
• any material release-document change has an accountable reviewer and recorded evidence.

If any condition is uncertain, hold the deployment. A successful local build does not resolve an authority failure.

2. Standard deployment

1. Open Actions → Deploy public draft → Run workflow.
2. Enter the exact candidate commit SHA.
3. Enter DEPLOY PUBLIC DRAFT exactly.
4. Select the protected production-draft environment review when prompted.
5. Observe the validate, build, deploy, and live-verification stages.
6. Retain the workflow URL and artifact name in the deployment record.

The workflow refuses a branch name, abbreviated SHA, commit outside main, changed confirmation phrase, stale source manifest, failed test, missing indexable canonical posture, missing token, or wrong live headers. Netlify receives the already-inspected dist bytes with --no-build; it cannot substitute a second provider-side build.

3. Evidence produced

The successful job retains for 90 days:

• deployment-evidence.json — exact built files and SHA-256 digests;
• netlify-deploy-receipt.json — provider response for the immutable deploy;
• live-verification.json — route, status, origin, indexability, and security-header results.

Review the Netlify receipt before sharing it outside the operating team. It must not contain credentials; the workflow never writes the auth token to a command argument or artifact.

4. Acceptance checks

The live verifier makes up to three bounded attempts after provider deployment and checks:

• HTTP 200 and same-origin resolution for /, /explorer, /pilot, /publications, /authority, and /method;
• HTML content type;
• indexable document metadata, exact canonical URLs, and no contradictory X-Robots-Tag noindex header;
• a canonical sitemap and plain-text crawler discovery files;
• Content Security Policy with default-src 'self' and no unsafe-eval;
• X-Frame-Options: DENY;
• X-Content-Type-Options: nosniff.

Rendered desktop/mobile and accessibility behavior is evaluated before deploy by the public-site suite. Live verification intentionally does not claim human accessibility validation.

5. Rollback

Rollback means restoring a previously verified public-draft build, not silently editing history.

1. Identify the last known-good 40-character commit and its successful deployment artifact.
2. Confirm the commit remains reachable from main and still preserves the current indexable canonical contract.
3. Rerun Deploy public draft for that commit using the same confirmation phrase and environment review.
4. Verify the 25 benchmark-only live routes and headers: landing, explorer, pilot, assessment workspace, research program, publications, authority, method paper, the build record, privacy, terms, security, license, the withdrawal record at /find-an-fde, the technical report at /report, the outcome architecture at /outcomes, the contact form, the learning hub, the AI skills check, and six learning guides. The named-author AI delivery field guide is checked separately, including its canonical article route. The verifier also confirms that /.well-known/security.txt and /robots.txt return text/plain rather than the application shell, that unknown general, learning-guide, and publication paths return real HTTP 404 responses, that every JavaScript chunk the entry page can load is free of the withdrawn staffing strings, and that no source map is served.
5. The workflow's own post-deploy check retries three times over roughly thirty seconds. A newly added route can still be propagating when those attempts run, so a failure at this step with a successful publish above it means rerun the verifier by hand before concluding anything is wrong: node fde-benchmark/scripts/verify-live-deployment.mjs https://benchmark.lockedinlabs.ai.
6. Record the failed commit, restored commit, incident reason, affected interval, and follow-up owner.

If GitHub Actions is unavailable, an authorized Netlify operator may restore the last verified immutable deploy from the existing site’s deploy history. Capture the provider deploy ID, then run:

node scripts/verify-live-deployment.mjs https://fdebenchmark.org --json

Do not create a new Netlify project, redirect the custom domain, or deploy uncommitted local bytes as a shortcut.

6. Post-deployment change control

Any byte change requires a new commit and fresh evidence. A material claim, status, license, author, reviewer, identifier, data, method, or scoring change also requires the relevant publication and governance gates; deployment approval alone cannot authorize it.