Golden Paths, Productized

Everything converges here

Watch what this training has quietly assembled: a routing contract (1.3), governed pipeline templates (M2), a wrapper library with inherited compliance (M3), release and test discipline (M4), evidence flowing per-run (M5). A golden path is these, composed: the paved road where a new team goes from intake to deployed-with-evidence without artisanal work. This lesson is the productization — and the two disciplines that separate platforms teams love from platforms teams route around.

Discipline one: narrow the v1

The reference platform’s scoping document has a pattern worth stealing verbatim in spirit: V1 is one archetype, one lane, one path — end to end. Not “the platform supports web apps, APIs, and data platforms across three assurance lanes” — that’s the roadmap. V1 is: the application-with-database archetype, in the standard lane, from intake through deployed starter with evidence flowing. (The same scoping document made one deliberate exclusion worth noting: data-platform archetypes got no push-button starter at all — guided customization only — because their designers judged that archetype too variable to template honestly.) Complete for one thing beats scaffolded for everything, because the first real consumer teaches you what the second version should be (the wrapper library’s wrap-at-consumption rule, at platform scale — and the portal ecosystem’s commonly-reported experience says the same: DIY-everything platform builds routinely run half a year or more before value, while narrow paved paths ship in weeks).

The codegen machinery Lesson 1.3 promised lands here: the routing contract is the source, and generation fans out —

10-field contract ──► starter pipeline (the right template family)
                  ──► IaC stack skeleton (the right wrappers, the right
                      env tree placement)
                  ──► handoff packet: who-provides-what, exit criteria
                  ──► the web catalog's entry (teams can SEE the paths)
      with a --check CI mode: regenerate and diff - if generated surfaces
      drifted from the contract source, FAIL. One source of truth,
      mechanically enforced (the same byte-equality trick every codegen
      system in this training uses).

And the 2026 twist the sources are just starting to encode: the scaffold provisions the AI context alongside the code — the CLAUDE.md/AGENTS.md, the MCP configuration, the context files from the AI curriculum’s scaffolding module — so a new service is born with its agent tooling configured to the platform’s conventions. A golden path that doesn’t pave the AI-assisted road is paving last year’s road.

Discipline two: productize the operating procedure

The deepest source finding (from a live platform’s wiki, superseding its own repo’s older docs — the fact that it superseded them is the lesson): as a platform matures, ad-hoc operations become productized procedures, and you can watch the pattern in the deltas:

BEFORE (repo runbook, v0)              AFTER (wiki operating model, v1)
"flip public access off after DNS   -> bootstrap→private cutover is an
 confirms" (operator remembers)        explicit TICKET-GATED PHASE with
                                       guardrails - "don't stay public
                                       because the first deploy worked"
operator files dependency tickets   -> tickets AUTO-GENERATED from a
 by hand, per their memory             manifest, by the platform team
two fixed reference paths           -> a LANE TAXONOMY with per-lane
                                       postures + a stated direction
(unstated)                          -> an OWNERSHIP BOUNDARY rule: for
                                       high-assurance lanes, the platform
                                       team owns bootstrap→lockdown; the
                                       product team can't operate the
                                       environment until lockdown completes

Each delta is the same move: a thing that lived in an operator’s judgment became a named, gated, owned step. That’s what “platform as product” means below the slogan — and note the direction of authority in the last row: for the highest-consequence lanes, the paved road isn’t just recommended, it’s the only road that exists until the safety gates close (the chokepoint principle from Zero Trust, as an onboarding workflow).

The artifact - Meridian's paved road, v1 scope document:
1. THE CUT: v1 = app-with-database, standard lane, end to end. Explicitly
   listed OUT: the other archetypes (roadmapped, dated), the high-assurance
   lane (its ownership-boundary rule drafted now, built later)
2. THE GENERATION: contract -> starter + IaC skeleton + handoff packet +
   catalog entry + AI context, with the --check drift gate in CI
3. THE PROCEDURE: the cutover gate (what must be true before a service
   leaves bootstrap), the auto-generated dependency tickets, and the
   ownership boundary per lane - each a named step with an owner
4. THE PRODUCT TRAPPINGS: the platform's own fleet-registry entry (owner,
   tier: critical), its docs generated not hand-maintained, and the
   feedback intake - because Lesson 6.2 is about to measure whether any
   of this works

Key takeaway

The golden path is this training composed: contract-driven generation of starters, IaC, handoffs, and AI context, drift-checked in CI — scoped to one ruthlessly-narrow, genuinely-complete v1, with operating procedures productized into named, gated, owned steps (and the highest-assurance lanes platform-owned until lockdown). Ship the narrow road; let consumption write the roadmap. Now: proving the road works, with numbers.