How platform discipline proves code quality, and keeps it

Platform discipline proves code quality by turning each quality rule into a check that runs on every change and leaves a record. Instead of "we follow our standards", you can point at a specific pull request and show which standards applied, that each one was checked, what the change was allowed to touch, what it actually ran, and who approved it. And because the checks run on every change rather than once, the quality you had on day one is still there on day 300.

Why is quality on day one easy and day 300 hard?

Starting well is the easy part. A good service template gives a new repository sensible structure, a working pipeline, tests and a linter. On day one, everything matches the standard because everything was just copied from it.

Then the repository lives. Dependencies move. Someone disables a flaky test to unblock a release. The platform team improves the template, but the change never reaches repositories created from the old one. A deploy step gets edited by hand in one place and not the others. None of these is a big decision, and none is checked by anything, so by day 300 the repository matches the standard only where nobody has touched it.

A template sets quality once. Discipline holds it on every change. That is the whole difference, and it is why the rest of this post is about checks and records rather than better templates.

What does it mean to prove quality?

"Proving" sounds grand, but it reduces to a few questions you should be able to answer for any change, without asking the person who made it:

If any row is answered with "ask the team", that part of your quality bar is a claim, not evidence.

How does platform discipline produce that evidence?

Every component is checked against its golden path

In orun, each unit of code has a component.yaml that names its type, which is its golden path, and sets the parameters that path needs:

apiVersion: sourceplane.io/v1
kind: Component
metadata:
  name: web
spec:
  type: cloudflare-workers-assets-turbo
  owner: platform
  subscribe:
    environments:
      - name: stage
        profile: verify
        profileRules:
          - profile: deploy
            when:
              triggerRef: github-push-main
  parameters:
    nodeVersion: "22"
    buildCommand: pnpm exec turbo run build --filter=@app/web
    smokeCommand: curl -sf "${DEPLOYED_URL}/"

The golden path, a composition, carries a schema for those parameters. Every orun plan checks each component's merged parameters against that schema, and a mismatch fails the plan. A component cannot leave out a parameter its path requires, or give one a value of the wrong shape, because the plan will not compile.

The plan is an artefact a reviewer reads

Before anything runs, orun compiles the change into one plan: every job, step, input and dependency, across every component and environment the change touches. Identical inputs give an identical plan, so the plan works as a diff. A reviewer can see that a change to a shared package will rebuild three services and deploy two of them, in that order, before any of it happens. Review moves from "does this pipeline file look right?" to "is this what we meant to ship?"

Every change has a contract

A pull request in an Orunbase repository belongs to a task, and the task has a contract that lives in the repository beside the code:

# tasks/WEB-12.TaskContract.yaml
apiVersion: orun.io/v1
kind: TaskContract
metadata:
  name: WEB-12
  title: "Cache the pricing page at the edge"
spec:
  goal: "The pricing page is served from cache in stage and prod"
  affects:
    - "apps/web/**"
    - "tasks/**"
  doneWhen:
    - "A second request for /pricing/ is a cache hit on stage"
  gates: []

affects is the ceiling on what the change may touch. orun task check compares the diff with it, and the platform checks it again on the pull request. doneWhen says what done means in terms someone can verify. gates names the checks a merge must pass before the task counts as done; an explicit empty list means the merge alone finishes it.

One detail matters more than it looks: nobody writes a task's status. A task moves from ready to in_progress when a branch on its key is pushed, to in_review when its pull request opens, and to done when the pull request merges and the contract's gates have passed. Every step is an observation the platform made, not a field someone set. A task without a contract parks at in_review after its merge and never counts as done. "Done" is something the evidence says, not something a person types.

Lineage on every pull request

Orunbase runs an orun/compliance check on every pull request. It verifies that the change carries its lineage:

• Branch grammar. The branch is orun/<KEY>-<slug>, so the platform knows which task it belongs to.
• The trailer. Every commit carries Orun-Task: <KEY>.
• One task, one PR. A pull request that closes two tasks documents neither.
• The contract. The task's contract exists in the tree, and the diff stays inside its affects.
• The manifest. The pull request body carries a small machine-readable block naming the task, its epic, and the revisions of the playbooks the work followed.

A repository can run the check in advisory mode, where it reports, or required mode, where a pull request that breaks a rule cannot pass. Either way, a red result names the rule and the fix. It is a check on lineage, not on whether the code is good, which is the point: it makes sure every change can be traced, so the other evidence has something to attach to.

A record that cannot change quietly

orun keeps every catalog it resolved, every plan it compiled and every run it executed as content-addressed history: each record is named by the hash of its content. A record cannot be edited without its identity changing, so the history of what shipped is tamper-evident. On Orunbase, run history is kept per workspace and browsable in the console, so "what ran in production last Tuesday, from which commit, and which job failed?" is a lookup.

How does discipline stop quality eroding?

Evidence for one change is useful. What keeps quality from decaying is how the standards themselves change.

Golden paths upgrade as a version bump. Compositions ship as versioned packages, called Stacks, that each repository pins. When the platform team improves a golden path, every repository moves to it by changing one version and reviewing the plan diff that results. Improvements reach old repositories, which is exactly what copied templates never do.

Deprecation is a query, not a hunt. A golden path can be marked stable, beta or deprecated, and the catalog records it. "Which components still ride the deprecated path?" is answered by the catalog rather than by a week of searching repositories.

New work starts on the current standard. On Orunbase, a baseline builds a new product with the current golden paths, the CI and the environments already wired. Day one starts disciplined, so there is no gap to close later.

What platform discipline does not do

It is worth being clear about the edges.

• It does not judge whether your code is good. Tests, review and taste still matter. Discipline makes sure the checks you agreed on ran, on every change, and records what they found.
• Not every declaration is enforced. orun's standards page labels each standard as enforced, recorded or declared only. Some, such as approval policies written on an execution profile, are parsed and carried but not yet acted on. If a rule matters, check that it is in the enforced column, or use a mechanism that is.
• It does not replace your tools. Your linters, test runners, Terraform and wrangler still do the work. Discipline decides when they run and checks the result.

A checklist for quality you can show

1. Every component names a golden path, and its parameters are checked against that path's schema on every pull request.
2. Every change produces a plan a reviewer can read before it runs.
3. Every pull request belongs to a task with a contract: a goal, a ceiling on what it may touch, and what done means.
4. Branch names, commit trailers and the pull request manifest tie each change to its task, and a check verifies them.
5. Plans and runs are kept as history that cannot be edited quietly.
6. Golden paths are pinned by version, and upgrading one is a reviewed version bump.

In short

• A template sets quality on day one; only checks on every change keep it on day 300.
• Proving quality means answering, for any change, which standards applied, whether they were checked, what the change could touch, what ran and who approved it.
• Golden-path schemas, the compiled plan, task contracts, the compliance check and content-addressed history each answer one of those questions.
• Upgrading a golden path is a version bump every repository reviews, so improvements reach old code too.
• Be honest about which standards are enforced and which are only written down.

If you are new to the idea, start with what platform discipline is. If coding agents write a growing share of your code, read why agentic development needs platform discipline.