Scope
Ordo, SDE, ROS and what is not here
Two names, one methodology, and one component this site declines to describe because nothing was found to describe it from.
Ordo is State-Directed Engineering
They are the same thing. Ordo is the name the methodology carries in public. State-Directed Engineering, usually abbreviated SDE, is the name it carries in the research record — in the doctrine documents, in the accepted evidence and hypothesis records, in the decision log, and in the published tooling package.
Every citation on this site resolves to an SDE-named artifact. That is deliberate, and it is
recorded as a decision rather than left as an inconsistency: experimental artifacts keep the
names they were created under, because a rename would break the provenance chain from every
published number back to the record that produced it. The reasoning, the alternatives
considered, and the consequences are in
research/decisions/DF-SDE-2026-0005.
Reading older material, you will also find state programming, state system and state-system architecture. Those are not synonyms for Ordo. State Programming is the paradigm — the constraints. Ordo is the methodology — how to work within them. Keeping the two apart is itself a recorded decision, made so that revising one does not implicitly relitigate the other.
The layers, as they actually exist
Paradigm
State Programming
The constraints: explicit semantic states, legal transitions, invariants, evidence, capabilities, obligations, effects, uncertainty, boundary preservation. A codebase can satisfy these and say nothing about how anyone should work in it.
Methodology
Ordo / SDE
How to work within those constraints: how a change is classified, where implementation starts, when a search substitutes for a mechanism that should exist instead, how verification is ordered, when work stops.
Operations
ROS
The Repository Operating System: work items, research artifact lifecycle, evidence records and validation. Ordo defines the method content; ROS is the process used to produce and record it. It is what makes the citations on this site resolvable at all.
The separation between the first two is load-bearing, and one experiment is the reason. Two conditions in the paired trial ran on architectures that were identical in the respect being studied, and produced different outcomes because of how each agent chose to work. That is a methodology question, not an architecture question — which is precisely why the methodology has to exist as something separate from the paradigm.
What this site makes no claim about
Limen. Ordo is sometimes described alongside a browser and application boundary architecture by that name. No artifact, configuration, or documentation for it was found in any of the six repositories inspected while this site was built. Rather than describe something unexamined, this site says only that it was looked for and not found. Nothing here depends on it, and nothing here should be read as a statement about what it is.
Any language or ecosystem not listed below. The evidence base covers F#, TypeScript, C# and JavaScript. It contains nothing about Java, Go, Rust, Python, or any other ecosystem, and this site makes no claim about them.
Teams. Every experiment on this site was executed by a single agent or a single supervised session. Nothing here measures what happens when several people apply Ordo to one codebase, and nothing here should be read as evidence about that.
Repositories this site cites
| Repository | Visibility | Role in the evidence base |
|---|---|---|
kemiller2002/state-directed-engineering | public | Canonical methodology: doctrine, construction method, and the accepted EV-/HY-/TH-/DF- records every experiment on this site is cited through. |
kemiller2002/helix-note-application | private | The application the first three controlled experiments were run on. Treated as read-only source evidence. |
kemiller2002/SDE-Engineering-Trial-1-Greenfield-Construction | private | First greenfield trial: the frozen requirements package, the development-metrics instrumentation, and a full implementation against it. |
kemiller2002/SDE-Engineering-Trial-2-Greenfield-Construction | private | Second greenfield trial and its independent replication: two agents building the same frozen requirements without seeing each other's work. |
kemiller2002/time-entry-state-machine | private | The time-entry domain and the effort experiment that rebuilt it twice in conventional styles for comparison. |
kemiller2002/consulting-company | public | The Echelon Foundry site. Its palette, type stack and layout primitives are the design system this site is built from. |
Several are private. A citation into one of them is labelled before you click it, so a reader knows in advance whether the artifact is open to them.
How this site is built
The site is static HTML and CSS with no client-side JavaScript. It is generated by a small F# program in the same repository that holds the methodology, from two data files and a set of content fragments.
Every number in the prose is a token that resolves against a typed evidence manifest at build time. A reference to a metric that does not exist fails the build. A metric that states no limitation, or that names no source artifact, cannot be represented in the manifest at all. Before anything is written to disk, the whole site is assembled in memory and checked: every internal link resolves, every citation fragment points at an element that exists, every generated JSON document parses, no unfinished draft marker survives, and nothing shaped like a credential is present.
That is not incidental. A site arguing that illegal states should be unrepresentable would be a poor advertisement for itself if an unsourced number were representable in it.