The platform operating model
Ten rules for building an autonomous platform that stays durable as it grows.
By Andrew J. Pyle
I run an autonomous platform that ships across dozens of live sites with very little human input. It stays durable because it follows ten rules. Each rule is a checkable sentence, and each one was paid for by an incident.
These are not aspirations. A rule only counts once something mechanical makes it the default path. Intention does not scale. Enforcement does.
01CHECKABLE SENTENCES
Rules, not vibes
I run an autonomous platform that ships across dozens of live sites with very little human input. It stays durable because it follows ten rules, and every rule is written as a checkable sentence. If you cannot test whether a piece of work complies, the rule is written wrong.
Each rule was paid for by an incident. These are not aspirations. They are the scars of things that broke, turned into a standard so they do not break the same way twice.
A rule only counts as adopted once something mechanical makes it the default path. Intention does not scale. Enforcement does.
02THE OPERATING MODEL
The ten rules
| Rule | The checkable version |
|---|---|
| Map before you wire | Every app, model, endpoint, route, and job appears in one census. Unmapped is a finding, not a feature. |
| Measure before you build or remove | No build without stated evidence of need. No removal without a telemetry-backed dormancy window. |
| Propose, do not act | Agents rank, draft, and stage. The operator dispatches. An agent that mutates production is a documented exception. |
| Ratchet, do not target | Quality metrics enforce never-worse-than-baseline in CI, not a chase for an absolute number. |
| Deprecate before delete | Telemetry window, then a redirect or log-on-hit, then deletion a cycle later. Rollback is never the recovery plan. |
| Scheduled, not invoked | Anything that matters runs on a cadence, writes a heartbeat, and is watched by an independent dead-man. |
| Built means exercised | Done means observed firing in production. A green deploy is not an acceptance test. |
| Spines, not re-models | Each core entity has exactly one canonical model. New apps link into the spine, never re-model the concept. |
| Durable state is declared in code | State a deploy reconciles is changed at its source in git, never hand-flipped in the database. |
| The right way is the easy way | New modules come from a scaffold with the gates pre-wired. Where compliance needs willpower, expect decay. |
Ten rules is a lot to hold at once. Three of them do the most work, and each one came from a specific failure. They are worth a closer look.
03DONE MEANS FIRED IN PROD
Built means exercised
The most common failure mode on any platform is not a bug. It is a surface that shipped green and was never actually exercised. Wired-but-never-fired is the default outcome, not the edge case.
I learned this the expensive way: a ledger sat frozen for weeks while the monitoring said everything was fine, because nobody had confirmed the thing actually fired. So the Definition of Done now includes observing it fire in production. A same-session spot-check does not satisfy a scheduled re-check. Someone verifies it ran on the real path, on a real date.
04AGENTS RANK, HUMANS DISPATCH
Propose, do not act
Autonomous agents are good at ranking, drafting, and staging a batch of work. They are not trusted to mutate production state on their own. Any agent that does is an explicit, documented exception, not a default.
The reason is empirical. The one actuator I let act autonomously, with real money on the line, lost money on average and was turned off. Read-only proposers that stage work for a human GO have been the durable pattern. Every new agent copies that shape.
05NEVER ROLLBACK A DELETION
Deprecate before delete
Nothing user-facing or callable is removed in one step. First a telemetry window confirms it is really dormant. Then a deprecation change puts a redirect, a gone response, or a log-on-hit in its place. Deletion comes a cycle later.
Rollback of a deletion is never the recovery plan. On a platform where a deploy ships the whole backlog at once, a bad deletion rides out alongside everyone else's work and cannot be cleanly reverted. So you deprecate, watch, then delete.
06WRITTEN IS NOT ENFORCED
The part nobody talks about
A rule that lives only in a document is debt, not a standard. It feels like progress to write it down. It is not adopted until a CI gate, a template field, a scaffold, or a scheduled audit makes it the path of least resistance.
So the honest status of any rule is one of two states: enforced, or written-but-not-enforced. I track which is which, and a scheduled audit flags any rule that stays unenforced too long. The gap between a good idea and a durable one is the enforcement.
07NEXT STEPS
How to adopt it
- Write one rule as a checkable sentence. If you cannot test compliance, rewrite it.
- Attach one mechanism to it: a CI gate, a template field, or a scheduled audit.
- Name your spines. Pick the core entities that get exactly one canonical model.
- Add one ratchet that enforces never-worse-than-baseline, not an absolute target.
- Audit the gap. List which rules are enforced and which are still just written.