What is platform discipline? The standards your platform keeps

Platform discipline closes the gap between the standards a team writes down and the ones its platform actually checks. Here is what it looks like in practice, why platforms drift without it, and what that drift costs.

7 November 2026 · 7 min read · The Orunbase team

Platform discipline is the practice of turning a platform's standards into declarations that are checked on every change. A standard that lives in a wiki is a hope. A standard that fails a pull request when it is broken is a fact about your platform. Platform discipline is the work of moving standards from the first kind to the second, and keeping them there as the platform grows.

What is platform discipline?

Every engineering organisation has standards. Services have owners. Production deploys after staging. Terraform runs a pinned version. Secrets never sit in a config file. The question is not whether those standards exist, but where they live.

Most live in one of three places: a document, a template, or someone's head. All three share a weakness. Nothing happens when the standard is broken. The document is not read during a deploy, the template was copied months ago, and the person who knew is on holiday.

A disciplined platform keeps its standards somewhere a machine reads on every change:

The standard	Written down	Kept
Every service has an owner	A spreadsheet someone updates each quarter	Ownership read into the catalog from `component.yaml` and `CODEOWNERS`, so it changes when the code does
Use the approved Terraform version	A line in the onboarding guide	A parameter of the golden path, which its schema can restrict to approved versions, checked when the change is planned
Production deploys after staging	A comment at the top of a CI file	A promotion rule in the platform's intent, compiled into the plan as an edge production waits on
Secrets are never literal values	A security policy PDF	A secret slot that only accepts a `secret://` reference, so a pasted value fails the plan

The standards in the left column are the same as the ones on the right. The difference is that the right-hand column cannot quietly stop being true.

Why do platforms drift?

Drift is what happens to standards that are not kept. It rarely comes from carelessness. It comes from ordinary, reasonable decisions made one repository at a time.

Copy-paste starters. A team builds a good service template in March and every new service starts from it. In June the platform team improves the template: better health checks, a newer runtime. The services created in March, April and May never hear about it. A template is excellent on day one and silent from then on.

One-off CI files. Each repository carries its own pipeline, edited by hand. One team adds a cache step, another skips a test stage to get a hotfix out and never puts it back. After a year you have forty repositories with forty slightly different ideas of what "deploy" means.

Tribal knowledge. Some rules were never written anywhere. Staging has to go first because of a database migration that bit someone in 2024. The person who knows leaves, and the rule leaves with them.

Exceptions that never close. A service needed an older runtime for one release. The exception was meant to last a month. Nobody is sure whether it still applies, so nobody removes it.

None of these is a failure of character. They are what happens when the only thing holding a standard in place is people remembering it.

What does drift cost?

Drift is cheap to create and expensive to find. The cost shows up in places that rarely get traced back to it.

Onboarding. A new engineer learns the platform repository by repository, because each one is a little different. What should take a day of reading takes weeks of asking.
Incidents. When something breaks, the fix depends on which variant of the pipeline that service runs. The post-incident review often finds the standard existed. It just was not applied there.
Upgrades. Moving every service to a new runtime becomes a migration project: find the repositories, read each pipeline, open a pull request per repository, chase each team. The work grows with the number of copies, not the size of the change.
Simple questions. "Which services still use the old deployment path?" should be a query. In a drifted platform it is a spreadsheet and a week of messages.

Each of these is a tax on every change the team makes, paid quietly and indefinitely.

What are the practices of platform discipline?

Platform discipline is not one tool. It is a small set of practices that reinforce each other.

Golden paths as versioned contracts

A golden path is the supported way to build and ship one kind of thing: a web app, a worker, a Terraform module. In a disciplined platform it is not a template you copy but a contract each component names. In orun this contract is a composition: a schema for the parameters a component must set, and the jobs that build, check and release it. Compositions ship as versioned packages that every repository pins, so improving a golden path is a version bump each repository reviews, not a migration.

Standards checked on every pull request

A standard earns its place by failing a build. When a component's parameters do not match its golden path's schema, the plan fails. When a secret slot holds a literal value, the plan fails. Checking on every pull request means drift is caught when it is one line in one diff, not after it has spread.

One reviewable plan per change

Before anything runs, the change is compiled into a plan that lists every job, input and dependency it will run, across every component and environment it touches. The same inputs give the same plan, byte for byte. A reviewer can read what a change will do instead of inferring it from a pipeline file.

A record of what shipped

Every plan and every run is kept as content-addressed history: each record is named by the hash of its content, so it cannot change without the change showing. "What ran in production on Tuesday, and from which commit?" has an answer you can look up rather than reconstruct.

Ownership derived from the code

The service catalog is not a second set of files to maintain. It is derived from the same declarations the planner reads, so a component that ships is in the catalog by construction, and its owner, dependencies and deployments are always the current ones.

What platform discipline is not

It is easy to hear "discipline" and picture a committee. It is the opposite.

It is not more process. The point is to remove the manual checks and reminders that drift forces on people, by letting a machine do the checking.
It is not a portal. A portal helps people find things. Discipline is about what holds when they change things.
It is not a replacement for your tools. Terraform, wrangler and Helm keep doing the work. Discipline decides what runs, with which inputs, in which order, and checks that it matches the standard.
It is not all or nothing. You can keep one standard this week and add the next one later.

How do orun and Orunbase put it into practice?

orun is the open-source CLI at the core. Each unit of code gets a component.yaml that names its golden path, the environments it ships to and its parameters:

apiVersion: sourceplane.io/v1
kind: Component
metadata:
  name: web
spec:
  type: cloudflare-workers-assets-turbo
  owner: platform
  subscribe:
    environments:
      - name: stage
      - name: prod
  parameters:
    nodeVersion: "22"
    buildCommand: pnpm exec turbo run build --filter=@app/web

orun plan checks every component against its golden path and compiles the change into one plan, which then runs in the CI you already have. orun's documentation is candid about the limits: its standards page lists every standard you can declare and says which ones orun enforces today, which it only records in the plan, and which it carries but does not yet act on.

Orunbase is the hosted control plane around it. It keeps run history and the catalog per workspace, tracks work as tasks with contracts, and runs a compliance check on every pull request that verifies each change carries its lineage. It also serves the whole platform to coding agents over MCP, so an agent works from the same standards as your team. A baseline gives a new product all of this on its first day: the repository, the golden paths, the CI and the environments, already wired.

How to start

You do not need to adopt everything at once. A practical order:

Pick the standard that hurts most. Usually it is the one an incident review mentioned, or the one that makes upgrades slow.
Write it where a machine reads it. A parameter in a golden path schema, a promotion rule, a pinned version.
Check it on every pull request. If it does not fail a build, it is still a hope.
Make upgrades a version bump. Stop copying templates; pin a golden path and move it forward deliberately.
Let the catalog fall out of the code. Stop maintaining ownership by hand.
Repeat with the next standard.

In short

Platform discipline is keeping standards, not just writing them: every standard is a declaration a machine checks on every change.
Platforms drift through copied templates, hand-edited pipelines, unwritten rules and exceptions that never close.
Drift costs you in onboarding, incidents, upgrades and the simple questions nobody can answer quickly.
The practices are golden paths as versioned contracts, checks on every pull request, one reviewable plan per change, a record of what shipped, and ownership derived from the code.
Start with the standard that hurts most, and make it fail a build.

For how this turns quality into evidence you can show, read how platform discipline proves code quality. For why it matters more once coding agents write most of the code, read why agentic development needs platform discipline.