What it is, what it proves, and what it does not. Version 0.1 · 15 September 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. Nothing here is aspirational: where something is built but not yet in use, it says so, and where a limit is live today it is named rather than left for you to find.
The record lives in New Zealand or the European Union and never on a US-owned provider. The tenant holds its own signing key, published in its own DID document. Export rights run before, during and after any subscription, and verification and export stay available if a subscription lapses — 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.
Every receipt is Ed25519-signed with the tenant’s own key. 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 client SDK ships the verifier 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.
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.
By default the record is tamper-evident: a signed, append-only proof chain in which each entry can be checked against its signer’s key. Tenants whose obligations require it can switch on write-once mode, which refuses amendment after the fact.
Per-entry linking is built but not yet in the released platform: each new entry will carry the hash of the entry before it, signature included, so removing or replacing one entry leaves the next one pointing at a hash that no longer matches. The verifier you can download from this site already follows those links, and says which kind of record it has been given — one with links, or one sealed without them. Every record in production today is the second kind.
What that does not mean. Tamper-evident is not tamper-proof. It shows that a record was altered after the fact; it cannot stop the alteration. The records published on this site predate per-entry linking and are not linked — every record published here was sealed without per-entry links, and for those the chain does not by itself prove that nothing was removed from the middle of it. The verifier reports them as chain not linked rather than quietly passing them, because a tool that cannot tell the two apart is no use for either. We are not going back to add links to the old records. Computing links now and writing them into records made earlier would give those records a property they did not have at the time. That is the change the record is built to expose.
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 Tamper-Evident Governance on this site.
This is the seminal part, and the one 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. An operator can satisfy every records-retention duty currently in force 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 authority, its jurisdiction,
whether it is qualified, the attested time, and a hash identifying the
RFC 3161 token itself. ⚠️ The token bytes are held on our side
and no route currently serves them, so today that hash lets you
confirm a token was recorded — it does not yet let you check the token
against the authority’s own root. Publishing the token is outstanding
work, not a property to claim.operator_attested — no attestation was
obtained. Three things cause it: no authority is configured, the request
exceeded the concurrency cap, or the authority did not answer in time.
The block records which, and the receipt is still issued.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.
⚠️ 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 authority on the receipt path is free and not eIDAS-qualified, so a stamped receipt gives evidence of when it existed, not a statutory presumption. The qualified authority — ArubaPEC, Italy — is under contract and its client is deployed behind a switch that is still off on that path. No receipt carries a qualified stamp, and this page will not say otherwise until one 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 carries that sentence inside the attested bytes, where it cannot be separated from the token.
The draft conformance standard asks for two authorities under distinct jurisdictions. One free authority runs on the receipt path; one qualified Italian authority has now been used once, over the published record set. That is not yet two authorities operating on the same records. No qualified service operating under New Zealand law has been found. An approach to one New Zealand provider was drafted on 14 September 2026; the search has begun and has not been described publicly.
The record is tamper-evident and signed. We do not market it as 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 moment of sealing, 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 went in 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 is the seminal one. Sending you to look at evidence that does not show the thing being claimed would be the exact move this page exists to argue against, so it is said here rather than discovered by you at a terminal. The verifier itself handles attestations correctly and fails closed on a grade it does not recognise; it simply has none of ours to read yet.