Adoption

Ordo is not a framework to install. It is an order of operations, and it can be applied to one feature without touching anything else. Four starting points follow, cheapest first.

Path 1 — one bounded feature

The cheapest useful start, and the one that produces information fastest.

Pick a feature with real states — something that is created, changes hands, and reaches a terminal condition. Anything with a status column is a candidate.
Write down the states as names. Not the fields: the states. If you cannot name them without saying "and also", there is more than one state machine in there.
Write down the legal transitions between them. Include the ones that are terminal, and say so explicitly rather than leaving them absent.
Find every place that currently decides one of these rules. If there is more than one, that is the finding, and it is usually the thing worth fixing first.
Make the capability query real: one function that answers what is legal now, calling the same predicates the writes enforce. Point the interface at it.
Add one verification mechanism you do not already have. Not more of what you have.

Step four is where most of the value is, and it needs no new code at all.

The lifecycle implemented independently by three separate builds of the same requirements. Nothing leaves Superseded: every guard refuses it, and two acceptance criteria assert the refusal rather than relying on its absence from the code.

Path 2 — an existing system, gradually

No rewrite. Increase explicitness where a change is already happening.

Find the authorities

For each important rule, find the place that decides it. Where there are several, note it. You now have a map of where drift is possible, which is more useful than most architecture diagrams.

Name the states in place

Introduce a state where flags are currently combined, and derive the old flags from it rather than maintaining both. Two answers to one question is the thing to eliminate.

Check the boundaries

For each closed set of values, find where it is restated — persistence constraints, wire formats, validation lists, fixtures. Add an agreement check anywhere the copies are maintained by hand.

Add a differing mechanism

One integration test against a real boundary, or one adversarial review by someone who did not write the code. Both have found things in this evidence base that nothing else did.

1Tier Four — Host / External EffectsDatabase, network, HTTP, browser, filesystem, clock, queues, provider SDKs, persistence and other external I/O. Reports Succeeded, Failed, or Unknown.
2Tier Three — Application / Projection / OrchestrationCoordinates use cases, projections, requested effects, and boundary translation without becoming a second semantic authority.
3Tier Two — State Transition / Domain ExecutionOwns decisions, guards, policy, invariants, evidence and capability requirements, legal transitions, obligations, and interpretation of effect results.
4Tier One — Semantic ModelOwns what can be true: domain values, closed alternatives, state-specific data, evidence, coverage, capabilities, obligations, and uncertainty.

Dependencies point toward the semantic core. Ordo refines Tier One and Tier Two semantics without moving infrastructure inward. ROS observes engineering execution from outside this stack; it is not a fifth tier.

Path 3 — greenfield

The path with the most direct evidence behind it, because it is what the greenfield experiments actually did. Both builds went from a frozen requirements package to a verified implementation with all acceptance criteria traced, and both preserved every open question unresolved rather than guessing past it.

What those builds did, in order: read the requirements in full; record predictions before writing code and never revise them afterwards; model states and transitions before implementing; keep domain functions pure and effects as returned data; write tests from the requirement text rather than from implementation output; then verify with mechanisms that fail differently.

The step most likely to be skipped is the second. Both builds' preregistrations correctly identified the highest-risk area and were wrong about the specific failure inside it — which is only knowable because the predictions were written down first and not edited afterwards.

1RequirementsNumbered, with acceptance criteria that can each be traced to a test.
2Semantic modelThe domain's states, and what each one means.
3State and legal transitionsWhich changes the model permits, and from where.
4Capabilities and obligationsWhat an actor may do next, and what is still owed.
5ImplementationWritten at the semantic authority first, then propagated outward.
6Mechanical verificationCompiler, architecture checks, contract checks — everything a machine can refuse without running the program.
7Heterogeneous verificationBehavioural tests, integration against real boundaries, adversarial review — mechanisms whose blind spots differ from each other's.
8EvidenceWhat ran, what it found, and what it does not establish, recorded durably.

The construction order Ordo prescribes. Verification is not a phase at the end; it is several mechanisms with different sensitivities, applied in order of how early and how cheaply each can refuse a mistake.

Path 4 — constraining an agent

Ordo's mechanisms are useful to an AI engineering agent for a reason that has nothing to do with AI: they shrink the action space and make the consequences of a choice mechanical.

Ask the domain what is legal, then choose from that. An action absent from the answer is not one the agent can attempt badly.
Let the compiler enumerate propagation sites instead of searching for them — in the tiers the architecture actually guards, and only there.
Require evidence at completion: which mechanisms ran, what each found, what was not established, and what telemetry never existed.
Add an independent verification pass by an agent with no knowledge of the construction. In the one trial that did this, 0 of 5Independent-verification findings the builder's own checks had already caught of its findings were already covered by everything else that had run.

1Work item and acceptance criteriaThe requested change starts with explicit intent and conditions that can be checked.
2Semantic mapThe repository points to the semantic area and authority that own the decision.
3Declared feature contextState, transitions, contracts, effects, interfaces, and tests for the feature are locally discoverable.
4Mechanical feedback firstCompiler, architecture, contract, and structural checks expose required propagation before broad search.
5Expand only when evidence says context is insufficientSearch is an escalation mechanism, not the default navigation strategy.
6Heterogeneous verificationBehavioural, integration, and independent review cover failure classes the earlier mechanisms cannot.
7Record evidence and unresolved obligationsThe work leaves behind what ran, what was established, what remains open, and what the evidence does not prove.

Ordo treats repository context as something to route and verify, not something every engineer or agent should reconstruct by exploration.

And the limit. Constraint is not correctness. Both agents in the paired trial produced a change that passed every mechanical check on both architectures and did the wrong thing. Constraining what an agent can attempt does not constrain whether what it attempts is right.

What these paths do not establish

Adoption itself is unmeasured

No experiment on this site observed a team adopting Ordo, or compared a codebase before and after. The four paths are reasoned from what the experiments found about failure modes — each step exists because something upstream of it was measured going wrong — which is a sound basis for a starting point and not an evidenced adoption programme. Anyone presenting it as one is overstating what exists.

The mechanisms those steps install are a different matter. That a state you cannot write down cannot be written down is a property of the code, verifiable by reading it. That is why the steps are worth taking before anyone has measured your team taking them.

Portability beyond four languages

The evidence base covers F#, TypeScript, C# and JavaScript. Within it, the clearest language-related finding is not that one language is better: it is that the mechanisms available to catch a mistake differ sharply, and that 0Mistakes caught by the language of the JavaScript rebuild's mistakes were caught by the language, against 3 of 6C# mistakes caught by the compiler in the C# rebuild.

That says something about what has to substitute for a compiler in a dynamically typed codebase. It says nothing about Java, Go, Rust, Python, or any ecosystem not listed, and this site makes no claim about them.

What to measure if you try it

If you adopt any of this, the useful thing to record is not whether it felt better. It is: where defects were found and by which mechanism; how many places a semantic decision required touching; and how often two parts of the system disagreed about the same rule.

Define each measure before collecting it, and write down what it will not show at the same time. That discipline is itself the part of Ordo that this evidence base supports most strongly (CL-019).