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 the invoice with only the figures you choose to show 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 checker and the invoice export are all built and deployed. Switched on per Village by arrangement.

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.
This first checker covers the Provenance and Email Decision Record members. The combined checker, version 2, also checks the invoice member, and is linked below.

Download the checker

node consignment-verifier.js file.zip --json

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

151ef62443703208f75cf5c9a569542a46eaf3f890f3385629bc4c3374615c16

Download the combined checker, version 2

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

1ffb7fa4d51ea61af3cd02ce3e6c82dc9b5b57ce5892dcd8f962f852697597c5

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; switched on per Village by arrangement.

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 holder chooses which fields to show, from this list only: lot reference, quantity, unit, currency, total and date. Every other field stays a hash, and no value for it is in the file.

Built and deployed; switched on per Village by arrangement.

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 checker, 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 checker 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

By arrangement. Access to evaluate it 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.
e466a1a61b5088efeacec2097820805979196f5998bcf17c227a542a5f40926c
consignment-verifier.js The consignment file checker.
151ef62443703208f75cf5c9a569542a46eaf3f890f3385629bc4c3374615c16
consignment-verifier-v2.js The combined consignment file checker, version 2, which also checks the invoice member.
1ffb7fa4d51ea61af3cd02ce3e6c82dc9b5b57ce5892dcd8f962f852697597c5
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 testing against is Midnight. Today that is a test-network attestation contract using test data, which records that our own checker accepted a proof. There is no production anchoring 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

Access to evaluate it is by arrangement: a one-time link, issued at our discretion.