What it is, what it proves, and what it does not. Version 0.3 · 21 October 2026
Four words, and each one is a separate claim with a separate mechanism behind it. This page sets out what each is doing, and — because the claims are only worth what their limits are — what each one stops short of. Where something is built but not yet in use, the page says so, and a limit that is live today is named here. The statements on this page were checked against the code and the live service on 21 October 2026 by AI agents working to the author’s instruction; no person has audited them.
The order is the mechanism, in sequence. Sovereignty is the ground the other three stand on: infrastructure in a jurisdiction you chose. On that ground, a record is sealed so its contents are fixed to a hash; signed (digital signature) so that seal is attributable and cannot be forged; and timestamped (trusted timestamping, RFC 3161) by an authority outside this estate, so its existence is dated by someone with no stake in it. Each of those three is worth less without the one before it. Read that way they are a chain; read in any other order they are a list of adjectives.
The record lives in New Zealand or the European Union and never on a US-owned provider. Each tenant has its own signing key, published in its own DID document. Since 20 October 2026 the record-signing key of every active tenant is held by a separate signing service on its own host, which we run, reached over mutually authenticated TLS; if that service cannot be reached, signing is refused rather than falling back to a local key. Split-key signing, where named parties each hold a share and nobody holds the whole key, is built; no tenant uses it yet. Export rights run before, during and after any subscription, export stays available if a subscription lapses, and a record you have saved can still be verified with the keys it carries, so the evidence does not go dark because a bill went unpaid.
What that does not mean. Sovereignty here is about custody and jurisdiction, not about invulnerability. A record held sovereignly is still a record somebody has to look after.
The deliberation is captured as a structured kōrero: the proposal, the discussion, the AI inputs identified by tool and content hash, each participant’s engagement with those inputs in their own words, and the outcome claimed. AI output and human reasoning are kept structurally separate.
Sealing fixes that content to a digest. Change one character anywhere in it and the digest changes, which is what every later step depends on: a signature is a signature over the digest, and a timestamp dates the digest. Without this step there is nothing for the two steps that follow to hold on to.
By default the record is tamper-evident: an append-only proof chain whose entries can each be checked against their signer’s key — the key described under Signed, below. Tenants whose obligations require it can switch on write-once mode, which refuses amendment after the fact.
Each proof-chain entry can also carry prev_sha256, the
hash of the entry before it — computed over a field list that
includes the predecessor’s signature. Delete an entry
and its successor points at something that is no longer there. Swap an
entry for another validly-signed one and the same thing happens.
⚠️ Chain linking is switched on in production, since 24
September 2026. ProofChainSigner.js sets
prev_sha256 on each entry when
PROOF_CHAIN_LINKING_ENABLED is on; that code shipped on 15
September 2026, and the setting has been on for both production servers
since the 24th. It applies to entries written from then on. Earlier
entries are not retro-linked, and the verifier reports them as unlinked,
not broken. Note also that linking is on the proof
chain, not on receipts: a receipt has never carried a
previous-entry hash and does not now.
The verifier published on this site walks those links and distinguishes three states, and that distinction is the care the code exists to take: the key absent means the entry was written before linking existed — unlinked, not broken; a null value is the first entry of a linked chain and is valid only at position 0; a hash must equal the hash of the entry before it. Reading absence as a break would condemn this estate’s own July bundles, and a verifier that calls genuine records tampered is worse than one that ignores links altogether.
What that does not mean — and the limits here are four, not one.
Tamper-evident is not tamper-proof: it shows that a record was altered after the fact; it cannot stop the alteration.
The ten records published on this site predate linking and are unlinked — measured by running the published verifier over each of them, not assumed. We are not going back to add links. Computing links now and writing them into records made earlier would give those records a property they did not have at the time, which is precisely the move this design exists to expose.
🔴 And linking does not prove that nothing was removed — not even on a linked chain. A backward link is checked by the entry that follows it, so deleting the last entry leaves no successor pointing at the hole. Truncation — including removing a final refusal — is invisible to links alone. Closing that needs a signed anchor over the chain head and its length, travelling inside the bundle; that mechanism exists inside the estate and is not yet exported, so what the public can check is the weaker of the two claims.
A link verdict is also suppressed whenever any signature in the chain failed or any entry was unsigned. Links are computed over entry content, so an attacker who deleted an entry and recomputed every surviving link would produce a chain that walks perfectly. Only the signatures catch that.
We hold that a record whose tampering can be demonstrated is stronger evidence than one that merely claims to be unchangeable — but that is an argument, not a proof, and it is made in full in Governance That Can’t Be Quietly Undone.
Every receipt is Ed25519-signed with the tenant’s own key (held as described under Sovereign), over the sealed digest above. The signer fails closed: if the signing infrastructure is unavailable the request returns 503 and no receipt is issued, because an external attestation that is not signed is worse than none. A receipt also carries an explicit, signed label naming which authority reached the verdict — never an unlabelled claim.
Verification takes the receipt, the tenant’s public DID document, and
about forty lines of code. No call to us, no account with us, no trust
in our word. The standalone verifier, verify-record.js, is
published here, and the canonical-payload algorithm is published so it
can be re-implemented in any language.
What that does not mean. A signature establishes who issued the record and that nothing in it has changed since. It says nothing about whether what the record says is true.
This is the part that does the work the other three cannot.
A signature made by us, on infrastructure we control, stamped by our own clock, is evidence about us. In our reading, an operator can satisfy a New Zealand records-retention duty today with a log it can edit, on a machine it owns, dated by a clock it sets. What is missing from that is an outsider.
So before a receipt is signed, its canonical digest is sent to an RFC 3161 timestamp authority — an organisation outside this estate, with no interest in what the record says. When the authority answers, its attestation is folded into the receipt beneath the tenant signature. That ordering is the whole design: because the attestation sits inside what was signed, a receipt cannot afterwards be re-stamped, back-dated, or stripped of its timestamp without breaking the signature.
The grade field says which of two things happened:
tsa_rfc3161 — an outside authority
attested the digest. The block carries the attested time, a hash
identifying the RFC 3161 token, and — since 16 September 2026 — the full
set of authorities used, how many there were, their jurisdictions,
whether those jurisdictions are distinct, and whether they are
independent of one another under mutual assistance. That last field is
the one the conformance standard turns on, and it is printed whether the
answer flatters us or not. For a receipt, the token is held
whole on our side with its certificate chain, and the Governance API
returns it from
GET /api/v1/governance/records/{id}/time-stamp-tokens/{sha256}
(Live since 27 October 2026). The receipt checker reads it with
--token and reports Verified only when both the signature
and the token check out. Records anchored by the daily sweep are
stored the same way and can also be checked with
openssl ts -verify without contacting us.operator_attested — no attestation was
obtained, and the block records which reason. There are more than a
dozen: no authority configured, the concurrency cap, a timeout, an
authority that answered but did not grant, a malformed or unparseable
token, a nonce mismatch, an oversized or unreadable response, a failure
to save. ⚠️ An earlier version of this page said “three things
cause it”. That was the count of the reasons someone had
thought to list, not the count in the code.A receipt is valid either way. Only the first tells you anything about the time that does not come from us, which is why the field exists and why it is inside the signature rather than beside it. Below, grade A is shorthand for the first and grade O for the second.
⚠️ A grade-O receipt stays grade O. The block is
inside the signature, so it cannot be amended afterwards. A nightly
sweep does retry the stamp, but what it writes is a separate anchor
record on our side — the receipt in your hands is unchanged, and
nothing currently lets its holder discover that a later stamp
exists. Read grade on the copy you hold and
believe it.
What that does not mean, and these are the live limits.
The attestation is attempted on every receipt. It does not always succeed, and a receipt issued grade O rests on our word for its time. We do not currently publish what proportion of receipts are grade A, and until that figure is published a reader should assume the weaker case.
✅ The path does work, and that is now demonstrated rather
than designed. On 21 September 2026 a receipt issued through
this path came back grade tsa_rfc3161, attested by Certum
(Asseco Data Systems S.A., Poland), with the token hash recorded in the
receipt. One receipt, one tenant — that is evidence the mechanism runs
end to end; it is not a proportion, and it does not make the paragraph
above any less true.
The authority on that path — Certum — is free of charge and
not eIDAS-qualified, so a stamped receipt gives evidence of
when it existed, not a statutory presumption. The trust anchor of a
second authority, Portugal’s state service, is pinned in the code as a
second time authority; it is recorded as not qualified. The qualified
authority, ArubaPEC in Italy, is under contract, and the software that
talks to it is deployed behind four switches, all of which must be on;
any one of them off means no qualified stamp. They are: an in-process
kill switch, a kill file on disk, an install-wide setting that must read
exactly true, and a per-tenant entitlement list that
defaults to nobody. The last is deliberate — the
balance is a single purchased pool, so without it one tenant’s traffic
would spend the stamps bought for another. Each tenant also has a
monthly ceiling on paid stamps, five unless set otherwise, and there is
no setting that means unlimited. We turn it on for a customer on
request; today it is on for none. Checked in the code and on both
production servers on 21 October 2026. No receipt carries a qualified
stamp, and none will be described as carrying one until it does.
✅ One qualified attestation does now exist, and it is not on
the receipt path. On 15 September 2026 the ten published record
bundles were listed in a manifest and that manifest’s digest was
submitted to ArubaPEC directly. The token came back granted, under ETSI
policy 0.4.0.2023.1.1, signed by a certificate reading
Qualified Time Stamping Authority. It is published with the
records and anyone can check it — see check the record
yourself.
That attestation says those ten files existed in exactly that form no later than 00:37:29 UTC on 15 September. It does not date the deliberations, which were sealed by our own signature on 10 July and carry no outside attestation of that date. Stamping a July record today and calling it July would be back-dating, which is the thing this design exists to make detectable — so the manifest states that inside the attested bytes, where the statement cannot be separated from the token.
The draft conformance standard asks for more than most readers assume, and the page previously quoted only the easy half. MIO-STD-01 §5.2.1 requires at least two authorities; §5.2.2 says one is not sufficient; §5.3.1 requires at least two distinct legal jurisdictions; and §5.3.2 requires that those jurisdictions not be ones where a single authority, court or executive can compel production or alteration from all of them under one instrument or one mutual-assistance mechanism.
Since 16 September the switch, when thrown, turns on a pair — Certum in Poland and ArubaPEC in Italy — rather than swapping one for the other. Thrown, that pair would satisfy §5.2.1, §5.2.2 and §5.3.1.
🔴 It fails §5.3.2, and every receipt says so on its
face. Poland and Italy are both EU member states and are
compellable under the same mutual-assistance arrangements, so the
receipt carries mutual_assistance_independent: "no". Two EU
authorities cannot satisfy that clause however many you use. Answering
it needs an authority outside that reach, which is why a New Zealand one
matters and is not merely a patriotic preference.
No qualified service operating under New Zealand law has been found. An approach to one New Zealand provider was sent on 1 October 2026 and no reply is recorded; the search for a New Zealand authority is described on our Provenance pages.
Built and deployed, not yet running: a second place, outside our systems, for the daily
fingerprint. The daily estate root can be anchored on Midnight’s
Preview test network, and a Governance API receipt can be given the path
that joins it to that anchor; the downloadable receipt checker reads the
path offline and prints anchored or
anchor_not_checked as a state after its result. The anchor
is separate from the time stamps above and does not replace them. It
shows that a value was recorded under a date key; it does not show that
any record is true or complete, it is our attestation (the entry is made
with our service key) on a network that is federated, not decentralised,
and only hashes go on the ledger. The code is deployed with the setting that adds Governance receipts to the daily root left unset, and the
daily job is not running on the production servers, so the anchor-proof route answers not_yet_anchored.
The record is tamper-evident and signed. We do not claim it is tamper-proof or court-defensible. Whether it satisfies a legal duty is a matter for your counsel and, where it comes to it, a court. What it gives you is the strongest contemporaneous, self-verifiable account of how a decision was made — evidence of how, not proof that a duty was met.
A timestamp from an outside authority establishes tamper-evidence from the attested time onwards, with the sealing party named. It does not establish provenance: where a tool is self-hosted, the customer’s own process makes the observation and submits the digest.
The strongest thing on this site is not an argument. There is a set of sealed records published with a standalone verifier that runs on your machine, imports nothing from here, and makes no call to us. Change one character of a bundle and it says so.
🔴 Read this before you run it. It is where the demonstration
stops. The published bundles were sealed on 10 July 2026 and
carry receipt_version: 2 — they predate
the timestamp work described above, which was built in September.
The verifier will report
Time attestation: NONE. No receipt in this bundle carries an outside date.
on every one of them, and that is correct output, not a fault.
So on the bundles themselves you check the signature and the
seal: that the content is unaltered and was signed by the
published key. ✅ And since 15 September there is a qualified
outside timestamp over the set, published beside it as a
separate artefact — a receipt cannot gain an attestation after signing
without breaking its own signature, so it sits alongside rather than
inside. What is still not attested by anyone outside this estate is the
10 July date — the part this page argues does the work.
Sending you to look at evidence that does not show the thing being
claimed would be the move this page exists to argue against. The
verifier itself handles attestations correctly and fails closed on a
grade it does not recognise; it simply has none of ours to read in these
July bundles. It also checks a did:x509 signer against trust anchors you
choose (--trust-anchor) and can require a post-quantum
second signature (--require-pq; at least ten records had
been given one by 26 October 2026, on Villages where it is switched on).