OrdoState-Directed Engineering · Echelon Foundry

Comparison

Ordo and conventional development

This comparison is built on what each approach makes visible to a machine — not on defect counts. We tried the defect-count comparison and it did not hold up, which is explained at the bottom of this page rather than omitted from it.

What each approach asks a human or an agent to infer

The operative difference, dimension by dimension
Dimension Conventional Ordo
What state a record is in Inferred by combining flags, nullable fields and status strings at each read site. Named. The state is the thing stored, not a consequence of other things stored.
Which changes are possible Any write the language permits. Illegal combinations are representable and must be defended against. Only declared transitions. Data belonging to one state is constructible only in that state.
What an actor may do next Usually re-derived in the interface, so the rule exists twice with nothing keeping the copies in step. Computed from the same predicates the transitions enforce. There is one copy.
Finding the change surface Exploration. Read until you are confident you have found every affected place. Routing. Repository map to semantic area, semantic area to the authority that decides the rule.
When a rename changes meaning Caught where the name appears. Silent where the value is a bare primitive passed positionally. Distinct nominal types mean the wrong value cannot be supplied without a compile error.
What a green build proves That it compiled. Independently measured not to establish merge-readiness. One signal among several chosen because their blind spots differ.
Architectural conformance Convention, review, and whoever remembers the rule. A check that runs. Dependency direction is verified rather than agreed.
Requirement coverage Believed, usually from test counts. Traced criterion by criterion to the test that covers it.
Unknown outcomes at a boundary Collapsed into success or failure, or thrown. A distinct state, with reconciliation as a declared operation.

Every row describes a property of the two approaches as built in our trials. Rows five, six, seven and eight are the ones with measurements behind them; the others are design descriptions you can verify by reading either codebase.

  1. 1Semantically complete state viewThe domain projects the smallest authoritative view in which no omitted fact could change legality, evidence requirements, coverage, capability applicability, obligations, policy, or transition outcome.
  2. 2EvidenceTyped evidence identifies what was observed, where it came from, when it was observed, and what it depends on.
  3. 3Scoped coverageEach contract-defined scope is Complete, Partial, or Unknown. Required non-Complete coverage refuses the decision before provider execution.
  4. 4Capabilities and obligationsHost-established semantic authority is supplied as capabilities; unresolved required work remains explicit as obligations.
  5. 5Legal choice spacePolicy, guards, state, evidence, coverage, capabilities, and obligations determine which outcomes are actually legal.
  6. 6Compute, bounded decide, refuse, or escalateDeterministic work stays deterministic. Judgment happens only inside the legal choice space. Missing prerequisites do not force an answer.
  7. 7Result, requested effects, and auditThe result carries the state identity and decision facts forward; external work is requested as data and observations are recorded for later verification.
A bounded Ordo decision is legal only after the domain has established the state being judged, the evidence and coverage supporting it, the authority already granted, and the choices that remain legal. The model or engineer selects inside that envelope; it does not create the envelope.

The same change, applied both ways

The unit of measure changes: recording becomes exact to the minute, and six-minute rounding moves to a derived billing view. This change was applied to the same domain in several implementations, which is why it is the most informative comparison available.

Conventional C#

Eight caught, fourteen silent

The compiler reported 8 of ~22Call sites the C# compiler reported on the unit change — direct member accesses. Roughly ~14Call sites where a rename silently changed meaning more passed duration as a bare positional integer, so the literal 10 silently went from meaning sixty minutes to meaning ten. Each had to be found by hand and its intent re-read. Two ended up correct 2Values that survived the change correct by coincidence. The build was clean throughout.

Conventional JavaScript

Nothing caught, program ran

0Mistakes caught by the language mistakes were caught by the language across the whole rebuild, and 0 of ~22Call sites the JavaScript language reported on the same change call sites were named on the unit change. The rename produced no errors, no warnings and no crashes. 8, from one root causeJavaScript test failures that caught the change instead did fail — a real safety net, the only one available, and one that worked because those assertions compare numbers rather than reference the renamed property.

Ordo, C#

Every site, one build

Ripple surfaced all of themRipple sites found by the compiler rather than by searching, with exact file and line, and none required a manual search. Separately and structurally: DurationMinutes is a distinct type from TimeOfDay, so the substitution that caused the silent sites cannot be written.

Ordo, F#

Seventeen at once

17Ripple sites surfaced in a single build across two root causes — each root cause showing every affected call site in a single build rather than one per cycle. 0Runtime domain defects runtime domain defects.

AI generating code, and AI working inside an engineering system

This is the distinction the methodology exists for, and it is not about model quality.

Give the agent context

Correctness depends on inference

The agent receives a goal and enough repository access to work out how to satisfy it. It must infer where the change belongs, what it may affect, which states are valid, and what would count as finished. Everything it gets right, it got right by reasoning correctly about an under-specified system — including the parts nobody wrote down.

Failure mode: locally plausible code in the wrong place.

Give the agent a system

Correctness depends on structure

The agent asks what is legal in the current state and chooses from the answer. The compiler enumerates what its change propagates to. The architecture check refuses what violates layering. An independent mechanism inspects what the tests cannot express.

Failure mode: still possible — but a smaller share of it now depends on inference.

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

Ordo does not make a model reliable. In one paired trial both agents produced a change that passed every mechanical check on both architectures and did the wrong thing. Constraining what an agent can attempt is not the same as guaranteeing that what it attempts is right. The goal is to reduce how much of correctness rests on inference, not to eliminate inference.

Where this comparison does not hold

Three places, all from our own records, and each one rules out a claim we would otherwise like to make.

What this leaves

A narrower claim than "Ordo produces better software," and a more useful one. Here it is with the numbers attached, because "they differ in which mechanism catches them" is not something a reader can check.

The difference, at its smallest defensible size
Conventional C# Conventional JavaScript
Size 1,645 lines 1,540 lines
Rework-driving mistakes 6 2
Caught by compiler or language 3 of 6 0
Caught only by a person re-reading the diff 3 of 6 1 of 2
Sites named by the machine on one identical change 8 of ~22 0 of ~22
Sites a person had to find on that change ~14 All of them

Mistake counts do not separate the two: 6 against 2, and the build with less static checking scored better. The highlighted rows are where the separation actually lives. Of the C# rebuild's six mistakes, 3 of 6 were invisible to every mechanism — swapped string arguments, a stale revision inside a loop, a signature change hidden behind var — and were caught only because someone re-read a diff before running it. None of those three is catchable by a compiler even in principle. In the state-structured builds, the substitution that produced the fourteen silent sites cannot be written down, because a duration and a time are distinct types.

That is the claim: not fewer failures, but a smaller set of failures that depend on a person noticing. Under the conditions the industry now measures, where change volume outruns review capacity, that is the difference that decides whether the volume is absorbable. Both tables in full, with every figure's source →

The measurements How to start