Check the record yourself

Ten sealed records, a verifier that runs on your machine, and no reason to trust us. Version 0.2 · 15 September 2026

Every line of output on this page was produced by running the published verifier — against the published records, or for the attacks against copies of them altered as each heading describes, except the one transcript marked as a constructed example below. The attack transcripts are cut to the lines that matter and long lines are wrapped, and the exit notes at their right are ours, not the tool’s; the untouched record is shown in full. You can reproduce all of it in about two minutes, on your own machine, with no account, no key from us, and no network call to this site.

Start with what it catches

A record you cannot break is not interesting. A record that tells you exactly how somebody tried is. Here is the tool refusing eight attacks on the same bundle.

Change one character of the deliberation:

  korero content hash DOES NOT MATCH (0784a11555ff492c…)
❌ VERIFICATION FAILED                                           exit 1

Flip a decision in the proof chain — allow becomes deny:

  proof create → deny — signature INVALID
❌ VERIFICATION FAILED                                           exit 1

Delete the deliberation and keep the receipts:

  korero content MISSING while receipt gr_1NPbvkh2PNkBJLoi seals
  31663a10191bdfe2… — the sealed content has been removed
❌ VERIFICATION FAILED                                           exit 1

Delete a whole entry from the middle of the proof chain. ⚠️ This transcript is a constructed example: a record we built on the not-yet-released linking code to show the check. It is not published, so unlike everything else on this page you cannot rerun it. Every surviving signature is still valid — that is the point. Signatures authenticate the entries that are present, and nothing in them ever named the one that was taken out. Only the link catches it:

$ node verify-record.js linked-example.json
  proof create → allow — signature VALID
  proof seal → allow — signature VALID
  ✗ chain link BROKEN between entries 1 and 2 — entry 2 points at
    046de8ad372b83ce… and entry 1 hashes to 41b02bf287aa46a9…
  ✗ 1 broken link — at least one proof-chain entry has been REMOVED or
    SUBSTITUTED. Every signature above may still be valid; that is what links
    exist to catch.
❌ VERIFICATION FAILED                                           exit 1

⚠️ And here is what that check cannot do. A link is checked by the entry that follows it. Remove the entry at the end of a chain and nothing points at the gap — so truncating a record, including cutting off a final deny, is invisible to links alone. The tool says so on every linked record rather than leaving you to assume otherwise. Closing that gap needs a signed count of the chain travelling with the bundle; it is not there yet, and until it is, what you are told here is the narrower claim rather than the wider one.

⚠️ That transcript is from a linked record, and the ten bundles published here are not linked. Per-entry linking is built but not yet in the released platform, and every record on this site was sealed without it. Run the tool against one of them and it says so rather than implying a check it cannot make:

  chain not linked — all 3 entries predate per-entry linking, so this tool
  CANNOT tell you whether an entry was removed

Everything else on those records still verifies — signatures, sealed content, receipt fields. The one question the tool cannot answer for them is whether an entry was taken out.

The published records are not being given links after the fact. Writing links into records made earlier would give them a property they did not have at the time — which is the change the verifier is there to catch.

Rewrite the record’s identity to point at a different decision:

  ✗ record.decision_id does not match signed receipt gr_6YhXmJ2mOGd699DY:
    "dvr_somethingelse" vs "dvr_HUG6loLQj5cjtBC7"
  ✗ record.decision_id does not match signed receipt gr_Fcqlg6Fz00zE255s: …
  ✗ record.decision_id does not match signed receipt gr_1NPbvkh2PNkBJLoi: …
❌ VERIFICATION FAILED                                           exit 1

Swap the published key for another valid one:

  receipt gr_6YhXmJ2mOGd699DY (record_open) [integrity seal (pre-v3)] → signature INVALID
  receipt gr_Fcqlg6Fz00zE255s (record_segment) [integrity seal (pre-v3)] → signature INVALID
  receipt gr_1NPbvkh2PNkBJLoi (record_seal) [integrity seal (pre-v3)] → signature INVALID
  proof create → allow — signature INVALID
  proof update → allow — signature INVALID
  proof update → allow — signature INVALID
❌ VERIFICATION FAILED

Claim it came from somebody else — pin the DID you expect, and a lie about origin surfaces even though every signature is mathematically fine:

$ node verify-record.js core.json --expect-did did:web:someone-else.example
Record: dvr_HUG6loLQj5cjtBC7 — 3 receipt(s), 2 sealed segment(s)
Issuer pin: every receipt and signed proof-chain entry must claim to be signed under did:web:someone-else.example
  receipt gr_6YhXmJ2mOGd699DY (record_open) [integrity seal (pre-v3)] → signature VALID, issuer MISMATCH
  receipt gr_Fcqlg6Fz00zE255s (record_segment) [integrity seal (pre-v3)] → signature VALID, issuer MISMATCH
  receipt gr_1NPbvkh2PNkBJLoi (record_seal) [integrity seal (pre-v3)] → signature VALID, issuer MISMATCH
  proof create → allow — issuer MISMATCH (did:web:devtest.mysovereignty.digital is not the pinned did:web:someone-else.example)
  proof update → allow — issuer MISMATCH (did:web:devtest.mysovereignty.digital is not the pinned did:web:someone-else.example)
  proof update → allow — issuer MISMATCH (did:web:devtest.mysovereignty.digital is not the pinned did:web:someone-else.example)
  chain not linked — all 3 entries predate per-entry linking, so this tool CANNOT tell you whether an entry was removed
  korero content hash MATCHES the sealed receipt (31663a10191bdfe2…)
❌ VERIFICATION FAILED

The pin covers proof-chain entries as well as receipts. It checks the DID a signature claims; see what it does not prove, below.

Strip a signature to hide who decided — and note it does not simply fail. It separates two different facts, which is the behaviour worth having:

  proof create → allow — UNSIGNED, verdict NOT proved
⚠️  VERIFIED — but at least one verdict in this record is UNSIGNED or uncheckable.
   Integrity holds; the DECISION is not proved. Do not rely on it as a
   governance verdict.
   Note: this proves integrity using the key published in the bundle.
   NOT PROVED: who issued it. --expect-did <the tenant's did:web, from a
   source you trust> pins the DID the signatures claim;
   to prove the issuer, also confirm the keys in this bundle against that
   DID's published did.json.                                     exit 3

Hand it an attestation grade it has never heard of, and it refuses to bless what it cannot evaluate rather than waving it through:

❌ VERIFICATION FAILED — this tool cannot evaluate a time attestation in this
   bundle, so it will not tell you the record is verified.        exit 1

Three exit codes, and the distinction between them is the point: 0 verified · 1 failed · 3 intact but the decision is not proved.

Then the untouched record

$ node verify-record.js core.json --expect-did did:web:devtest.mysovereignty.digital
Record: dvr_HUG6loLQj5cjtBC7 — 3 receipt(s), 2 sealed segment(s)
Issuer pin: every receipt and signed proof-chain entry must claim to be signed under did:web:devtest.mysovereignty.digital
  receipt gr_6YhXmJ2mOGd699DY (record_open) [integrity seal (pre-v3)] → signature VALID, issuer MATCHES pin
  receipt gr_Fcqlg6Fz00zE255s (record_segment) [integrity seal (pre-v3)] → signature VALID, issuer MATCHES pin
  receipt gr_1NPbvkh2PNkBJLoi (record_seal) [integrity seal (pre-v3)] → signature VALID, issuer MATCHES pin
  proof create → allow — signature VALID
  proof update → allow — signature VALID
  proof update → allow — signature VALID
  chain not linked — all 3 entries predate per-entry linking, so this tool CANNOT tell you whether an entry was removed
  korero content hash MATCHES the sealed receipt (31663a10191bdfe2…)

Time attestation: NONE. No receipt in this bundle carries an outside date.
  Every date here is the issuer's own claim.

✅ VERIFIED — signatures valid and sealed content unaltered (integrity seal), checked without the platform.
   Pinned: every signature claims did:web:devtest.mysovereignty.digital.
   NOT PROVED: that the keys in this bundle belong to that DID — confirm them against its published did.json.

It exits 0. All ten bundles verify. Nothing on this page asks you to take that on trust — the next section is how to run it.

The tool — how to run it, and what each check does

Download verify-record.js →

Plain readable JavaScript. No dependencies. It requires only Node’s own crypto and fs, so there is no npm install and nothing to trust but the file you can read.

node verify-record.js core.json
node verify-record.js core.json --expect-did did:web:<the issuer, from a source you trust>

What it establishes, offline:

Every receipt’s Ed25519 signature, over canonical JSON with sorted keys and nulls dropped
Every proof-chain entry’s signature, bound to the record’s own provenance hash — so an entry cannot be lifted from one record and pasted into another
The links between entries, where a record has them: each entry carries the hash of the one before it, signature included, so a removed or replaced entry leaves the next one pointing at a hash that no longer matches. A record made before linking is reported as chain not linked rather than passed quietly. Where the links are intact but the signatures were not, the tool withholds the reassuring sentence and says instead that the links tell you nothing — they prove nothing about entries it could not authenticate
The deliberation content, rehashed and compared to the sealing receipt
The record’s own fields against every receipt’s: identity, tenant, reason codes, attestation authority. Dropping later receipts to shorten the history breaks this
The authority label is inside the signature, so a sandbox verdict can never be relabelled as an authoritative one
With --expect-did, the DID that every receipt and every signed proof-chain entry claims to be signed under — pinned offline, with no DID resolution and no network. ⚠️ That pins the name, not the keys: the keys travel inside the bundle, so proving the issuer also needs those keys confirmed against that DID’s own published did.json

What it refuses: an unknown receipt version · an unrecognised attestation grade · a bundle with no receipts, no chain and no content · malformed input, in sentences rather than a stack trace.

What it does not prove. Every run that passes ends by saying the issuer is not proved; a run that fails ends with the failure and no caveat. The key travels inside the bundle, so integrity is proved and issuer is not. Pinning with --expect-did checks the DID the signatures claim; it does not check that the keys belong to that DID, so a bundle with its keys swapped and every entry re-signed with them would still pass a pinned run until you compare them with the DID’s published did.json. It does not parse the RFC 3161 token against the authority’s own root — for a stamped receipt it verifies the authority’s details were signed by the issuing key, which is a different thing. And decided_at is deliberately unbound.

The records — ten sealed bundles

Open the set →

Ten plain JSON bundles, one per strand of a deliberation: authority and institutions, strategic posture, security and resilience, people and work, data and privacy, grid and generation, freshwater and cooling, hardware supply, sovereign compute, and te Tiriti with Māori data sovereignty.

Each carries its deliberation content, its chain of signed receipts, the signed proof chain, and the public key those signatures were made with. The compute bundle carries an extra segment — a blocked plan, a revision, then adoption — which is the most interesting one to open if you open only one.

What the bundles themselves do not carry. They were sealed on 10 July 2026 and carry receipt_version: 2, so they predate the outside-timestamp work that went into the receipt path in September. verify-record.js will report Time attestation: NONE on every one of them. That is correct output, not a fault — a receipt cannot gain an attestation after signing without breaking its own signature, which is the property the whole design rests on.

What sits beside them, as of 15 September 2026: a qualified timestamp over the set. See the next section.

The qualified timestamp — what an outside authority has attested

On 15 September 2026 the ten bundles, exactly as published, were listed in a manifest of their SHA-256 digests, and that manifest’s own digest was submitted to ArubaPEC S.p.A., an eIDAS-qualified trust service provider in Italy. The token it returned is published here:

records-manifest.json — the ten digests, and what the stamp does not claim
records-attestation.json — the authority, the time, the token
records-manifest.tsr — the RFC 3161 token itself
records-manifest-tsa-cert.pem — the certificate that signed it

$ openssl ts -reply -token_in -in records-manifest.tsr -text
Status: Granted.
Policy OID: 0.4.0.2023.1.1
Hash Algorithm: sha256
Message data: 8f9b828b 8608c8e3 114f63f2 ad0ddbde
              72f78005 eaec5687 1e5c3a02 a71f4d67
Serial number: 0x6BC9E98DB13DB933
Time stamp: Sep 15 00:37:29 2026 GMT

The certificate that signed it names what it is:

CN = ArubaPEC Time Stamping Authority EQ A
OU = Qualified Time Stamping Authority
issuer: ArubaPEC EU Qualified TimeStamp CA G1

Checking it takes three hashes and no trust in us. Hash the bundle you downloaded and find that digest in the manifest. Hash the manifest and confirm it equals manifest_sha256. Then read the token’s message imprint — it is the same value, and an Italian qualified authority put its signature on it at a time it chose, not one we supplied.

🔴 What this attestation says, and the boundary matters. It says those ten files existed in exactly that form no later than 00:37:29 UTC on 15 September 2026. It does not date the deliberations. Those were sealed by our own signature on 10 July and carry no outside attestation of that date — stamping a July record today and presenting it as July would be back-dating, which is the precise act this architecture exists to make detectable. The manifest carries that sentence inside the attested bytes, so it cannot be separated from the token and re-described later.

⚠️ Two limits, stated rather than left for you to hit. verify-record.js does not check this sidecar — it verifies bundles, and the attestation is a separate artefact checked with openssl. And a full chain verification needs ArubaPEC’s qualified CA root, which is not embedded in the token; it is published on the EU Trusted List. Without it openssl ts -verify will report unable to get local issuer certificate, which is a missing root rather than a bad token.

The background — what was sealed, and what it is not

Open the page →

The instructions page, with its central promise in its own words:

Our Own Machines makes an unusual promise: do not take the document’s word for anything — check the record. This page is how you do that, without trusting the platform that produced it.

It also states what the exercise does not establish: that the deliberation was wise, or that the participants were real. They were not — the members are fictional composites, authored by an AI from real sources. What is demonstrated is the integrity of the record, not the authority of its contents.

Where this gets you

Without contacting us, you can establish that these records have not been altered since they were sealed, that they were sealed by the key published alongside them, that no entry has been moved between records, and — if you pin the DID from a source you trust and confirm its keys against that DID’s own did.json — who issued them.

And since 15 September 2026 you can establish, without contacting us, that those ten files existed in exactly that form no later than 00:37:29 UTC that day — because an eIDAS-qualified Italian authority signed a statement saying so, and the token is published above.

What that still does not give you is the July date. The deliberations were sealed by our own signature on 10 July and nothing outside this estate attests to that. The qualified stamp is later than the records and says so on its face.

The sovereign, signed, sealed and timestamped record — what each of the four words means, with its limits
Seal a record, then try to break it — the same mechanism, interactive, in your browser
What we claim, and how sure we are — the full claims register, graded