Evidence index
The files and endpoints the checking pages rely on, with each address, byte size and SHA-256 written out in the text of this page. Some browsing tools cannot open raw program or data files, so nothing here needs them opened.
The page builder computed each size and hash from the files in our repository, and it publishes only a hash that agrees with the file's .sha256 sidecar. To check one yourself, download the file and run sha256sum on it: a matching hash shows you hold the same bytes as the ones listed here. What the Provenance checker checks is held to published test vectors and a conformance matrix, linked in the limits below.
The same index is published at https://agenticgovernance.digital/evidence, on a different host that we also run. The two hosts serve the same bytes, so comparing a hash across them shows whether a copy was changed on one site alone.
Files served from this site
Each is a file you can download. A line for each file sets out what a successful check shows and what lies beyond it. The hash beside a .sha256 file is the hash of that small file itself.
| Address | Bytes | SHA-256 hash | What a successful check shows | Beyond this check |
|---|---|---|---|---|
| mysovereignty.digital/downloads/verify-record.js | 181221 | c90ced27a9400a9efeeddece0dcb0fb9a70ddbe4ab8e7d16129890e361a14bb2 | The record file you give it hashes and verifies as it claims: content hashes match, each signature checks against the key carried in the record, and linked entries chain, so an entry removed from inside a chain shows. It reports the signed time attestation: the authority, its country, the time it states and the grade (the Email Decision Record and Provenance checkers check the token bytes themselves). Who issued the record is shown three ways: --verify-against-did confirms the keys against the signer's published DID document, --expect-did holds the record to a DID you obtained elsewhere, and --trust-anchor identifies a signer by certificate. With none of them the signatures are still checked and the result says the issuer was not confirmed. | The end of a chain of entries and certificate revocation: the explainers below set out what covers each today. |
| mysovereignty.digital/downloads/verify-record.js.sha256 | 83 | 68cab055ba4ae64bf4632c4bfd1ebc0740bab3103c0135c18ba90148d272f71c | The published hash of the checker, in the form sha256sum -c reads. A match shows a copy you hold is the copy this site serves, and the same file is served from agenticgovernance.digital. | To rule out a change on this site alone, compare the hash with the one on agenticgovernance.digital/evidence. |
| mysovereignty.digital/downloads/provenance-verifier.js | 362461 | eff7425271fd4ff57ac0d27e6e05944de7292c9297edde4396e239f53128618f | A Provenance dossier parses strictly, each signature checks against the key in the copy of that party's DID document that travels in the dossier and against the key fingerprint you fix for that party, the sequence numbers, daily fingerprints and inclusion proofs line up for each party, handovers between parties match, and the lot graph recomputes. It shows what each party signed, when, in what order, and that each handover was signed by both parties. The result says which of these it could and could not check. | That the goods match the records. What a party declared is that party's statement: the checker holds the file to the signatures, not the goods to the file. |
| mysovereignty.digital/downloads/provenance-verifier.js.sha256 | 89 | 133419710a7b90df15a7eb061ce84666d1802f57180eba42ad3f776f759c5a20 | The published hash of the checker, in the form sha256sum -c reads. A match shows a copy you hold is the copy this site serves, and the same file is served from agenticgovernance.digital. | To rule out a change on this site alone, compare the hash with the one on agenticgovernance.digital/evidence. |
| mysovereignty.digital/downloads/email-decision-record-verifier.js | 197926 | fe7e54285f812bf0c770b33247801d10b3f31545b90bf2e2d65758f6adb6409e | An Email Decision Record dossier's receipts are unchanged since signing, each signature checks against the key it names, the chain and the inclusion proofs hold, and each RFC 3161 time-stamp token is checked against the authority roots bundled in the file, with every certificate on its chain judged valid at the time the token states. A receipt signed under a key the tenant later withdrew counts only if a verified token dates it before the withdrawal. The record names which credential acted (a person's login or an agent's API key) and the mandate the platform cited when one was recorded; the checker verifies the signature over them. The result states what it did not examine. | Who composed the words, which no record can show. How revocation is handled today is explained below. |
| mysovereignty.digital/downloads/email-decision-record-verifier.js.sha256 | 100 | 93f7aed51e92fbcd917567b0affbdfb8f9dda7274c87e4da9741037e253a262b | The published hash of the checker, in the form sha256sum -c reads. A match shows a copy you hold is the copy this site serves, and the same file is served from agenticgovernance.digital. | To rule out a change on this site alone, compare the hash with the one on agenticgovernance.digital/evidence. |
| mysovereignty.digital/downloads/consignment-verifier.js | 57050 | 41196ba26ea603979d347e236cd57c43ac3d2a1514a198555d5551ab2468d98a | A consignment file's Provenance record and Email Decision Record each pass their own pinned checker, a signed email names the lot reference, and, for a member declared complete, the member checkers confirm that every number up to its newest daily root is present and report that root's date. | What else went with that email, whether the member list is the full set the assembler held, and whether any rule is met. |
| mysovereignty.digital/downloads/consignment-verifier.js.sha256 | 90 | ca2aae87a6765023a4a8fbb49287a8fca2d6d71e8aae9b2c3c611539014b2bd4 | The published hash of the checker, in the form sha256sum -c reads. A match shows a copy you hold is the copy this site serves, and the same file is served from agenticgovernance.digital. | To rule out a change on this site alone, compare the hash with the one on agenticgovernance.digital/evidence. |
| mysovereignty.digital/downloads/consignment-verifier-v2.js | 72864 | 9bdf86820abef381afd036ad86013c05d1f9f65b49e6bd535d7813eded7c5fa0 | The same as the checker above for a version 1 consignment file, and for a version 2 file also that the invoice member passes its own pinned checker, and whether the invoice names the same lot as the Provenance record. A key you have not pinned is reported as such, never as verified. The invoice receipt carries a signed time attestation: from Certum where the authority answered, otherwise the time the platform itself attested; verify-record.js reports which. | Whether the invoice's figures are right, which is between the parties. The Consignment file carries no daily root for the invoice member today; adding one is the next step. |
| mysovereignty.digital/downloads/consignment-verifier-v2.js.sha256 | 93 | 869995fb1e37e0469db2d5b0deb7433fcbb225c5864b8c42185bc392661cb91d | The published hash of the checker, in the form sha256sum -c reads. A match shows a copy you hold is the copy this site serves, and the same file is served from agenticgovernance.digital. | To rule out a change on this site alone, compare the hash with the one on agenticgovernance.digital/evidence. |
| mysovereignty.digital/downloads/invoice-bundle-verifier.js | 23254 | 96ac2ac454da385d1f0b93ed2040e2bbb1959973135af57820161ad64da5111f | An invoice record that shows only a chosen few fields (lot reference, quantity, unit, currency, total, date) hashes and verifies as sealed. The fields shown are the only ones in the bundle; a hidden field is a hash the shown digest commits to, so it is proved unchanged without being revealed. Run with --pin DID=sha256-of-the-signer's-key to tie it to a key you hold; without a key fingerprint fixed in advance, key_not_pinned is returned. It runs the verify-record.js beside it and confirms it is the exact build it expects. | Who holds the signing key is what your pin asserts; whether the invoice is correct is between the parties. |
| mysovereignty.digital/downloads/invoice-bundle-verifier.js.sha256 | 93 | 82291168a24c92bc7de2168a54ae9c973c16f1415f28f84667efd40d7bc950fe | The published hash of the checker, in the form sha256sum -c reads. A match shows a copy you hold is the copy this site serves, and the same file is served from agenticgovernance.digital. | To rule out a change on this site alone, compare the hash with the one on agenticgovernance.digital/evidence. |
The hash of every file is published beside it as a .sha256 file, verify-record.js included. The consignment checkers execute only member checkers whose bytes hash to a value on their built-in list; the list grows with each release and keeps every earlier published build, so a file assembled with an earlier checker keeps checking.
How the checks work
Each of these opens to show how a check is done and what covers each part today. They need no script.
How a removal from the end of a chain is detected today
Four things hold an Email Decision Record in place: a number, a link, a daily fingerprint and an outside clock.
The number. Every receipt a tenant makes takes the next whole number in that tenant's sequence, claimed by the database as the receipt is written, so two receipts never share one and none is skipped. A day root is a receipt that names the first and last number it covers and a count, and the checker accepts a day root only when its count equals last minus first plus one.
The link. The three receipts that make up one email decision each carry the SHA-256 of the receipt before it. The checker looks up every predecessor named, and one that is not in the file reads gap_in_sequence, so a receipt removed from inside a chain leaves a hole the next receipt points at.
The daily fingerprint. Each day the tenant's new receipts, by number, are hashed into one tree of the RFC 6962 shape and its root is signed as a day root receipt. Each receipt in the file carries its path up that tree, and the checker accepts a path only when it reaches the signed root. In a file declared complete, every number between the day root's first and last must then be present. Within any day whose root is in the file, a receipt removed, added or reordered is reported.
The outside clock. Each day the platform places every tenant's day root in one more tree, the estate root, signs it, and has Certum in Poland and Portugal's state authority time-stamp its digest. The checker verifies the tenant's day root is in that estate root by its path, and verifies each authority's token against the authority roots bundled in the file. Each estate root names the previous day's, so a missing day is a visible break.
What covers the end of a chain. The last receipt has nothing after it to name it, so a receipt made after the newest day root in the file is not shown by the file itself. The result names the date of the newest estate root it checked, and the estate root for that date is stamped; anything made after that date is covered by the next day's root.
How a key is pinned
A record carries the key it was signed with, so the checker can always confirm each signature is correct under that key. Who holds the key is answered one of three ways. Pin: give the checker the key's fingerprint, which you obtained from the party (their DID document, a letter, a call), and the result says whether the key in the record is that key. Resolve: --verify-against-did fetches the signer's published DID document and confirms the keys in the record against it. Certificate: for a signer identified by a certificate, --trust-anchor names a root you trust and the checker builds the chain to it. --expect-did holds a record to a DID you obtained elsewhere.
Without any of these the signatures are still checked, and the result is key_not_pinned: valid under a key the record itself supplied, issuer not confirmed. It never reads as verified, because a record whose keys had been swapped would otherwise pass. Give the checker the fingerprint, the key history from the signer's published record, and the time-stamp token for each record that claims one, and the same run reads verified or key_mismatch. If a piece is missing, the result names it: key_history_missing or timestamp_missing.
How revocation is handled today
A time-stamp token is an authority's signed statement that a digest existed at a given moment. The Email Decision Record and Provenance checkers recompute the digest from the record, open the token, confirm the digest inside matches, check the authority's signature, and walk the certificate chain to one of the authority roots bundled in the file (Certum, Portugal's Cartão de Cidadão, Aruba PEC). Every certificate on that chain must have been valid at the time the token states, and the result names the authority, the country and the time.
A tenant's DID document carries each key's history, including the time a key was withdrawn. A receipt signed under a withdrawn key counts only if a verified token dates it before the withdrawal; the time claimed inside the receipt is never enough alone.
When the platform makes a stamp it asks the authority's own servers whether the signing certificate is revoked, fetches the authority's revocation list, and stores both signed answers, as returned, beside the token. They stay checkable with openssl ocsp and openssl crl after the servers are gone. The checkers published here do not consult those lists themselves, and verify-record.js reports revocation as not checked on every run that meets a certificate signer.
What complete means here
For the checkers, a file is complete when every sequence number inside every day root it carries is present, every chain predecessor named is present, and, for Provenance, the records shown for each lot match the count the party signed for that lot in each day root. A file labelled selective is checked the same way and the gaps are reported as information rather than as faults.
Two things fall outside that: a receipt made after the newest day root in the file, and the member list of a consignment file, which is the assembler's list and is not signed by the assembler.
What the invoice check shows
An invoice is sealed as a set of salted hashes, one per field. The holder shows a counterparty only chosen fields (lot reference, quantity, unit, currency, total, date) with their salts, and the rest stay as hashes. The checker recomputes each shown field's hash, the lot commitment and the whole-invoice digest, and confirms the receipt signature under a key you pinned. A hidden field is proved unchanged without being revealed, because its hash is committed by the digest the receipt signs.
The invoice receipt carries a signed time attestation: from Certum where the authority answered, otherwise the time the platform itself attested; verify-record.js reports which. The consignment checker compares the lot on the invoice with the lot in the Provenance record.
What a .sha256 file is for
Each checker has a one-line sidecar holding its SHA-256 and its file name, in the form sha256sum -c reads. Download both into one folder and run sha256sum -c name.js.sha256: OK means your copy has the bytes listed on this page. The hash of each sidecar is also in the table, so a sidecar altered in transit shows too.
Signing identity (DID)
| Address | Key id | Type of key | Key fingerprint | What it shows when the fingerprint matches | Beyond this check |
|---|---|---|---|---|---|
| stroh.myfamilyhistory.digital/.well-known/did.json | #pq-1 | JsonWebKey, kty AKP, alg ML-DSA-65 | The first 16 hex characters of the SHA-256 of the decoded public key (1952 bytes), read from the live page on 22 October 2026: f0d6bef7de540b4c | That a key in a record is the one the tenant's DID document lists. The document also carries each key's history, including withdrawal, which the checkers apply, so a withdrawal before you looked shows in that history. | The future strength of the signing scheme, which is a property of Ed25519 and ML-DSA-65 and not of this page. This row covers #pq-1; the DID document lists the other keys. |
Estate root endpoints
The estate root is the daily root hash over the Email Decision Record. Two outside time-stamping authorities stamp each day's root hash: Certum (Poland) and Portugal's Cartão de Cidadão authority. Any registered witness may sign what it saw at /estate-root/:date/witness. One witness is registered today, our own server in New Zealand, and the response marks it as not independent. Both addresses below answered with HTTP 200 on 22 October 2026.
| Address | What it returns | What a successful check shows | Beyond this check |
|---|---|---|---|
| mysovereignty.digital/api/email-decision-record/estate-root/latest | The most recent day's root hash, its signature and the witness signature. The outside time stamps are on the index. | With the signature checked against the signing key: that this root is the one our key signed, that each tenant's day root in it covers every sequence number up to the last one that day root names, and that our witness recorded seeing it. | What a record says: that is the record's own statement. |
| mysovereignty.digital/api/email-decision-record/estate-root/index | The list of days for which a root hash exists, each with the time stamps issued over it by Certum (Poland) and by Portugal's Cartão de Cidadão authority. | Which days have a root, each root's link to the previous one (so a missing day is a visible gap), and the digest and stated time of each authority's stamp. | The token bytes. They are in the dossier an owner downloads, where the checker verifies them; serving them here is the next addition. |
How to check the estate root signature
You can check that a published estate root hash is the one our key signed, using OpenSSL 3.0 or later and Node. Nothing here needs an account.
What the signature is computed over
The signature covers the UTF-8 text of a JSON object with exactly three keys, date, previous_root and root, written in that order, with no spaces and no newline at the end. There is no prefix. The signature is a plain Ed25519 signature, published as hex. The signing key is published as 32 bytes of hex at the key address below.
The commands
Run these in an empty folder. Change the date to check a different day. The commands check roots signed by the current key, which the key address returns.
D=2026-10-24
B=https://mysovereignty.digital/api/email-decision-record
curl -s $B/estate-root/$D -o root.json
curl -s $B/estate-root-key -o key.json
node -e 'const r=require("./root.json");process.stdout.write(`{"date":"${r.date}","previous_root":"${r.previous_root}","root":"${r.root}"}`)' > signed.bin
node -e 'const fs=require("fs"),r=require("./root.json"),k=require("./key.json");fs.writeFileSync("sig.bin",Buffer.from(r.signature,"hex"));fs.writeFileSync("pub.der",Buffer.concat([Buffer.from("302a300506032b6570032100","hex"),Buffer.from(k.public_key_hex,"hex")]))'
openssl pkey -pubin -inform DER -in pub.der -out pub.pem
openssl pkeyutl -verify -pubin -inkey pub.pem -rawin -in signed.bin -sigfile sig.bin
sha256sum signed.binA correct signature prints Signature Verified Successfully. Change one character of the root hash and it prints Signature Verification Failure and exits with code 1. An AI agent ran these commands on the root for 24 October 2026: the signature verified, and failed once one character was changed. The last line prints the SHA-256 of the signed bytes, which is the value a time-stamp over this root must carry.
Time-stamp tokens and the witness
Each day's root hash is stamped over the SHA-256 of the same signed bytes. The index lists, for each stamp, the authority, the time it states where it states one, and the SHA-256 of the token. The token bytes travel in the dossier an owner downloads, where the checker verifies them against the authority roots; serving them here, with the witness key, is the next addition.
The key and the roots come from the same site. The key response carries the key's SHA-256 fingerprint in a field called fingerprint_sha256. To be sure the key belongs to My Digital Sovereignty Ltd, compare that fingerprint with a copy you obtained another way before you rely on it.
Limits that apply to all of it
- The hashes are computed from our own repository by the page builder, which publishes only a hash that agrees with the file's sidecar. They are our statement until you compute them from the bytes you fetched.
- A matching hash shows you hold the bytes listed here. Whether a program is correct is a separate question. The signature, hashing and tree code in the Email Decision Record and Provenance checkers is self-checked against published RFC vectors at startup and held to the platform's own output by cross-check vectors, and the Provenance checker is held to the published test vectors and conformance matrix. A second implementation, written by an independent AI agent from the format specification alone and without sight of these checkers, agrees with them on every signature, canonical form, manifest, chain link, inclusion proof and day root of the published sample records. It also verified all 22 published estate-root signatures, one of them by the OpenSSL recipe on this page as well. The published Email Decision Record checker reads Verified only when a key is pinned, a key history is supplied from outside the file, and every record that claims an outside time-stamp has a time-stamp token it accepted. Otherwise it names the missing piece, timestamp_missing or key_history_missing, and exits 4. The published sample records carry no tokens and no key history is supplied with them, so they read key_history_missing and timestamp_missing. A reproduction by someone outside the company would be welcome.
- Record signing has moved to a separate host, reached over mutually authenticated TLS, and can be split between custodians.
- A fetch that fails in your tool is a limit of the tool, not necessarily an error at our end. Say which you saw.
Direction and continuity
Our stated intention is to move what we have built towards open source, in stages: the checking programs and standards first, then the substrate, then the Governance API. The reason is continuity. A record that has to stay checkable for years should not depend on one company, one founder or an escrow agreement. Code that others can run and inspect removes the succession question and the source-escrow question together. What we sell is the running of it: hosting in New Zealand and the EU, key custody, assurance, support and continuity. Nothing has been released, no date is set and no licence is fixed.
Our direction is a hybrid design: business records stay on infrastructure under New Zealand or EU control, and only fingerprints are committed to an outside network. The network we are working with is Midnight, a federated network. Anchoring on Midnight. Status: Built. The hash of our signed daily root can be recorded once a day on Midnight's Preview test network, in a contract that accepts one value per date. Only that hash goes onto the shared ledger. The receipts issued by the Governance API and the records of the MIO° Conduct Record are built to join that daily root once we switch it on. An anchor shows that a value was recorded under a date key. It does not answer whether any record is true or complete. It is an attestation by our service key. It covers records held on our OVH servers only. There is no anchoring on the real Midnight network and no partnership.
Who made it
AI agents built these checking programs and this page, and AI agents reviewed them, working under John Stroh's direction. Changes to the checkers are tested by an agent that did not write them, with the new tests shown to fail against the previous build before they pass against the new one, and mutant runs check that the tests can fail. No person has audited this software or this page.
Publisher: My Digital Sovereignty Ltd, Amberley, New Zealand.