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:

1 · Engine facade first merge and deploy the engine; prove the /v1/extractions contract live merged 2026-07-16 live facade proof pending 2 · Isolated dev stack + canary dev bucket, credentials, engine API/worker/DB/Redis, Gallopify worker; run the private canary there SOURCE_AWS_* unset; buckets still shared 3 · Production dependencies equivalent infrastructure proven, without customer traffic not done 4 · Un-pause: default-active intake the pause is for incident response, never a rollout mechanism pause flag stuck on blocked on 1–3 5 · Prove, then observe 7 days full upload-to-portal proof; seven-day observation window not started
The locked activation order, with status as verified 2026-09-07.

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)

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.