The Consignment file

One file for a lot of goods. Whoever holds it can check it on their own computer, with no account and no call to us.

Available on request 27 October 2026

A lot of goods leaves one party and arrives with another, and the people on the receiving end want three answers: where the goods came from and what was done to them, who decided to send the paperwork and what was checked first, and what was invoiced. Those answers normally live in three places and are believed on trust. The Consignment file puts all three in one file and gives the holder one checker that reports, member by member, what it could prove and what it could not.

What is in it

• The Provenance record. Where the goods came from and what was done to them, as signed records for one lot.
• The Email Decision Record. Who decided to send the file, who approved it and what was checked before it went. Sending a file by email goes through the Email Decision Record and is held until a second person approves; the person who proposed it cannot be that person.
• The Attested Accounts invoice. Every field of the invoice is held as a salted hash. The file shows six fields: lot reference, quantity, unit, currency, total and issue date. Every other field stays a hash.

Each of the three is available on its own. The Consignment file is the three together. A file needs the Provenance and Email Decision Record members; the invoice is added when the owner names one that carries the same lot reference. The file ties a signed email record to the lot by that lot reference.

What “checked offline by one checker” means

The checker is one JavaScript file you can read. It needs Node.js and nothing else: no install, no account, no network. You hand it the file and it runs each member’s own checker on that member’s bytes, then prints one result.

Use the combined checking program, version 2: it checks the Provenance, Email Decision Record and invoice members, and reads a file made for the first checker in the same way. The first checker reports the Email Decision Record member but takes no key history, so it cannot reach Verified for that member. --edr-pin is the fingerprint of the key you trust for the email record. --edr-key-history is a file holding that signer’s key history, taken from the signer’s own published record. --time-anchor names a time authority root you trust, in addition to the roots the program carries.

node consignment-verifier-v2.js file.zip --edr-pin FINGERPRINT --edr-key-history key-history.json --time-anchor NAME=SPKI_SHA256 --json

What it can establish, when the file carries the material:

• that each signed record is unchanged since it was signed, and which key signed it;
• that a signed email record names the lot reference of the Provenance record;
• that the time stamps were issued by an outside authority (RFC 3161), where the records carry them;
• for the invoice, that each field shown matches its hash, that the lot commitment matches the lot fields shown, and that the signed record behind the invoice verifies.

It does not round a doubtful result up. Where a key has not been pinned by the reader, or a time stamp is missing, or a link between members cannot be derived, it says so, and its exit code differs from the code for a clean pass. It will not run a member checker whose bytes do not match the published SHA-256; you can compare the checker’s own SHA-256 with the values below before you run it.

What it does not show

• It does not show that the goods match the paper, that any lot meets any law or rule, or that any record is complete. It is not a legal opinion, an audit or a certification.
• It does not show who wrote an email. The record notes whether a person’s login or an agent’s API key was used, not who wrote the text.
• A hidden invoice field is hidden. The file shows that the field exists and has not changed, not what it says. A verified invoice says nothing about whether its figures are true.
• The list of members is not signed by the assembler, so the file does not show that nothing was left out. The invoice member carries no outside time stamp.
• “Unchanged since signing” rests on who holds the signing key and on the time-stamping authority. My Digital Sovereignty Ltd holds the signing key for most Villages.

Where it stands

The checkers

Served from this site, with the SHA-256 of each file as this site serves it. The first checks Provenance and Email Decision Record members; the second also checks the invoice member and reads a file made for the first in the same way. The Email Decision Record checker is listed because the combined checking program runs it.

• consignment-verifier.js
SHA-256 41196ba26ea603979d347e236cd57c43ac3d2a1514a198555d5551ab2468d98a
• consignment-verifier-v2.js
SHA-256 9bdf86820abef381afd036ad86013c05d1f9f65b49e6bd535d7813eded7c5fa0
• email-decision-record-verifier.js
SHA-256 fe7e54285f812bf0c770b33247801d10b3f31545b90bf2e2d65758f6adb6409e
• invoice-bundle-verifier.js
SHA-256 96ac2ac454da385d1f0b93ed2040e2bbb1959973135af57820161ad64da5111f
• provenance-verifier.js
SHA-256 eff7425271fd4ff57ac0d27e6e05944de7292c9297edde4396e239f53128618f

The draft standard MIO-STD-01 has not been adopted by any standards body, and nothing here is a conformance claim.

Read next

• Check the record yourself: the instructions, ten sealed records and the standalone verifier
• The Consignment file on mysovereignty.digital: how access works
• Provenance, the Email Decision Record and Attested Accounts: the three products
• The sovereign, sealed, signed and timestamped record: what each of the four words means, with its limits
• What we claim, and how sure we are: the full claims register, graded

AI agents compiled this page from the product pages and records of My Digital Sovereignty Ltd, and the system it describes was built and reviewed by AI agents. No person has audited either.