Most golden paths cover scaffold and build, stop before release and never mention retirement, so teams keep their own pipelines for the parts that actually hurt. This blueprint is the reference design: seven stages across the service, data and ML paths, what the platform owns at each, what the team keeps, and the interface between them.
The trap most platform teams walked into: pave service, data and ML in parallel because the data and ML leaders will not wait two quarters, then ship three half-paths that each cover scaffold and build, none of which reach release, rollback or retirement, leaving every team on its own pipeline for exactly the parts that hurt.
What the platform teams who get adoption do: pave the service path first for one workload type, end to end through all seven stages including retire, prove a three-year-old service with a hand-written pipeline can move onto it in under a week, and give data and ML their real requirements folded into the design plus a dated commitment rather than a lane of their own.
Most path documents list what the platform provides and stop there. This one names three things at every stage: what the platform owns, what the team keeps, and the interface between them. A manifest at the repo root. A declared runtime rather than a Dockerfile per team. An SLO the health gate can read. Where you cannot name the interface, platform and product argue about the boundary every sprint.
The path carries a version number and every service, pipeline and model records the version it runs on. That one field turns a vague migration into a count: how many on v1, how many on v2, how many on something nobody supports. Without it you cannot deprecate anything, because you cannot tell who breaks. Ship path changes like a public API, with a change log and a two-quarter window.
Leaving the path is allowed. Leaving it silently is not. Every exception records the stage left, the reason, the replacement, a named owner who now carries patching and on-call, and a review date next quarter. Six teams leaving at the same stage for the same reason is not six exceptions, it is a missing capability. Open exceptions per stage beats adoption percentage as a measure.
Stateless HTTP only, all seven stages including retire. Versioned generator, declared runtime, policy checks as code, one typed resource declaration, a canary behind a health gate, auto-instrumentation, and a decommission request that closes the cost line. Done when two teams ship on it without asking the platform team anything.
Take a three-year-old service with a hand-written pipeline and migrate it without a rewrite. More than a week and the path is greenfield only. Most workloads join at Provision or Release, never at Scaffold, so every stage has to stand alone. Done when half of tier-one services are on the path, counted from the inventory.
Contract first. Schema, column semantics, nullability, primary key, owner and freshness SLA in the repo, compiled into tests so a breaking change fails the build rather than a consumer's dashboard. Scaffold, build, verify and provision are reused. Done when one production dataset has a published contract and consumers depending on it.
Provenance on every training run: code commit, dataset version, feature contract version, hyperparameters, environment and artifact hash. An eval gate as a pipeline step with a threshold, not a review meeting. Cost per request tracked alongside latency. Done when one model has passed the gate and been rolled back once on purpose.
No, and it is the most common plan we are handed. It fails the same way every time: three half-paths covering scaffold and build, none of them reaching release or retirement, every team still running its own pipeline for the parts that hurt. Adoption stays near zero and the next budget round asks hard questions.
Because that is what a half-built platform does. A path that adds a hop without removing the ticket costs throughput and returns nothing. The stages that pay it back are provision, release and rollback, and those are precisely the ones most paths never reach. Depth on one path beats breadth across three.
No, and mandates backfire. Leaving is allowed, leaving silently is not. Every off-ramp records the stage left, the reason, the replacement, a named owner and a review date next quarter. Teams stay because upgrades arrive for free, not because a policy says they must. Open exceptions per stage become the platform roadmap.
Four to eight people. The first quarter is deliberately narrow on purpose: one workload type, stateless HTTP, all seven stages including the one nobody
builds. Widening before the shape is proven is what produces three half-paths. A smaller team can still run this, one quarter later at every step.
Heads of DevEx and platform leads who own the paved road. It assumes you have an internal platform of some kind, teams quietly working around it, and a budget round coming where you have to say which of the seven stages are paved, which are partial, and which are absent.
Drop your details and we'll send Only 5% Of Your Estate Is Greenfield. A Path For New Services Is A Demo. straight to your inbox - no spam, unsubscribe anytime.
Book a 30-minute golden path review (logiciel.io)
Download the blueprint