State column, and State of implementation
is the same picture in one place, as of 2026-08-29. A spec written as though it were all
shipped is a lie with a schema attached, and the honest state is part of what makes the rest
credible.
The objective
A merge reaches production the same day, through machine gates, and every claim made about it is provable: traceable from value → evidence → environment, and verifiable offline by a subscriber whose cluster the vendor never touches. Two concerns, deliberately separate:- Delivery speed — how long a merge takes to become a running image.
- Provability — whether what shipped can be shown to have earned it.
Value and evidence are different nouns
The single most load-bearing distinction in this model, and the one that collapses first if left implicit.
The relation is many-to-many. One evidence run covers many values — a single set-level
validation exercises dozens of claims at once. One value needs fresh evidence per environment: the
same claim proven in staging is not proven in production, because the configuration differs and the
configuration is what makes an observation mean anything. See
ADR-0010 (in review, #10)
§ What must ride with the per-image claim, or it means nothing: the per-image claim carries the
configuration it was exercised under, or it is not a claim.
Environment is stamped, never inferred. An envelope without the environment it ran on is a
sentence with the subject removed.
Nondeterministic modules get statistical evidence, not a green tick. Where a module is flaky by
nature — a browser joining a live meeting, a transcription pass over real audio — a single passing
run is evidence that it passed once, which is not the claim anyone cares about. The evidence is a
rate over a declared window: numerator, denominator, window bounds, and the environment. A
threshold is then a contract predicate over that rate, not a boolean the producer decides.
What a soak is
A soak is letting a release carry real production traffic for a declared stretch, and counting what happened. Not a test suite, not a longer test suite — the same work the software does for users anyway, watched. Its output is a rate over a window: this many meetings joined out of this many attempted, over these hours, on these image digests, in this environment. It exists because some claims cannot be made any other way. A join path that works ten times in a test rig and fails one time in twenty against real calendars, real networks and real meeting platforms has a defect a suite will never see; only volume finds it. So the soak is the producer forstatistical-rank values, and the reason production traffic is an evidence source rather than
merely the thing we are protecting.
Two properties matter downstream. It is per-digest, so the claim survives into any assembly
that reuses those images. And it keeps running, so it is the standing watch that catches
interactions nobody predicted, described in evidence reuse.
Rank — who can prove a claim
Every value declares its rank. Every evidence envelope records how it was produced. The contract is where the two meet.
Enforcement is by signature, not by convention. Rank maps to the class of functionary permitted
to sign the evidence that satisfies it. A contract row for a
human-rank value requires an
attestation signed by a human identity; a green CI run cannot satisfy it, however many gates it
contains, because no human key signed anything. Conversely an autonomous row is not satisfied by a
person asserting the gate passed — the gate’s own signed result is the only thing that counts.
This is what makes rank more than a label: it is a constraint on the permitted signer set, checked
by the same machinery that checks anything else in the contract.
The witness flow — a human observing a run and recording what they saw — exists today and is
unsigned, so nothing it produces can satisfy a human-rank row yet. That gap is the work, not
an oversight.
The three subjects
A claim binds to the thing it is actually about, and to nothing larger. Full reasoning in ADR-0010 (in review, #10 — not onmain, so it is referenced by PR,
not by path); the shape:
validation-contract.schema.json, and it is the point of that
document:
An image reused in a different assembly therefore inherits exactly what the configuration rows
justify — not the set’s verdict, and not nothing. A consumer running outside the exercised
configuration does not get a weaker claim; they get the claim plus the explicit statement of what it
does not prove for them, and their contract decides whether that is enough.
Through
value_ids on the candidate map, one set run validates many PRs. Some claims are only
ever true of an assembly — “the documented API surface responds as documented” is nobody’s pull
request — so they are proven once against the set, then propagate down the two edges the map
already holds:
Carrying the value ids on the map is the whole mechanism. One set-level observation settles the
claims of every change inside it with nothing re-run per PR — and a PR whose value id no set run
covered shows as
unproven rather than quietly passing.
Contracts are the gates to channels
A channel is an ordered stream of entries (channel.md). A contract is what
decides whether an entry may enter it, and whether an entry may run once pulled.
The contract belongs to the channel. Not to a release train, and not to a station: a staging
station and a prod station are two enforcement points of the same channel contract, and neither
owns one of its own. Composition is across channels — oenb-stable extends vexa-internal and may
only tighten it. Founder correction, 2026-08-29, recorded on
#12; the mechanics are on
How channel contracts compose.
A contract is a machine-readable list of:
- required evidence — kind, and (ruled, not built) the rank or signer identity that must have produced it, and its freshness bound;
- refusals — including the refusal of a declared absence:
evidence_absent[]states what an entry does not carry, andforbid_absent_evidenceis how a subscriber refuses an entry for declaring away something they require. The gap becomes checkable data rather than silence.
The contract is a form; a station run fills it in
The other founder ruling of 2026-08-29, on the same issue: there is no separate validation document. The contract is the form, and a run fills it in — per row, beside the demand it answers:proof: proven | unproven | not-run, a pointer to the evidence that proves it, the fidelity of
whatever stood in for a real dependency, and a does_not_prove line. The decomposition vocabulary
that used to live in a standalone document moves onto the rows it qualifies, so a reader stops
holding two files side by side working out which caveat attaches to which claim.
One train yields one filled instance of its channel’s contract: the same contract_id, sha-linked
back to the unfilled demand. The demand is constant across the trains that run on a channel; the
proof column is what varies per set. The verdict is that instance’s bottom line and the PROOF
card is that instance rendered — one record, two readings, neither written by hand. Every demand row
appears in the instance whether or not it was answered, and the verdict has a third value,
INCOMPLETE, for a run that ended with required rows neither proven nor refuted — so a station that
could not reach a dependency cannot be filed as a pass or as a failure. The definition is
spec/filled-contract.schema.json, committed with the seq-7 respin and not on main yet: as of
that turn it defines the document and validates instances offline, nothing produces one, and the
in-cluster verifier does not read it.
The evidence kind on the wire stays validation_contract. The name is now wrong for what it carries
and is kept this turn anyway, because the entry schema, the carriage predicates that name it in
require_evidence_kinds and forbid_absent_evidence, and the entries already published under it all
depend on the string. The prose says the filled contract; the wire says validation_contract.
Contracts are checked at publish and at admission — and, stated plainly rather than papered
over, these are two gates, not one gate run twice:
The publisher does not hold the subscriber’s contract and cannot evaluate it. That is a correct
consequence of the two-party design, and it means “both sides run the same contract” is not a claim
this repository can make.
evidence_absent[] + forbid_absent_evidence is built and barely exercised. The only contract
that forbids an absence today is the vendor’s own internal one. No subscriber contract forbids
anything yet, which means the sharpest property of the design is currently unproven by use.
Where everything lives, and how it is traced
Three stores, three jobs, and no store does two of them.
The reason there are three and not one: a bucket of signed blobs is durable and unreadable.
Files in a store nobody indexes will answer “is this signature valid” and will never answer
“what is the state of our software” — which is the question actually being asked. Content
addressing is what makes evidence trustworthy and is exactly what makes it unbrowsable: to find a
claim you must already know its digest.
So the three stores split that: the registry proves, the ledger records what happened in order, and
the projection is the surface a human or a dashboard reads. It is rebuilt from the artifacts at
ingest and holds no fact of its own, so it can be wrong only by being stale, never by disagreeing —
delete it and it comes back. Traceability is then a property of the chain rather than of any store:
value id → evidence envelope → subject digest → entry → station, each hop a pin rather than a
lookup by name.
Two further consequences:
- Entries move pointers, not bytes. The channel pointer moves by descriptor copy; an immutable tag carries identity and a floating tag carries position. Nothing is re-wrapped and nothing is rewritten.
- Mirroring a registry is how evidence reaches an air-gapped estate. Because the truth store is content-addressed and the verification path needs no network, a copied registry is a complete copy of the proof.
The standard stack
Founder ruling, 2026-08-29 (#12): wherever a widely-adopted standard covers a layer, adopt it; keep bespoke machinery only where the void is verified. Borrowed vocabulary lets a reviewer who recognises the standard stop evaluating and start checking.What is deliberately not standard, and why
Each of the following was searched for across in-toto, SLSA, VSA, Witness, Kargo, Binary Authorization, Flux, Ratify and GUAC, and not found. Not found is a bounded search, not a proof of novelty, and is written that way.The development flow this enables
- State the value — one sentence a human can witness — its rank, and which contracts will consume it.
- Validation is derived from those contracts, not designed per change. Nobody invents a test plan per pull request; the contracts that will have to accept the result already say what evidence must exist and who must have signed it.
- Agents implement, and collect evidence en route. The evidence is a by-product of the steps that were going to run, signed where produced.
- Two human moments remain, and only two: value sign-off — a person attesting the claim is the claim — and promotion approval — a person releasing it into an environment.
State of implementation
As of 2026-08-29. Nothing below is aspiration stated as fact. Two parts of the model have their own rendered pages, each carrying its own state: Evidence reuse and blast radius — how a claim is inherited when the diff cannot have touched it — and How channel contracts compose — the tighten-only chain across channels, the values registry that lets a claim be written exactly once, and the filled instance a train returns.
Two honest readings of that table. The evidence carriage is built — entries, bundles, digests,
offline verification, the publish gate. The evidence semantics — values, rank, subjects, standard
predicates — are ruled and mostly unbuilt. And the property the design leans on hardest, a
subscriber refusing a declared absence, has never been exercised by a subscriber.