The runtime underneath, rebuildable from source.
Provisioning, containers, pipelines and the path from a commit to a running service. Built so an environment can be recreated from the repository rather than reconstructed from one person's memory, and so a bad release can be undone.
The situations this fits.
Usually arrives as a symptom rather than a request: deploys are frightening, or nobody can rebuild staging.
- Infrastructure that was clicked together once and is now understood by exactly one person.
- A deploy process frightening enough that releases get batched, which makes each one riskier than the last.
- An environment that cannot be recreated, so staging and production have quietly diverged.
- A product that is about to need more than a single box, where the next step should be decided rather than improvised.
- An incident history where the recurring theme is that nothing surfaced until a user reported it.
Where runtimes go wrong.
Infrastructure decays quietly. A console change made during an incident never makes it back into the configuration, and the gap between what is written down and what is running widens until the written version is fiction. The moment that matters is the one where you need to rebuild, and discover you cannot.
The second problem is that rollback is usually theoretical. A deploy path everybody trusts has almost always been tested forwards and never backwards, so the first genuine attempt to undo a release happens under pressure, at the worst possible time, by someone reading documentation they have never used.
The third is observability that reports health rather than truth. Dashboards showing that the process is running, while the queue behind it silently grew for six hours. What is worth instrumenting is the thing that would be wrong first, and that requires knowing how the system fails, not just that it is up.
The stack, and where this sits.
This category starts below the product and works down. What sits above it is named here too, so the boundary is visible rather than assumed.
A reference architecture, meaning the shape the work is designed to rather than a record of systems delivered. It names layers and responsibilities and never products: what runs at a given layer is a decision taken with you during scoping, not one taken here in advance.
- L5
Product surface
Coverage: OutsideThe product surface is built under product engineering. This category starts below it.
- L4
Services and APIs
Coverage: TouchedHow services are packaged, started, limited and released, rather than what they do.
- L3
Data and state
Coverage: TouchedWhere state lives, and whether an environment carrying it can be recreated from the repository instead of reconstructed from one person's memory.
- L2
Models and agents
Coverage: OutsideModel and agent work is AI and automation. Nothing here assumes a product has any.
- L1
Runtime and infrastructure
Coverage: OwnedProvisioning as code, container and runtime setup, pipelines, and the path from a commit to a running service with a rollback that has been exercised. This builds the platform and hands it over; it is not a support contract.
- L0
The layer underneath
Coverage: TouchedProcess behaviour, resource limits and failure modes read where they are decided, so the runtime matches the failures the product actually has rather than the ones that are expected.
What the marks mean
- Owned
- This category is accountable for the layer. It is designed, built and handed over inside the engagement.
- Touched
- The work reaches the layer as far as the build needs it to, and the depth here belongs to one of the other categories.
- Outside
- Deliberately not this category. The note on the rung says where the work goes instead.
What the engagement produces.
Infrastructure as an artifact you keep, not a configuration somebody remembers.
- Provisioning as code, so an environment is defined in the repository rather than in a console.
- Container and runtime setup, with the resource limits and failure behaviour made explicit.
- CI/CD pipelines: what runs on a commit, what gates a release, and what stops it.
- A rollout and rollback path, with the rollback exercised rather than assumed.
- Logging, metrics and observability aimed at the failures this system actually has.
- A deployment and rollback checklist, so the procedure survives the person who wrote it.
What you are no longer exposed to.
Every item is a failure that has a name because it is common.
- An environment nobody can rebuild, where the only copy of the configuration is the running system.
- Discovering during an incident that the rollback path was theoretical.
- A release process so risky it gets batched, compounding the risk it was avoiding.
- Silent failure: a system that reports healthy while the work behind it backs up.
- Infrastructure that lives in a vendor's account rather than yours, so access is something you have to request.
Work turned down.
The infrastructure asks that are usually the wrong shape.
- Ongoing 24/7 on-call or a managed-service arrangement. This builds the platform and hands it over; it is not a support contract.
- A cloud migration chosen for its own sake, with no problem it is solving. That gets scoped as a decision first, and often the answer is not to move.
- Kubernetes because it is expected. The runtime should match the failure modes the product actually has, and frequently something smaller is correct.
- A cost-reduction engagement where the target number is fixed before anyone has looked at what is running.
- Infrastructure work in an account we cannot be given properly scoped access to. Broad standing credentials are not a workaround.
What you are left holding.
Infrastructure is the easiest thing to leave in a state only its author understands, so this is where handover matters most.
Everything in your accounts
Infrastructure runs in accounts you own from the start. Nothing is hosted on our side and migrated later, so there is no cutover and no dependency on us continuing to exist.
The configuration in the repository
Provisioning as code means the environment has a definition your team can read, review and change. A rebuild is running the code, not reconstructing a memory.
A release procedure that has been run
The path from commit to production, the gates on it, and the exact steps to reverse a release, exercised during the engagement rather than documented and hoped for.
The conditions that trigger a rollback
Not just how to undo a release but when to: what to watch after a deploy, and what reading means stop. Judgment written down while it is fresh.
The evidence behind this.
The build, the document and the writing this page connects to.
- BuildA privilege-separated display managerThe lowest level a build reaches: independent parts made to boot as one system, and keep booting after an update.
- DocumentsSample artifactsThe deployment and rollback checklist, shown as the format with what it records and the risk it removes.
- ServiceSecurity and systems depthThe access boundaries and credential handling that sit alongside the runtime work.
Start with the constraint.
Describe what runs today and what you cannot currently rebuild. That is usually enough to scope the first stage.