Provenance

Signed records for every step of an export chain, checked by the buyer in a browser

Each party in an export chain, from grower to processor, exporter and buyer, signs its own records of a lot, and each giver sends its records on with the lot. A buyer checks the whole chain in a browser, offline, with no account on anyone's platform.

Available on request for New Zealand exporters, their suppliers and their buyers.

Try the tamper demo Check a dossier yourself How to ask for it

In brief

Provenance keeps a signed record of each step a lot of produce goes through, from the grower to the buyer.

It is for New Zealand exporters, the businesses that supply them, and the importers and buyers they sell to.

A buyer checks every party's records in a browser, on its own machine, with no account and no connection to us.

To ask for it, use the contact page. Prices are on the price list.

Published by My Digital Sovereignty Ltd. Last updated 14 October 2026

What Provenance does

Provenance is a record of what happened to a lot of produce on its way from the grower to the buyer, kept by the businesses that handled it. Each of these is a claim the conformance register holds to a test:

When a lot passes from party to party, each giver sends its own signed records on with the lot, so the last holder's file shows every party back to the first, and an altered or substituted pack is refused.
A handover is two records: the giving party's proposal and the receiving party's acceptance, both naming the same terms. The page checks that both are in the file and that each is signed by its own party.
A new lot can be derived from named input lots; the check rebuilds the lot graph and reports an input lot that is not in the file.
A wrong step is put right by a correction that names it; the earlier record stays, and the check shows both.
The dossier a holder downloads carries the published checker, byte for byte, with its SHA-256, and a README in five languages.
One tenant's lots, chains and records are not readable by another tenant; an id from another tenant answers exactly as an unknown id does.

It is built for growers, processors, exporters and buyers in New Zealand export chains, and for the auditors, regulators and buyers overseas who need to check what those businesses recorded.

What it does for you

For an exporter

From 30 December 2026, a large or medium EU importer of New Zealand beef must file a due diligence statement under the EU Deforestation Regulation that names every establishment where the cattle were kept, and keep the information for 5 years; most micro and small importers follow from 30 June 2027. New Zealand is on the EU's low-risk list, but the locations are still required.

The importer files the statement, not the exporter. What the exporter can offer is a record the importer checks for itself, in place of answering questionnaire after questionnaire.

Commercial detail stays yours: a quantity or a plot's location is sealed as a commitment and opened only when you choose, to the recipient you name.

Beta When you leave, you take a full export of your records first; after a short window in which you can cancel, the platform deletes its own copy, and the copies your buyers already hold stay theirs.

For an importer or buyer

An evidence pack built from the supplier's own signed records sets each element the deforestation statement asks for beside the place it is evidenced, with the establishments and the mass balance of the lots.

You check every party's records in a browser on your own machine, with no account and no connection to us, which a supplier's spreadsheet or portal cannot offer.

For a regulator or an auditor

The same file shows, record by record, who signed it, when an outside authority stamped it, whether anything has changed since and whether anything is missing.

It does not show that what a party recorded is true; that, and the legal weight a record carries, are for the reader and the user to judge.

For the New Zealand government and its agencies

It costs less to rely on records that carry their own proof than on assertions: an agency can check a dossier without asking the platform or the exporter to vouch for it.

We know of no time-stamping authority in New Zealand and of no statutory scheme to recognise one, so the outside authorities used today are based in Europe, and the records say so. Records are held in New Zealand or the European Union, by the region chosen when the Village was set up.

Sovereign, signed, sealed, time-stamped

Sovereign

Each business keeps its own records in its own Village.

An outside time-stamping authority sees only a fingerprint of each record. A dossier holds the records of the lot it is for and the records its givers sent on with the lot; the organisation's other lots stay out of it.

Signed

Each record is signed by the party that made it, with that party's own key. The page checks every signature against the key in that party's key document, which travels in the file.

Sealed

Each party numbers its own records in order and seals each day's records under one signed day root, which also states how many records the party made for each lot that day.

Provenance never edits or deletes a sealed record; a correction is a new record that points to the one it replaces, and both stay visible.

Time-stamped

Each record is time-stamped by an outside authority, which sees only a fingerprint; when no authority answers, the record is still signed and says so, and a later day root carries the stamp.

What a seal does, and what it does not

A seal shows which key signed a record, what was signed and, with an outside time stamp, when it existed. The check shows whether the record in front of you is the one its party signed.

It does not show that what the party stated is true, who the party is, or that the party recorded everything. How far a record can be relied on depends on who stated it and how it was signed, which is what the label below shows. The evidence-strength label

Who said it, and how the record says it was signed: the evidence-strength label

Every record says who stated it and how it was signed, and the check shows that label with every record. The check works the label out from two signed fields of the record; a file whose copy of the label says otherwise is reported.

Who stated it: three sources

The party's own statement: Stated by the party that made the record, about its own activity.
An instrument file the party supplied: Taken from an instrument file (a weighbridge ticket or a sensor log) that the party fingerprinted and supplied. The page checks the fingerprint, not the instrument.
Another party's attestation: Recorded by another party on the platform (a different organisation's DID), about a lot that party does not hold here.

How it was signed, as the record states it: three ways to hold the key

Key held by the Village: Signed with the organisation's key, held by its Village under a standing authorisation its owner gave on 3 November 2026, valid to 2 November 2027.
Key split with the Village: Signed jointly: the signature needs 2 of 3 key holders, one of them the Village. Neither the organisation nor the Village can sign alone.
Key held by the organisation's own custodians: Signed with key shares held by the organisation's own custodians. The Village holds no share.

The dates and the numbers in these texts are an example: the label of a real record names the dates of the standing authorisation it was signed under, and the number of key holders its arrangement needs.

The nine labels a record can carry: one source with one way of holding the key
Source	Key held by the Village	Key split with the Village	Key held by the organisation's own custodians
The party's own statement	The party's own statement · Key held by the Village	The party's own statement · Key split with the Village	The party's own statement · Key held by the organisation's own custodians
An instrument file the party supplied	An instrument file the party supplied · Key held by the Village	An instrument file the party supplied · Key split with the Village	An instrument file the party supplied · Key held by the organisation's own custodians
Another party's attestation	Another party's attestation · Key held by the Village	Another party's attestation · Key split with the Village	Another party's attestation · Key held by the organisation's own custodians

All nine labels, in full, as the check prints them

Source: Stated by the party that made the record, about its own activity. Signing: Signed with the organisation's key, held by its Village under a standing authorisation its owner gave on 3 November 2026, valid to 2 November 2027.
Source: Stated by the party that made the record, about its own activity. Signing: Signed jointly: the signature needs 2 of 3 key holders, one of them the Village. Neither the organisation nor the Village can sign alone.
Source: Stated by the party that made the record, about its own activity. Signing: Signed with key shares held by the organisation's own custodians. The Village holds no share.
Source: Taken from an instrument file (a weighbridge ticket or a sensor log) that the party fingerprinted and supplied. The page checks the fingerprint, not the instrument. Signing: Signed with the organisation's key, held by its Village under a standing authorisation its owner gave on 3 November 2026, valid to 2 November 2027.
Source: Taken from an instrument file (a weighbridge ticket or a sensor log) that the party fingerprinted and supplied. The page checks the fingerprint, not the instrument. Signing: Signed jointly: the signature needs 2 of 3 key holders, one of them the Village. Neither the organisation nor the Village can sign alone.
Source: Taken from an instrument file (a weighbridge ticket or a sensor log) that the party fingerprinted and supplied. The page checks the fingerprint, not the instrument. Signing: Signed with key shares held by the organisation's own custodians. The Village holds no share.
Source: Recorded by another party on the platform (a different organisation's DID), about a lot that party does not hold here. Signing: Signed with the organisation's key, held by its Village under a standing authorisation its owner gave on 3 November 2026, valid to 2 November 2027.
Source: Recorded by another party on the platform (a different organisation's DID), about a lot that party does not hold here. Signing: Signed jointly: the signature needs 2 of 3 key holders, one of them the Village. Neither the organisation nor the Village can sign alone.
Source: Recorded by another party on the platform (a different organisation's DID), about a lot that party does not hold here. Signing: Signed with key shares held by the organisation's own custodians. The Village holds no share.

Whether anyone else spoke to it: corroboration

For each lot the check also says, point by point (origin, handling, quantity and inspection), whether another party that did not hold the lot recorded an attestation about it. This is worked out from the records, never signed.

Uncorroborated: Only the records of the parties that held the lot speak to this; no other party on the platform has recorded an attestation about it.
Corroborated: Another party on the platform, which did not hold the lot here, recorded an attestation about this point.
Contested: Another party on the platform, which did not hold the lot here, recorded an attestation that this point failed.

The page knows that an attestation was signed by a different organisation's key, by a party that held no record of the lot on the platform. It does not know that the two organisations are independent: one operator running two organisations could attest about its own lot under the second. The label shows two keys, not two independent operators.

How the key is held: three arrangements are supported

An organisation chooses how its signing key is held. By default the Village holds it under a standing authorisation the owner gives. An organisation can instead split the key with the Village, so the two must sign together, or split it among its own key holders with no share held by the Village. In both split arrangements a missing share means nothing is signed. The split arrangements are built and have been tested. An organisation using one first needs its key holders named and its key generated with them.

Every business starts with the first arrangement, in which Village (our hosted service) holds the signing key. A sole-trader grower therefore needs no equipment of its own. An organisation that wants a split arrangement chooses it; the platform does not require a split arrangement of any organisation.

A Village signs nothing for an organisation without a standing authorisation that covers the kind of record and the date. The owner gives it after signing in again with a passkey or a two-step code; a password alone is refused. It lasts at most twelve months, can be withdrawn at any time, and both the grant and the withdrawal are signed records.

Under either split arrangement the Village key is never used in place of a missing share: if a share is missing, nothing is signed.

Giving the authorisation, step by step

The owner chooses what the authorisation covers (steps, handovers, day roots, attestations, key events) and for how long, up to twelve months.
The owner reads and ticks the three statements below.
The owner signs in again with a passkey or a two-step code.
The authorisation is sealed as a record of its own, time-stamped like any other, and it travels in the organisation's dossiers.

Before the first standing authorisation the owner ticks three statements, set out below, and the ticks are sealed inside the authorisation.

The legal framing of your records, including what you record, on what basis, and how you describe it to others, is your responsibility. My Digital Sovereignty Ltd provides the system and holds the participant register on your instructions.
A record, once sealed, is never edited or deleted; a mistake is put right by a correction that points to it.
Erasure removes personal data and salts held outside the seal; fingerprints inside sealed records remain, and copies already shared cannot be recalled.

A key that is withdrawn, rotated or declared compromised is recorded in a signed key event. From then on the key signs nothing new, and what it signed before stays checkable.

Try it: change one byte, and see the check say so

This takes the published sample dossier for a synthetic honey chain, from the apiary through a processor and an exporter to the buyer, and checks it with the published checker. Then it changes one byte of one signed record, in a copy held in this page, and checks again. The parties are invented: each is a did:example name, which belongs to no business.

The demo runs the published checker in a worker inside this page. Nothing it checks is sent anywhere.

The demo runs in your browser and needs JavaScript switched on.

The check page does the same with any dossier you give it, and shows each record, each party and each handover.

Open the check page

Time stamps, authority by authority

Each record asks Certum, in Poland, for a time stamp. For an organisation whose order includes qualified time stamps, ArubaPEC, in Italy, is asked as well, and each authority's token is kept separately.

The authorities Provenance asks, and what the trusted lists record about each
Authority	When it is asked	Qualified status, as the trusted lists record it
Certum (Asseco Data Systems S.A.), Poland	For every record and every day root.	Not shown as qualified on the trusted lists the checker carries. The Polish trusted list (sequence 162, issued 18 September 2026) was read as well. the list
ArubaPEC S.p.A., Italy	As well, for an organisation whose order includes qualified time stamps.	Recorded as a qualified time-stamping service on the Italian trusted list (sequence 224, issued 24 September 2026). the list
New Zealand	Not yet: no authority exists.	In development

The trusted lists were read on 13 October 2026. A list is the member state's own; the EU List of Trusted Lists points to each.

The check labels a time stamp qualified only when a party in the file has confirmed the authority against its member state's trusted list and the trusted list the checker carries says the same; any other time stamp is labelled not verified as qualified.

Each organisation keeps its own register of time-stamp authorities. Its owner confirms an authority against the official trusted list of the authority's member state; the confirmation is a signed record that travels in the organisation's dossiers, and a link that is not the official list for that state is refused.

A day root states how many authorities it needs and how many answered, and a day root that claims a time stamp the file does not carry is not shown as verified.

The checker does not yet check whether an authority's stamping certificate was revoked, and it says so in its result.

Regulations: what each adapter is, and how far it has got

Each row shows its status, read from the conformance register, and the date its rules were last checked, with the official sources read. A status of Beta or Live is printed only when its tests pass.

Live: Used in a live export with a customer, with passing conformance tests and a sample dossier.
Beta: Built and tested, and offered by arrangement; not yet used in a live export.
Scaffolded: A mapping and a sample exist as data; no export is built yet.
Roadmap: Planned; nothing is built yet.
Not applicable: The law does not cover this kind of product.

EU Deforestation Regulation: supplier evidence pack for cattle and beef Beta

Beef (ex 0201 and ex 0202) is in scope. Cattle leather was removed from the Regulation from 18 September 2026, so no leather chain is offered; frozen cattle tongues are added from 30 December 2027.

The Regulation applies to large and medium operators from 30 December 2026, and to micro and small operators from 30 June 2027.

New Zealand is benchmarked low risk, so due diligence is simplified, but geolocation is still required; for cattle it is every establishment where the cattle were kept.

The EU importer, not the New Zealand exporter, submits the due diligence statement. The pack is evidence for that importer, from its supplier.

Field list as in the 2023 Regulation; whether the 2025 amendment changes it is not yet checked, and the pack is not validated against the Commission's V3 schema. The Commission's 2026 review may change these requirements.

Rules last checked 13 October 2026: Regulation (EU) 2023/1115; Regulation (EU) 2025/2650; Delegated Regulation (EU) 2026/2102; Implementing Regulation (EU) 2025/1093

New Zealand MPI export requirements Roadmap

Provenance carries evidence alongside an MPI certificate; it does not replace one.

We have not found published data formats for MPI's systems, and no mapping to MPI Trade Certification is built.

Rules last checked 13 October 2026: MPI: replacing our trade certification systems; IPPC ePhyto

A buyer's own profile Roadmap

A buyer publishes, as data, what it expects of its suppliers: the steps, the evidence and how each is signed. It is planned, and nothing of it is built.

No regulation: there are no official sources to check.

Corporate Sustainability Due Diligence Directive: an information-request response pack Roadmap

Directive (EU) 2026/470 limits the Directive to companies with more than 5,000 employees and more than 1.5 billion euros turnover, from 26 July 2029.

Nothing under it applies before July 2029. What an in-scope buyer may ask of a supplier is narrow; a dossier a buyer can check itself is the form that fits.

Rules last checked 13 October 2026: Directive (EU) 2026/470

Digital Product Passport (Ecodesign for Sustainable Products Regulation) Not applicable

The Regulation does not cover food, feed, or living plants and animals, so no Digital Product Passport is offered for food products.

Rules last checked 13 October 2026: Regulation (EU) 2024/1781, Article 1(2)

By industry

The record engine is the same for every product group; what a sector adds is its own steps, evidence and checks.

Product groups, their status in the conformance register, and what exists for each
Product group	Status	What exists
Honey	Beta	A honey chain built from invented data, from apiary to buyer, runs end to end under the honey profile; its sample dossiers can be checked by anyone. Provenance carries evidence alongside MPI's own export certificate and does not connect to MPI's systems or to laboratory software.
Beef	Beta	A beef chain from the first farm to an EU importer runs under the beef profile. The EU deforestation evidence pack for the importer is built from it.
Dairy	Beta	A dairy profile and an example chain from two farms by tanker to a processor, an exporter and an EU importer, with sample dossiers to check, are available as a Beta; live use is for the pilot.
Kiwifruit	Roadmap	Planned; the first version will be an invented example for testing.
Other product groups		Added as customers need them: see below.

Beta The EU deforestation evidence pack for cattle and beef.

A New Zealand beef chain, from the first farm to an importer in the EU, is sealed under one sector profile, beef_nz_v1, and the importer's dossier verifies in the offline check.

Cattle and beef only: the beef profile refuses a leather tariff heading, and the pack says that leather and other derived products ceased to be in scope on 18 September 2026.

Adapts to other product groups

A sector profile is data that the shared record engine reads: the steps a sector records, the evidence it attaches and the tariff codes it may seal. A new product group is mostly a new profile, not a new application, and we add profiles as customers need them.

If your product group is not here yet, tell us what your buyers ask for.

Every claim, held to a test

Every claim on this page names an entry in the conformance register, and the build leaves out any claim whose entry is not passing.

The conformance register lists every claim the product makes, every limit it states and every privacy test, each with the tests that hold it. The matrix is built from a run of those tests: an entry passes only when every test named for it ran and passed.

Entries in the register: 238
Passing: 223
Tests named but not all passing: 0
No test yet (planned or roadmap): 15
Matrix generated: 14 October 2026

The full matrix: every entry, its status, its result and the titles of its tests (JSON)

Sample dossiers

Sample dossiers can be downloaded and checked, each listed in samples.json with what it carries and the result to expect: the four-party sample carries no outside time-stamp token, so every check passes except the time; the honey samples carry time stamps from a test authority the checker does not trust; each altered copy, with one byte of one signed record changed, is shown as changed.

Each sample is published with its SHA-256, so the copy you download can be compared with the one listed here. The descriptions are in English; a commitment, which they mention, is a salted fingerprint of the value.

four-party-sample.json A lot of honey handed from a grower to a processor, an exporter and a buyer, each record signed with an Ed25519 key made for this sample. The parties are did:example DIDs, a documentation convention; none is a business. SHA-256 f83833bd85784cad2efc28a29c7218a3e99c6cbd8745ffb5e9cfad9584c23906
tamper-sample.json The same dossier with one byte of one signed record changed: in the grower's first step 1ef06e94-4605-45a1-add9-7074f5ada3dd, byte 589 of its signed bytes (a digit of the month it says the step happened) is "0" where the party signed "1". Its readable copy was changed to agree, so only the signature shows the change. SHA-256 ccf5e81a4c4325c2199c17d5992b462a52a577f1e12db3dfd1896ccdffd0b434
honey-chain.json A synthetic honey chain built through the platform's own services: an apiary harvests two lots and hands both to a processor, which extracts each, blends the two into a new lot, tests and packs it and hands it to an exporter, which ships it to a buyer. This is the buyer's dossier. The processor signs jointly with a key split between it and its Village; the other parties sign with keys their Villages hold under standing authorisations. Every step was sealed under the honey_nz_v1 profile, and the quantities each holder chose to disclose are opened. The parties are did:example DIDs, a documentation convention; none is a business, and every quantity, number and file is made up. The time stamps come from a test authority, so the check page reports the times as not established (see test_time_authority). SHA-256 bf0e1d3dcbbbea9adcb6b671d06962051c6dc2cfcbcf3b159221775daf10c3a0
honey-chain-altered.json The honey dossier with one byte of one signed record changed: in the processor's pack record aee42280-a41a-422f-a106-35546dfd76fd, byte 742 of its signed bytes (a digit of the month it says the step happened) is "1" where the party signed "0". Its readable copy was changed to agree, so only the signature shows the change. SHA-256 dc235595360b22119cdbe225b36a978ff408b56d24d036daa130351c661952ac
honey-chain-incomplete.json The honey dossier as the platform writes it when a party earlier in the chain left its time-stamp tokens out of what it passed on, to keep within the size limit: the apiary's 8 tokens are not in the file, and the file says so (pack_omissions). Every record still checks; the file cannot be complete. SHA-256 d6d590889e85331816326c6938a4ebe246c0882067cef764a7956a445a5f3ec6
beef-chain.json A synthetic New Zealand beef chain built through the platform's own services: a farm begins a mob of steers and hands it to a finishing farm, which begins a second mob, declares both finished and ships them to a processor. The processor slaughters the two lots into one carcass lot, chills it, bones it into two cut lots, tests and packs the boneless lot and hands it to an exporter, which ships it to an importer in the EU. This is the importer's dossier. The processor signs jointly with a key split between it and its Village; the other parties sign with keys their Villages hold under standing authorisations. Every step was sealed under the beef_nz_v1 profile, and the quantities each holder chose to disclose are opened, so the slaughter and the boning can be added up. The establishments' geometries are commitments only. The parties are did:example DIDs, a documentation convention; none is a business, and every quantity, number and file is made up. The time stamps come from a test authority, so the check page reports the times as not established (see test_time_authority). SHA-256 678f0f52867717ac9e553f67ada146b7a04a5fe3d5ee5657afa3805189614de7
beef-chain-altered.json The beef dossier with one byte of one signed record changed: in the processor's pack record af4d068a-1815-410c-95c6-ed5006191c02, byte 739 of its signed bytes (a digit of the month it says the step happened) is "1" where the party signed "0". Its readable copy was changed to agree, so only the signature shows the change. SHA-256 c83d443cf599015e063f184371d2bef905303243296ab1203756f6b2edb6d66d
beef-chain-incomplete.json The beef dossier as the platform writes it when a party earlier in the chain left its time-stamp tokens out of what it passed on, to keep within the size limit: the first farm's 5 tokens are not in the file, and the file says so (pack_omissions). Every record still checks; the file cannot be complete. SHA-256 b57a4895af83b7dd57e41f43b87cc452a9899517157fe7ecc1f8227937f6d4e0
dairy-chain.json A synthetic New Zealand dairy chain built through the platform's own services: two farms each collect their milk into a lot and hand it, by tanker run, to a processor. The processor weighs both in, merges them into one processing lot, splits that lot into a cheese lot and a milk powder lot, tests and packs the cheese and hands it to an exporter, which ships it to an importer in the EU. This is the importer's dossier, so it holds the cheese lot and the lots it was made from; the milk powder lot is a sibling that stays in the processor's own records. The processor signs jointly with a key split between it and its Village; the other parties sign with keys their Villages hold under standing authorisations. Every step was sealed under the dairy_nz_v1 profile, and the quantities each holder chose to disclose are opened, so the merge and the cheese run can be added up in mass. The parties are did:example DIDs, a documentation convention; none is a business, and every quantity, number and file is made up. The time stamps come from a test authority, so the check page reports the times as not established (see test_time_authority). SHA-256 e0a65d82d3e86ef1dddfbd404de7484920173fa9209b11a492da656caff1bf75
dairy-chain-altered.json The dairy dossier with one byte of one signed record changed: in the processor's pack record e4786974-1ed0-4990-bb12-924a4daa81bf, byte 739 of its signed bytes (a digit of the month it says the step happened) is "1" where the party signed "0". Its readable copy was changed to agree, so only the signature shows the change. SHA-256 01e63b10d4cb3c914c4e4420c33a6520c1dcd6c28544966a2580651f879b8cee
dairy-chain-incomplete.json The dairy dossier as the platform writes it when a party earlier in the chain left its time-stamp tokens out of what it passed on, to keep within the size limit: the first farm's 6 tokens are not in the file, and the file says so (pack_omissions). Every record still checks; the file cannot be complete. SHA-256 45069d669948d832d54454853d5ac03f65a0e8696db8dc1b38dcc86bb29bb043
attestation-delivered.json A grower's dossier for one lot, built through the platform's own services. An inspector (did:example:attest-inspector) inspected the lot and signed an attestation about it; the platform delivered the attestation to the grower (did:example:attest-grower), and the grower's own chain recorded receiving it, with no action by the grower (an attestation receipt). The file carries the grower's records, the receipt, and the inspector's segment with the attestation and the day root that includes it. The checker shows that the receipt is met. The parties are did:example DIDs, a documentation convention; none is a business. The time stamps come from a test authority, so the check page reports the times as not established (see test_time_authority). SHA-256 700e1af0bcca1e22b70875178fdb1c61c096bb352d94ac4ba7c318484679081b
attestation-delivered-stripped.json The attestation dossier with the inspector's attestation (e1bb27e3-61df-4000-b22d-db33e3ee820b) taken out of the inspector's segment, together with its inclusion proof and the inspector's count entry for the lot, and the segment relabelled as a selection. Every record left still checks, but the grower's chain records receiving that attestation, so the file reads incomplete (attestation_receipt_unmet). SHA-256 6e07daef96ada7350b37522f84dc6589cf7b7f7cacb3fc3d9470420778f66496
queued-capture.json A packer's dossier for one lot, built through the platform's own services. Its packing step was captured on a device with no connection and sent two hours later, when the device reconnected; the platform sealed it then. The checker prints both times (record_capture_time) and says that the device's clock was not checked. The party is a did:example DID, a documentation convention. The time stamps come from a test authority, so the check page reports the times as not established (see test_time_authority). SHA-256 0afda3c8025c891df81a481b1b5e669d9ac34ec663b83752e4bca9dbd95e36c7

The list of samples, with the key fingerprints to check them against (JSON)

Legal weight

What a Provenance seal is designed to do

Each Provenance record is signed, sealed and time-stamped. Together these are designed to produce evidence that a record is the one its party signed, who signed it, and when. A buyer, auditor or regulator can check this offline, without an account and without trusting us.

How time stamps are treated in the EU

Under Article 41(2) of the eIDAS Regulation (Regulation (EU) 910/2014, as amended by Regulation (EU) 2024/1183), a qualified electronic time stamp enjoys a presumption that the date and time it shows are accurate and that the data it is bound to was intact at that time. Under Article 24a(6), a qualified time stamp issued in one member state is recognised as qualified in every other. Under Article 41(1), a time stamp that is not qualified is not to be denied legal effect, or refused as evidence, only because it is electronic or not qualified; it carries no presumption.

Text read 13 October 2026: Regulation (EU) 910/2014 as amended by Regulation (EU) 2024/1183, consolidated text

Where Provenance stands today

The authorities that time-stamp Provenance records, and what the trusted lists record about each, are set out under Time stamps above. Only a time stamp from an authority whose qualified status is verified is labelled qualified. Anything else is labelled plainly as not verified as qualified. Verified means a party in the file recorded that it checked the authority's stamping certificate against the trusted list, on a date, with the link, and signed that record; and the checker's own built-in list, dated, says the same. The seal is designed to support evidence in EU contexts. Whether a record is accepted, and how much weight it carries, is decided by the court, regulator or buyer assessing it.

New Zealand

We know of no time-stamping authority in New Zealand, and New Zealand has no statutory scheme for recognising time-stamping authorities. We are working to establish one (NZ Timestamp Certification Authority: in development). Until one exists and is recognised, the seal's legal weight in New Zealand and in other jurisdictions outside the EU is a matter for local law and the assessing party.

The Contract and Commercial Law Act 2017 recognises electronic signatures where they identify the signatory, show approval and are as reliable as appropriate (section 226). A Provenance record signed by a Village on an organisation's standing authorisation is the organisation's instruction carried out by its service provider; the Act's presumption of reliability for a signature under the signatory's sole control (section 228) is not claimed for it. An organisation that holds its own key shares is in a different position, and the label on each record gives, as the record states it, which applies.

What the seal cannot do on its own

A seal shows a claim was made, by whom, and when. It does not show the claim was true. How strongly a claim is supported depends on who attested it and how it was signed. Every record carries an evidence-strength label so you can see that for yourself.

Seek legal advice

This is a description of how the product works, not legal advice. Evidentiary weight depends on the jurisdiction, the dispute and the facts. If you rely on a Provenance record in a regulatory, contractual or legal setting, take advice from a lawyer in the relevant jurisdiction.

What we do not claim

Provenance is designed to give you strong, independently checkable evidence. These are the limits of that claim, and for each one, where the product shows it.

We do not claim a seal proves the underlying facts are true. A signed and time-stamped statement that a plot is deforestation-free is evidence that someone made that statement. It is not proof that it is correct. Truth depends on the source, and the evidence-strength label shows whether a claim is the party's own statement, a separate organisation's signed record, or taken from an instrument file the party supplied. Shown by: the evidence-strength label with every record
We do not claim that using Provenance meets any legal obligation. Provenance carries evidence a party can use for obligations such as the EU Deforestation Regulation, the Corporate Sustainability Due Diligence Directive and MPI export requirements, where they apply to you. It does not replace your own due diligence. Shown by: each adapter's status, and the date its rules were last checked
We are not a certification, accreditation or assurance body and we issue no certificate of any kind. Provenance records the fingerprint of a certificate issued by others and does not substitute for it. Planned: the check page labelling a certificate's evidence "fingerprint of a certificate issued by others".
We do not claim that any regulator, court or buyer will accept a record. Acceptance is their decision. Shown by: "What this check did not establish", under every result on the check page
We do not provide legal, regulatory or compliance advice. Shown by: "Seek legal advice", here and at the head of the check page's printed report
We do not claim every time stamp is qualified. Qualified status is shown per authority and per token, and only where verified. Shown by: the qualified line for each time stamp on the check page, and the authority table above
We do not claim a New Zealand time-stamping authority exists today. It is an initiative in development. Shown by: the printed report's list of authorities, which ends "New Zealand: none"
We do not claim regulatory coverage beyond what is marked Live. Adapters marked Beta, Scaffolded or Roadmap are not complete, and regulatory requirements change. Each adapter shows the date its rules were last checked against official sources. Shown by: the status label and last-checked date on every adapter
We do not claim records can be erased. Provenance never edits or deletes a sealed record; a correction is a new record that points to the one it replaces, and both stay visible. We keep personal data out of sealed payloads where possible, and where it must be referenced we use commitments, so erasure obligations can be met outside the seal. Please read the note on personal data before putting personal data into your records. Shown by: the check page's line for a commitment whose data its party erased, read from that party's signed erasure record
We do not claim the system is infallible. Keys can be lost or compromised, and time-stamp authorities can fail or be distrusted. Provenance is designed to detect and record these events, but it cannot prevent every one. Records signed by Village-custodied keys rely on our custody controls, and the label says so. Shown by: signed key events, the withdrawn-key line on the check page, and how each record says its key was held
We do not claim to verify the physical world. We cannot confirm that the goods in a container are the goods described. Device and third-party attestations narrow that gap but do not close it. Shown by: the instrument-file label, "The page checks the fingerprint, not the instrument."
The presumption of section 228 of the Contract and Commercial Law Act 2017 is not claimed for a signature made by a Village on an organisation's standing authorisation. Shown by: the label on every record, which gives how the key was held as the record states it
Outside the EU and New Zealand the record is evidence on its own terms, for local law to weigh. Planned: the printed report naming only the jurisdictions of the authorities whose stamps are in the file.
Whether an unopenable fingerprint counts as anonymous is not stated. Shown by: the check page's line for an erased commitment, "Commitment unopened (data erased)", which does not use the word
The legal framing of your records is your responsibility. Shown by: the first of the three statements the owner ticks before the first standing authorisation
Some records must be kept by law for a period, such as the EU Deforestation Regulation's five years. Shown by: each retention hold in the owner console, with its legal basis, its source and the date the source was read
Your records, keys and participant register are held in New Zealand or in the European Union, according to the region chosen when your Village was set up. Planned: "Records held in New Zealand" or "in the European Union" on the Provenance settings page.
Proofs about a location without revealing it are on the roadmap; no page claims them. Shown by: the row marked Roadmap in the table of what goes where
Copies already shared cannot be recalled. Shown by: the sealed disclosure record the owner confirms before coordinates or salts leave, naming what, to which kind of recipient and when

Limits the check itself states

How a key was held is what the record states: the check cannot see how the key was actually held, and the label says so wherever it is printed.
A compromise time a party states for its key is shown as a stated time, not verified, and every record signed with that key is listed as signed before or after it, or not shown either way; none is quietly relabelled.
A standing authorisation granted days before the records that name it can be shown on its own day root, without the day roots between, in a selection only; such a day root must show no lot record and must show the authorisation the records name, and the check names it on a line.

How Provenance handles personal data and erasure

The short version

Provenance never edits or deletes a sealed record. That is what makes it trustworthy. Privacy law, however, gives people rights to have their data corrected or erased. Provenance resolves this by design: personal data is kept out of the sealed record wherever possible, and the seal holds only a cryptographic commitment to it. The personal data itself lives outside the seal, where it can be corrected, restricted or erased.

Personal information is kept out of signed records: every field of a signed record is a closed list, a date, a digest, a DID or a six-digit tariff code, and the schema refuses to load a free-text field.

What goes where

What is inside the sealed record, what is outside it, and how far each part is built
	Inside the sealed record	Outside the seal (erasable)	Status
Names, contact details, addresses	No. The organisation's decentralised identifier (a name the party chose for its key) and its stated role.	Yes, in the participant register	Built
Signing identity	The published half of the signing key, and the party's role	The link between that key and a named person	Built
Plot geolocation	A commitment.	The raw coordinates, held by the data owner	Built
Plot geolocation: proofs about a location without revealing it	Roadmap	—	Roadmap
Documents and photos	A fingerprint only	The files themselves	Built
Business facts (weights, dates, batch identifiers, certificate numbers)	Yes: dates, step types and product classes as they are; weights and certificate, seal and batch numbers as salted fingerprints.	Not applicable	Built

Erasing a lot's salt: built.
Erasing a participant's register entry (the label your organisation gives a counterparty) and a plot's geometry, with their salts, and the sealed record of each erasure: built.
Evidence salts and quantity openings: held by your organisation, not by the platform, so the platform has none of them to erase.

A lot's salt is kept apart from the lot's records, and a salt that has been destroyed can never be read again.

Names, contact details and addresses are kept in the participant register, outside the seal. Correcting them changes nothing that has been sealed.

A registration number or a coordinate that a sealed record commits to is not edited in the register. It is put right by a new commitment with a new salt, linked from a sealed correction that points to the one it replaces.

Erasing a participant removes their register entry and the geometry of their plots, with the salts of their registration numbers and plots, so the fingerprints in sealed records can no longer be opened. The erasure is recorded in a sealed event that names classes and fingerprints and holds no personal data.

Each erasure is written first to a ledger kept in two places, the database and a file on the host's disk outside it. When a system is restored, the ledger is replayed and every erasure is applied again before any Provenance route serves. If neither copy can be read, nothing is served.

A retention rule is held as data: its legal basis, its period, its source and the day it was read. An erasure request on data a rule covers is held, with the basis recorded and use restricted to that purpose, and carried out when the period ends. Data no rule covers is erased at once.

The geometry of each production plot is held on behalf of its owner, with a salt of its own. A sealed step carries only a commitment to it.

Raw coordinates and salts leave only when an owner discloses them. The owner confirms with a passkey or a two-step code, a sealed record of what, to which kind of recipient and when is made first, and the opening goes only to that kind of recipient.

Free text that looks like personal data (an email address, a telephone number, a New Zealand or European identity number, a coordinate pair) is refused by the privacy routes unless the owner overrides it with a stated reason, and the override is recorded. No sealed field takes free text.

How a commitment works

A commitment is a fingerprint of the data combined with a random secret value, called a salt. The fingerprint goes into the seal, and the data and salt are stored separately. Anyone holding all three can check that the data matches what was sealed. Without the salt, the fingerprint is designed to reveal nothing, and the salt is long and random so that guessing likely names or coordinates does not recover it.

What happens when someone asks for erasure

We delete the personal data and its salt from the participant register and storage. Built.
The sealed record stays intact, so the chain still verifies. What remains is a fingerprint that can no longer be linked to the person or reproduced.
The deletion is itself recorded as a sealed event, with no personal data in it. The erasing party's own history shows it. A copy already given to a buyer is theirs and does not change. Built.

This approach is sometimes called crypto-shredding. It is designed to make the link to the person unrecoverable in practice. Whether a remaining fingerprint counts as anonymous is a legal question that regulators have approached differently, so we do not state that it does.

Corrections

Inaccurate personal data is corrected outside the seal. If a sealed business fact is wrong, the correction is a new, linked amendment that points to the original. Both stay visible, so a verifier can see what was changed and when.

What we cannot undo

Copies already shared. A buyer or regulator who downloaded an evidence bundle holds their own copy. We cannot recall it. Evidence packs and dossiers already given are such copies. For this reason, bundles are built to contain commitments rather than raw personal data, and disclosure of identity or location is a deliberate choice by the data owner.
Data you put into the seal directly. Today no sealed field takes free text: every one is a closed list, a date, a fingerprint, an identifier or a tariff code. A sealed text field added later will carry the warning "This will be sealed permanently. Don't enter personal information."
Records you must keep by law. Erasure rights are not absolute. Some obligations, such as the EU Deforestation Regulation's 5-year retention (Articles 4(3), 9(1) and 12(5)), may require data to be kept for a set time. Where a legal obligation applies, we keep the minimum required, restrict use to that purpose, and erase when the period ends. Read 13 October 2026: Regulation (EU) 2023/1115
Time stamps. Time-stamp authorities receive only a fingerprint of the record, never its contents, so no personal data leaves your chosen region through time-stamping.
Lot references in linked email records. Where an organisation's subscription includes linked artifacts, an Email Decision Record can name a lot by a reference. That field is signed, sequenced and rolled into the day's sealed root, so the reference itself cannot be erased. Two emails that name the same lot carry the same reference, so they are linkable to each other. Treat it as a permanent fingerprint. The reference is SHA-256 over the lot reference, the chain head and the day root. It reveals nothing by itself, and it identifies a lot only to someone who holds that lot's Provenance data. If the lot's openings are later erased, the reference can no longer be recomputed and the checker reports it as unopened, which is not a fault of the email record. A consignment file already built is a snapshot and goes stale after an erasure. The link means only that a signed email record names this lot reference, never that the dossier was attached to that email. The field is off unless the organisation's subscription includes it.

Where data is held

Your records, keys and participant register are held in New Zealand or in the European Union, according to the region chosen when your Village was set up. Time-stamp authorities receive only a fingerprint.

Laws this is designed with in mind

The New Zealand Privacy Act 2020 (including the principles on retention, access and correction) and the EU General Data Protection Regulation (including the rights to erasure and rectification). This note describes the design. It is not legal advice, and it does not mean that any particular use meets the law.

What we recommend

Keep names, contact details and raw coordinates in the participant register, not in sealed fields.
Share commitments rather than raw location data unless a buyer or regulator needs it.
Tell the people whose data you record how it is used and what cannot be undone.
Decide who may disclose identity or coordinates, and record that decision.

The checker, its fingerprint and its terms

The checker's SHA-256 is published, and a copy of it can be hashed with any SHA-256 tool and compared.

The format of the evidence bundle is published, with test vectors, and the published checker meets every vector.

The checker's source is published so you can read what it does, and its fingerprint is published so you can see the copy in your dossier is the one we published. Publication is not a licence: the terms on which you may run it are those of the order under which the dossier was made.

provenance-verifier.js · SHA-256 · command-line version · the bundle format and test vectors

Who is responsible for the legal framing

The legal framing of your records, including what you record, on what basis, and how you describe it to others, is your responsibility. My Digital Sovereignty Ltd provides the system and holds the participant register on your instructions.

For data a participant enters about its own business, the participant decides what to record and whether it has a lawful basis to. The owner of each organisation confirms this before the first standing authorisation, as the first of the three statements above. Nothing on this page is legal advice.

How to ask for it

Provenance is available on request. Tell us about your chain through the contact page: what you export, who you sell to, and what your buyers ask of you. We reply to arrange a time to talk.

Prices are on the price list.

There is no self-service signup. Evaluation access is by invitation: a one-time link, issued at our discretion. The check page and the sample dossiers need no account.

For New Zealand exporters: a New Zealand time-stamping authority

In development

My Digital Sovereignty Ltd is working to establish a time-stamping authority for New Zealand. We know of no such authority in New Zealand today, and New Zealand has no statutory scheme for recognising one; the authorities used today are in the European Union.

We have approached a number of potential private-sector entities, and the Christchurch Chamber of Commerce, to help open a dialogue with MBIE. We are also exploring an alternative architecture for core components using Midnight and associated services.

A New Zealand authority would put the time on an exporter's records under New Zealand jurisdiction, beside the European ones an EU buyer relies on. Provenance keeps a place for it in its list of authorities.

If your organisation, an industry body or a government agency would use such an authority, or wants a say in how it is set up, talk to us.

Talk to us about a New Zealand authority