Concept 5
Boundaries and authority
A boundary is where a value leaves the place that understands it. This is where this
research programme found most of its defects, every time it looked.
Two failure shapes
Representation collapse
A closed value becomes open
A named alternative crosses a boundary and arrives as an arbitrary string. The domain
permits four things; the boundary admits anything. Nothing fails at the crossing — it
fails later, somewhere that cannot tell it was ever constrained.
Uncoordinated duplication
One fact, several copies, no agreement check
The same vocabulary maintained in the domain, in the persistence schema and in the wire
format, by hand. Adding a case updates one of them and produces silence at the others.
Experiment 1 measured both in one codebase. The single fact the compiler protects had zero
duplication. The two facts outside its reach were duplicated four times and twice, with no
automated check that the copies agreed.
What a shared type does not buy you
The intuition that two components in one language sharing one type are therefore safe at
their boundary was tested directly, and refuted. The identical shared type produced three
different wire behaviours depending on which call path reached it — inside a single process.
A type is a promise about values in memory. It is not a promise about what a serialiser
emits. That is a different artifact, and Ordo asks for it to be specified deliberately rather
than inherited from whatever a library does by default.
What hardening the boundaries changed
Experiment 2 built five mechanisms against Experiment 1's specific blind spots: a
constraint-agreement test between the database and the domain, a single-source wire
discriminator, exhaustive dispatch replacing string dispatch, a field-vocabulary agreement
test, and a fixture forced to a compile error when a case is missing.
8 of 12
Required sites found by the compiler alone
Self-reported
- Measures
- The share of required handling sites for a new closed-alternative case that a compiler exhaustiveness error pointed at directly — 66.7%.
- Collected by
- Each site was classified as it was discovered, as either a compiler error or manual investigation, during the implementation itself.
- Does not show
- One change class — a new case in a closed alternative — on one architecture, in one trial. It says nothing about change classes the type system does not model, and the session classified its own discoveries.
Sourcekemiller2002/state-directed-engineering / research/evidence/EV-HN-2026-0003--experiment-1-boundary-amplification.md — Key figures66.7% to 100%
Mechanical discovery rate after hardening
Self-reported
- Measures
- The share of required sites reported by a machine rather than found by looking, before and after five targeted hardening mechanisms.
- Collected by
- Same classification method as Experiment 1, applied to a new case on the hardened architecture.
- Does not show
- 100% is measured against the specific blind spots these five mechanisms were built to close. Experiment 3 showed the figure does not transfer to a tier the hardening does not cover, where it fell well below this.
Sourcekemiller2002/state-directed-engineering / research/evidence/EV-HN-2026-0004--experiment-2-boundary-authority.md — Key figures
One of those mechanisms did something better than mechanising discovery. Making the wire
discriminator single-sourced removed the site entirely — there was no longer anything there
to find. That distinction, between making a change easier to find and making it unnecessary,
is worth more than the discovery-rate improvement.
What hardening did not change
Four boundary files per semantic decision, measured three times, across three domain cases
and two architectures, identically. Hardening changed how required boundary work was
found. It did not change how much of it there was.
This is recorded permanently as a contradicted proposition
(CL-006) so that nobody proposes it again without
seeing why it was rejected. If somebody tells you that making boundaries explicit reduces
the number of places a change touches, the only measurements here say otherwise.
And one tier nothing guarded at all
In the paired trial, 7 of 19 required sites fell in the HTTP tier, which had
zero mechanical guard on either architecture. That is the single biggest reason the
hardened condition's discovery rate came in below its own preregistered prediction.
A candidate mechanism for that tier is sketched in the source report. It has not been built
and it has not been tested, and this site does not claim it works
(CL-009).
How this is most often got wrong
Reading compiler silence as agreement. A build that goes green after a case
is added to a closed set has told you about the tiers it can see. The persistence constraint,
the wire contract and the fixtures are the tiers it cannot, and they are the tiers where
Experiment 1 found the duplicated facts. Silence there is absence of a check, not a passing
one.
Expecting hardening to shrink the work. It does not, and that was measured
three times across two architectures
(CL-006). Hardening changes who finds a propagation
site — a mechanism instead of a person — and leaves the number of sites roughly where it was.
A team that adopts it expecting less work will conclude it failed; a team that adopts it
expecting fewer misses is measuring the thing it actually does.
Hardening the tiers that were already guarded. The tempting work is where the
tools already are, because that is where progress is visible. The unguarded tier stays
unguarded, and it is where 7 of 19 required sites fell.
What an agent should do differently
-
When adding a case to a closed set, ask where that set is restated — persistence
constraints, wire formats, validation lists, test fixtures. Compiler silence at those
places is not agreement.
-
Do not treat a shared type as a boundary contract. Specify the wire representation, and
check it.
-
Where duplication cannot be removed, add a mechanical agreement check. A comment saying
"keep in sync" is not one.