The consignment file

One file that anyone holding it can check offline.

A consignment file puts the signed supply-chain records for one lot, the signed record of who decided to send them, and an invoice that shows only the lot reference, quantity, unit, currency, total and issue date into a single file. Anyone holding the file can check it on their own computer, with no account and no connection to us.

Where it stands: assembling the file, sending it by email, the invoice record, its offline checker, the combined checking program and the invoice export are all built and deployed. Available on request, turned on per Village.

Download the checker Read about Provenance Read about the Email Decision Record Read about Attested Accounts

What it does

Four parts, each with its own status.

The platform assembles the file

An owner of a Village that has Provenance and the Email Decision Record can have the platform assemble a consignment file for a lot. The file carries a Provenance dossier and an Email Decision Record dossier, and a signed email record is tied to the lot by the lot reference. When the owner names an invoice that carries the same lot reference, the file can carry that invoice as a third member. The assembly step stores nothing.

Built and deployed.

A checker that anyone can run offline

The checker is one readable JavaScript file. It runs each member's own checker on that member's bytes, with no network, and prints one result. It refuses a member checker whose bytes do not match the published SHA-256.

Built and deployed.

It needs Node.js only.
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.

Download the combined checking program, version 2

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

SHA-256 of the combined checking program, version 2:

a142f8dc0011feedacfb948a2dee1ca7bafb25f331825252f6188b82be50fde0

Download the first checker, version 1

SHA-256 of the first checking program, as this site serves it:

d595bc2b694acc9e61ca399fcaf1ab25f0db61e5f503e2633b0983ee78148822

Sending it by email, with a second person

An owner can propose sending a consignment file to one outside recipient. The proposal goes through the Email Decision Record and is held until a second person approves it; the person who proposed it cannot be the one who approves. It is then released through the existing release route.

Built and deployed; available on request, turned on per Village.

An invoice that can be partly hidden

The invoice member is built on Attested Accounts. Every field of the invoice is held as a salted hash. The file shows these fields and no others: lot reference, quantity, unit, currency, total and issue date. Every other field stays a hash, and no value for it is in the file.

Built and deployed; available on request, turned on per Village.

A separate offline checker, invoice-bundle-verifier.js, linked below, recomputes the hashes of the fields shown, recomputes the lot commitment, and checks the signed record behind the invoice.
A combined checking program, consignment-verifier-v2.js, checks the invoice member together with the other two, and still reads a file made for the first checker in the same way.
An invoice export produces the invoice member from an invoice in Attested Accounts.
The two routes that assemble and send a file accept an optional invoice, and then produce a file with three members.

What anyone holding the file can check, offline

That each signed record in the file is unchanged since it was signed, and which key signed it.
That a signed email record names the lot reference of the Provenance dossier. The checker says which links it could and could not derive, and under which key.
That the time stamps on the records were issued by an outside time-stamping authority (RFC 3161), when 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.
That the checker is the file described here: compare its SHA-256 with the value on this page.

What it does not show

It does not show that the goods match the paper, that any lot meets any law or rule, that any record is complete, or who wrote an email. A login or an API key is recorded; the author of the text is not.
The list of members in the file is not signed by the assembler, so the file does not show that nothing was left out.
A hidden invoice field is hidden. The file shows that the field exists and has not changed, not what it says.
The invoice member carries no outside time stamp, and the combined checking program reads none from it.
The result "unchanged since signing" depends on who holds the signing key and on the time-stamping authority. My Digital Sovereignty Ltd holds the signing key for most Villages.
When the checker reports the invoice member as verified, that says nothing about whether the figures on the invoice are true or whether the goods match them.
It is not a legal opinion, an audit or a certification.

How access works

Available on request. Evaluation access is a single one-time link, issued by John Stroh at his discretion. There is no self-service signup.

Ask about the consignment file

Check the files behind this page yourself

Each of these is a file you can download and read. Compare its SHA-256 with the value shown.

verify-record.js The offline checker for a single signed record.
c90ced27a9400a9efeeddece0dcb0fb9a70ddbe4ab8e7d16129890e361a14bb2
provenance-verifier.js The Provenance checker.
eff7425271fd4ff57ac0d27e6e05944de7292c9297edde4396e239f53128618f
email-decision-record-verifier.js The Email Decision Record checker.
1cec4e7661f7e11605ca63317aeb868b2415aac852011ed1cb9ad9c0a2e0f52b
consignment-verifier.js The consignment file checker.
d595bc2b694acc9e61ca399fcaf1ab25f0db61e5f503e2633b0983ee78148822
consignment-verifier-v2.js The combined checking program for consignment files, version 2, which also checks the invoice member.
a142f8dc0011feedacfb948a2dee1ca7bafb25f331825252f6188b82be50fde0
invoice-bundle-verifier.js The invoice checker.
96ac2ac454da385d1f0b93ed2040e2bbb1959973135af57820161ad64da5111f

The signing identity of the founding Village, which carries two ML-DSA-65 key entries, is published here:

stroh.myfamilyhistory.digital/.well-known/did.json

Direction

MDSL intends to release Village Gateway as open source. This is an intention only: nothing has been released, no licence has been fixed, no date is set and no stage has been named.

Business records stay on infrastructure in New Zealand or the EU, and only fingerprints leave it. A Village hosted in the EU can turn daily sealing on. Its day's records then join our signed daily estate root, and the hash of that root is the one value the anchoring contract on Midnight mainnet takes for a date. Only that hash goes onto the ledger. The published estate-root index lists every root with its stamps and any anchor made; the anchors made so far are on Midnight's Preview network, and none is on mainnet yet. Governance API receipts and MIO° Conduct Record records can join the same daily root. An anchor shows that a value was recorded under a date key; it does not show whether any record is true or complete.

Who made it

No person has audited this software.

Prepared by AI agents working under John Stroh's direction.

Publisher: My Digital Sovereignty Ltd, Amberley, New Zealand.

Ask about the consignment file

Evaluation access is by invitation: a one-time link, issued at our discretion.