Three questions, one substrate.

Governance, liability evidence and agent authority are routinely sold as one problem. They are three, they face different adversaries in different directions in time, and a system that merges them ends up holding the union of everyone's data and the intersection of everyone's guarantees. This paper sets out the layering, what the layers legitimately share, how they compose over a single event — and the seams that are still open.

§1Three questions that look like one

An organisation runs an automated system. Something happens. Over the following months three different parties arrive, and it is tempting to think they want the same file.

Different time direction. Different adversary. Different artefact. Different retention horizon — an obligation derivation is worth little once the rule changes, whereas a record may need to be checkable for a decade or more.^[1] And, decisively, different disclosure surfaces: the material you hand a regulator, the material you disclose to a claimant, and the material you show a counterparty at machine speed have almost nothing in common except the event they describe.

§2Why they have to be separate layers

The instinct is to build one system that answers all three, because they are about the same event and share vocabulary. Three arguments against, in ascending order of how much they cost you if ignored.

Data gravity works the wrong way

Merge the layers and each one's data becomes reachable from every other one's interface. The authority layer, which needs to hold almost nothing, is now colocated with the record layer, which holds the most sensitive operational history you have. A disclosure order scoped to one produces an argument about the other. Separation is not tidiness; it is what keeps the blast radius of a disclosure, a breach or a subpoena bounded.

The guarantees do not compose upward

Each layer can make a strong, narrow promise. The authority layer can promise that a credential was valid and unrevoked at an instant. The record layer can promise that a record is exactly what was written and has not been quietly altered. The governance layer can promise that an obligation follows from a stated derivation. Merge them and you cannot promise the union — you end up promising the weakest of the three about everything, because a single verifier now has to be right about all of it at once.

Severability is a real requirement, not a business preference

These layers face different regulators, will be operated under different jurisdictions, and have genuinely different lifespans. A system that cannot be separated later has made an irreversible decision on behalf of people who were not in the room. The engineering expression of that is unglamorous and absolute: separate stores, separate keys, separate verifiers. Not separate schemas in one database — separate databases, so that carving one out is a move rather than a migration.

§3What they share, and why sharing is safe

Separate stores, separate keys — and yet all three need the same underlying property: a record that proves itself, in an order that cannot be quietly rearranged, attributable to a party. Rebuilding that three times is how you get three subtly different constructions and three different sets of defects. (That is not hypothetical. The audit behind these papers found the same canonicalisation defect — Paper 002's __proto__ trap — in eight copies across four codebases, fixed in some and live in others.)

So the layers share a substrate, which is the set of constructions in Papers 002 and 003:

• canonical JSON — deterministic, keys sorted recursively, null-prototype accumulator;
• a record identity that is a Merkle root over salted field leaves, so it survives redaction;
• a hash link binding each record to its predecessor;
• a signature over domain ‖ chainId ‖ seq ‖ prevHash ‖ recordHash;
• a per-record envelope version, so the format can move without rewriting history;
• and the rule that every absence — a missing signature, an unloadable key — is a failure.

That last point is what makes sharing safe rather than dangerous. Domain separation (Paper 003 §5) means a record signed by one layer cannot replay as a record of another, even though the byte layout is identical and even if a key were ever reused. The tag is what converts "three systems using the same maths" from a correlated-failure risk into a straightforward benefit: one construction to get right, one verifier shape to review, one set of test vectors — and no path by which an artefact of one becomes an artefact of another.

§4How they compose over one event

The value of the layering shows up when a single event is examined from three directions at once. Take a concrete shape: an automated system takes an action with financial consequences, and eighteen months later somebody disputes it.

1. The authority layer answers what was permitted at the instant: which agent identity acted, under what scope, within which ceiling, and whether that authority had been withdrawn. Its record is small and deliberately says nothing about amounts or people.
2. The evidence layer answers what the system actually did and what state it was in — disclosed in part, with fields withheld for relevance or confidentiality, and the remainder still reproducing the commitment sealed at the time.
3. The governance layer answers which obligations attached to that system, on what derivation, on the date in question — including obligations that have since changed, which is why the derivation matters more than the conclusion.

Three artefacts, three narrow claims, each checkable without the other two. That independence is the whole point: a party who trusts none of them can verify each separately, and a failure in one does not contaminate the others. A merged system produces one artefact that must be believed as a whole.

§5The seams, including the one that is not finished

Layers that must not share a database still have to meet somewhere. Three seams, and they are not equally solid.

Identity and tenancy

All three need to agree on which organisation a record belongs to, or the chain identifier in the signed preimage means different things in different systems. The safe form of this seam is a shared identifier resolved over an API — never a shared table. The identifier appears inside the signed bytes of each layer under that layer's own domain tag, which is what keeps the binding strong without creating a coupling.

A common verifier contract

Because the substrate is one specification, a party can hold one mental model and check all three: recompute the canonical form, recompute the hash, rebuild the link, check the signature over the five-field preimage, and refuse on any absence. Reviewing one verifier carefully means understanding all of them — which is a real reduction in what a sceptic has to take on faith.

Custody hand-off — and this one is open

§6What the layering costs

An architecture paper that only lists benefits is a diagram with adjectives. The costs here are real and two of them are unsolved.

• Three key custodies. Three signing keys, three rotation stories, three sets of published verification keys. Each is a place to get key management wrong.
• Three domain tags that must never collide, including as products are renamed, merged or sold. A tag is a permanent commitment; it appears in every signature ever made.
• Cross-language agreement is not free. Where layers are implemented in different languages — and they will be — the canonicalisers must agree byte for byte. They do not agree by default. Measured across two runtimes on the same inputs: integers above 2⁵³ serialise differently, small exponents format differently (1e-7 against 1e-07), and object keys containing supplementary-plane characters sort differently under UTF-16 code units than under UTF-8 bytes. Each produces a different record hash for the same logical payload.
• There is no shared conformance corpus yet. This is the honest gap. Agreement is currently believed rather than proven, and the fix is unglamorous: a versioned set of test vectors — canonicalisation, preimages, tree roots, proofs, and named negative cases — that every implementation must reproduce, wired into every build. Until that exists, "these implementations agree" is a claim of the kind this series exists to distrust.

§7Provenance, and what is out of scope

The layering described here is implemented across three systems built by the practitioners contributing these notes: a governance layer (RiverAct), a liability-evidence layer (SureWard) and an agent-authority layer (SignWard). That provenance is stated so a reader can weigh it, and because the defects reported throughout this series were found in that code rather than imagined.

What is deliberately absent, here as elsewhere: the content of any layer's rules — the obligation derivations, the detector logic, the policy evaluator — and every operational specific. Those are product decisions and deployment decisions. They vary, they are not properties of the architecture, and generalising from one implementation would be misleading rather than generous.

What is present is the part that is checkable: three questions, three layers, one substrate held in common by specification, distinct domain tags to keep them apart, and an honest ledger of the seams that are not yet finished. Each of those claims can be tested by anyone who implements it, which is the only standard worth writing to.