Application map / Runbooks / Upload-pipeline activation

Upload-Pipeline Activation Runbook

What separates "the v2 reserve-study pipeline is merged and deployed" from "production customers can actually use it".

Not activated in production verified 2026-09-07

The code gate is met — application PRs #287 and #288 and engine PR #19 are merged, and the production app and engine hosts expose the v2 routes. Deployment activation is not met. Live blockers observed 2026-09-07:

UPLOAD_PIPELINE_V2_UPLOADS_PAUSED=true in production Doppler — the emergency brake is stuck on, so new presigns are rejected. §13.2 requires production to present active v2 intake by default.
Zero production traffic: no property has a v2 cutover timestamp; the documents table is empty.
Isolated source infrastructure is missing: SOURCE_AWS_* credentials are unset on both the backend and engine configs, and bucket names still match the shared, not-activation-ready inventory.
The engine still publishes its legacy split routes alongside the required /v1/extractions facade; retirement after disposition remains undone on the live surface.

Do not misread merged code as activation

Merged PRs prove application and dependency code completeness only. The pipeline's own completion gates split deliberately: the application gate (build, review, CI — met 2026-07-16) may not be papered over by shipping a disabled customer dropzone, and the deployment gate below is a separate, live-proof checklist. Flipping the pause flag alone would not satisfy activation while the infrastructure items still fail.

Activation criteria (all required)

Every acceptance scenario in the pipeline plan passes, including deployed-persona and failure-recovery scenarios.
The versioned source bucket, scoped IAM, Gallopify worker, isolated engine stack, secrets, migrations, and monitoring are active in each environment — per-environment isolation proven (dev credentials cannot read production objects).
The deployed engine exposes and passes the exact /v1/extractions facade contract, with Gallopify calling no split legacy routes.
A private dev/staging canary passes upload → ops approval → archive/keep/restore before the production release.
The production release presents active v2 intake to every authorized active property by default, with only the emergency pause available.
Legacy jobs have documented terminal dispositions, and the idempotent metadata-only history importer has reconciled its counts.
Seven days of v2 observation with no silent/stuck job, duplicate release, cross-environment access, unauthorized source access, or legacy application traffic.
Customer support holds the status/error/restore runbook and every named alert has been test-fired.
Remaining external legacy engine/ops credentials and source data are retired only after disposition and import requirements are satisfied.
The wiki pages describing the pipeline are updated with the final deployed evidence.

Locked activation order

Engine facade first: merge and deploy the engine, prove the facade contract live. merged 2026-07-16 — live facade proof still pending.
Provision and prove the isolated dev bucket, credentials, engine API/worker/DB/Redis, and Gallopify worker; run the private canary there.
Provision and prove equivalent production dependencies without customer traffic.
Only then release the default-active application behavior (un-pause) — the pause is for incident response, never a rollout mechanism.
Run the full upload-to-portal proof and start the seven-day observation window.

Semantics of the pause while this runbook is open: pause rejects new presigns (customer sees the paused state); history, existing upload completion, worker processing, review, archive, restore, and cleanup all continue. Recovery from any incident is pause plus forward fix — no state ever routes a document through the retired blind-insert pipeline.