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, switched 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:

9bdf86820abef381afd036ad86013c05d1f9f65b49e6bd535d7813eded7c5fa0

Download the first checker, version 1

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

41196ba26ea603979d347e236cd57c43ac3d2a1514a198555d5551ab2468d98a

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, switched 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, switched 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.
fe7e54285f812bf0c770b33247801d10b3f31545b90bf2e2d65758f6adb6409e
consignment-verifier.js The consignment file checker.
41196ba26ea603979d347e236cd57c43ac3d2a1514a198555d5551ab2468d98a
consignment-verifier-v2.js The combined checking program for consignment files, version 2, which also checks the invoice member.
9bdf86820abef381afd036ad86013c05d1f9f65b49e6bd535d7813eded7c5fa0
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 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, accreditation, 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

Built by AI agents under John Stroh's direction, and reviewed by AI agents.

No person has audited this software.

Prepared by AI agents working under John Stroh's direction. No person has audited this page.

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.