The files and endpoints the record-checking pages rely on, with sizes and hashes in the text of this page. Version 0.2 · 27 October 2026
Some browsing tools cannot fetch raw .js, .json or .txt files. The page lists each artefact in HTML so that its address, byte size and SHA-256 can be read without fetching it. Sizes and hashes were computed from the files in our repository and re-read against the files on 27 October 2026. 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 mysovereignty.digital/evidence.html, 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.
| Address | Bytes | SHA-256 | What a successful check shows | Beyond this check |
|---|---|---|---|---|
| agenticgovernance.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. |
| agenticgovernance.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 mysovereignty.digital. | To rule out a change on this site alone, compare the hash with the one on mysovereignty.digital/evidence.html. |
| agenticgovernance.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. |
| agenticgovernance.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 mysovereignty.digital. | To rule out a change on this site alone, compare the hash with the one on mysovereignty.digital/evidence.html. |
| agenticgovernance.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. |
| agenticgovernance.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 mysovereignty.digital. | To rule out a change on this site alone, compare the hash with the one on mysovereignty.digital/evidence.html. |
| agenticgovernance.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 pin it reports key_not_pinned. 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. |
| agenticgovernance.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 mysovereignty.digital. | To rule out a change on this site alone, compare the hash with the one on mysovereignty.digital/evidence.html. |
| agenticgovernance.digital/downloads/governance-receipt-verifier.js | 84228 | 6b48e52e16a74c55a382a5225a7e6f1f70166ccf7a4d059370a3f52ed7ad8680 | A Governance API receipt (a bare receipt, a POST response or a GET bundle) is unchanged since signing and its signature checks against the key in the tenant’s DID document, with withdrawn keys, the signer’s DID, the supersedes chain and the post-quantum sidecar all applied, and the outside RFC 3161 time-stamp token is checked against the authority roots bundled in the file. It reads Verified only with both the signature and the token. | Whether the verdict or record is right: the receipt shows what was signed and when, not that the decision was sound. Key custody is what the tenant’s DID document asserts. |
| agenticgovernance.digital/downloads/governance-receipt-verifier.js.sha256 | 97 | 24897e8e74f1a48e00530da55b6fba85767cde603cf3b01b90a4e73deff8ffe8 | 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 mysovereignty.digital. | To rule out a change on this site alone, compare the hash with the one on mysovereignty.digital/evidence.html. |
| agenticgovernance.digital/downloads/village-governance-client.js | 6906 | 74d5603fd56bce888f394b7979ea5c220678425aac087b9164b6037acee861fd | The API client, listed so its hash can be checked. | It checks no record: it is not evidence about any record. |
| agenticgovernance.digital/downloads/governance-api-openapi-v1.yaml | 72304 | 3c4610f6a59b7960eac3a761170d1802dd5b92c6bd613c2e4b6c1abb96cac1d0 | The published interface description. | Behaviour: what the service does is what its records show. |
| agenticgovernance.digital/llms.txt | 1222 | e3860936585f1ba7273f1318457fe663a0e9c97aceb10d19faff9c462d0d3705 | A short plain-text summary of the site for machine readers. | Any claim; the claims are graded on what we claim. |
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.
Status is stated in prose on what we claim and what we know and what we don’t.
consignment-verifier.js runs two member checkers and executes only bytes whose SHA-256 it has pinned. Those checkers are published on mysovereignty.digital and are also served from this site’s downloads, with the same bytes. Put these two files into a checkers/ folder inside the consignment file, and confirm each hash against the pin below:
| File | Bytes | SHA-256 pinned in consignment-verifier.js |
|---|---|---|
checkers/provenance-verifier.js | 362461 | eff7425271fd4ff57ac0d27e6e05944de7292c9297edde4396e239f53128618f |
checkers/email-decision-record-verifier.js | 197926 | fe7e54285f812bf0c770b33247801d10b3f31545b90bf2e2d65758f6adb6409e |
Source of both: https://mysovereignty.digital/downloads/; the copies here carry the same bytes. A pass under a pinned hash shows the checker is the one we named. The signature, hashing and tree code in the Email Decision Record and Provenance checkers is self-checked against published RFC vectors at startup; the limits below say what else holds them.
| Address | Key id | Key type | 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 | First 16 hex characters of the SHA-256 of the decoded public key: f0d6bef7de540b4c (1952 bytes decoded; read 22 October 2026) | That a key in a bundle 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. |
The estate root is the daily root over the Email Decision Record. It is stamped by Certum (Poland) and by 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 New Zealand server, and the response marks it as not independent. Both addresses 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, its signature and the witness signature. The outside time stamps are on the index and on the per-day address. | 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 exists. | 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. |
Each of these opens to show how a check is done and what covers each part today. They need no script.
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.
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.
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.
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.
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.
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.
See also check the record yourself and what we claim, and how sure we are.