When the blocker moves upstream

For one client configuration — Poppi revenue HROAS — all four layers are wired:

Layer A: four taxonomy columns on the upstream job tables, a one-time backfill for existing promoted rows, and a write-path that tags every new run from Econ config.

Layer B: registry and audit schema, a TypeScript orchestrator (resolver, inputs builder, batch submit, manual trigger), and API gateway cut-over. Not the Java-on-MMMJob path I sketched early — those jobs have no direct Postgres access; the orchestrator needed to live where the database and Batch client already do.

Layer C: unchanged since Part 3 — five routines, one job, full-chain E2E proven in June.

Layer D: read-side merged and in production since late June — consolidated results endpoint, frontend reading latest/ instead of legacy bundle paths. Write-side (run button, status banner, "which models?" panel) still deferred.

That is a vertical slice, not fleet-wide rollout. But Layer B is real code in prod, not a design doc waiting on alignment. Part 4's gating call paid off: economists and data engineering signed off before I merged nine PRs across four repos.

I expected the hard part after Layer B merged to be trigger wiring or frontend polish. Instead I hit a promotion gap.

The resolver picks the latest client-facing run on main for each registered slot. Poppi's national MMM has a Meridian run in the batch location — correct artifacts, correct branch — but it is client_facing = false. The only promoted national row is a legacy-R run from March on a feature branch, which the resolver correctly excludes. Brand equity had the same shape: Meridian rows exist after a fresh rerun, but they need promote-and-tag before resolution can pick them. Geo already resolves cleanly.

This is not a seed bug or a backfill miss. The one-time backfill only tagged rows that were already promoted on main at backfill time. The Meridian runs landed afterward — or landed unpromoted — and the write-path tags future runs automatically; these pre-write-path rows need a one-time Econ action.

The durable engineering fix is a resolver Meridian gate (output_file_version >= 2) so legacy-R rows are skipped rather than selected-then-failed. That does not remove the need to promote the right run; it prevents silent selection of a run that cannot produce batch artifacts.

Part 4's risk table still applies. These rows are new or sharper post-ship:

The silent-degradation case is the one I worry about most. The orchestrator has a ≥2-slot floor — if two of three slots resolve, it proceeds. A dormant third slot produces a quietly wrong HROAS, not an error. The bidirectional coverage warning is designed but not built yet. Until it is, correctness depends on humans noticing a missing model in the output.

Part 4 asked whether rollback belongs in v1. I still don't have a production incident that justifies pin-to-known-good complexity. I'd ship the Meridian gate and coverage warning first and learn which failure actually happens.

"Done" for the Poppi vertical slice is a four-gate test plan, not a merge:

1. Prerequisites — taxonomy backfill and registry seed live in prod (confirmed).
2. Dry-run — invoke resolver + builder read-only; assert three slots resolve and every S3 key in the produced inputs.json exists. Catches resolution and path errors without burning 2.5 hours of compute.
3. Full submit — trigger orchestrator; compare structurally to the June 17 hand-built baseline (Part 3), not byte-exact — orchestrator points at newer Meridian batch models.
4. Frontend — results panels render off latest/.

Once Meridian rMMM and BE are promoted and tagged, gate 3 is a single manual POST to the trigger endpoint. The frontend button and app-toggle auto-run are not wired yet — deliberate; I want the coverage warning and Meridian gate landed before a burst of expensive batch jobs can fire unattended.

A capstone post will follow: that first orchestrator-driven run, structural diff against the June baseline, and an honest answer to "what did HROAS use on day X?" from the audit table — not from archaeology.

Gating Layer B in Part 4 was the right call — I'd make it again. What I mis-forecast was where cross-team risk would surface after the build. I assumed alignment would slow implementation; instead implementation finished and promotion became the gate. Separating solo-build velocity from cross-team schedule risk was correct instinct; I just attributed the cross-team half to the wrong layer.

The Part 3 comms lesson still applies: name what your metrics don't prove before the demo. "All four layers merged" reads as "push the button" to stakeholders who don't live in promotion flags and output_file_version. I'm saying it upfront this time — merged is not the same as first real run.