Evidence bundle
The issuer's package: source documents, structured claims, canonical inputs and the asserted figure, listed in a manifest of file hashes.
Stays with the issuer. A counterparty sees it only if the issuer shares it.
Protocol model
From private evidence to a signed public commitment.
The evidence bundle holds the documents, the canonical inputs and the asserted figure, and it stays with the issuer. The verification receipt records the policy, status and reason codes of a check. The registry entry, signed by the issuer, commits to that receipt with hashes, identifiers and the verdict, and carries no evidence. The trust registry says which issuer keys may sign one.
Object model
Each object does one job, and the evidence is kept apart.
The registry entry is written for publication, and the trust registry says whose signature on it counts.
Verification receipt
The result of a check: the status, the reason codes it follows from, the policy and version applied, the manifest and policy-pack hashes, and the verification time.
Not signed itself. The signed registry entry commits to its hash.
Registry entry
Identifiers, manifest and receipt hashes, policy identity, verdict and reason codes, signed by the issuer.
The verifier confirms its link to the bundle at level L2.
Trust registry
The list of authorized issuers, their public keys, and the asset types and workflows each key may sign for.
The verifier checks each signing key against it at level L3.
Summaries
The verification, coverage, change and lineage summaries, all derived from the bundle. The last two record what changed since the previous verification and which earlier receipt a new one supersedes.
Held on the private side, with the bundle.
Specification index
What each object may hold, and nothing more.
The schemas define the verification receipt, the registry entry, the trust registry and the summaries derived from the bundle. The evidence bundle itself is defined by field contracts in the specification.
| Object | Fields | Required | Additional properties |
|---|---|---|---|
| change_summary | 25 | 4 | closed |
| coverage_summary | 18 | 5 | closed |
| lineage_summary | 17 | 2 | closed |
| registry_entry | 23 | 19 | closed |
| trust_registry | 10 | 10 | closed |
| verification_receipt | 20 | 12 | closed |
| verification_summary | 20 | 6 | closed |
7 canonical objects. Every one is closed: a field the schema does not define is rejected rather than ignored.
Verification lifecycle
A registry entry is signed only after the receipt exists.
An update runs the same sequence again.
- 01
Private evidence
Source documents, claims and workflow metadata are gathered on the issuer's side.
- 02
Policy evaluation
A named policy, authored and versioned by the issuer, checks the evidence for support, coverage, freshness, conflicts and material changes. The protocol defines the record of that outcome, not the policy itself.
- 03
Receipt
The result becomes a verification receipt, which records the manifest hash of the bundle it was checked against.
- 04
Registry entry
The issuer signs a registry entry that commits to the receipt's hash.
- 05
Offline verification
A verifier reads the bundle offline and checks its structure, its file and manifest integrity, its link to the registry entry, and the issuer's key authorization.
Verification modes
L0 to L3 need nothing but the files in hand.
Each level adds one check to the one before, and up to L3 the files alone are enough. L4 and L5 would add a transparency log and an anchor.
Reason-code catalog
Every outcome says why.
Codes come from a versioned catalog, and a verification summary's status and a registry entry's verdict must each match the most severe code cited. A dispute could then go after the specific reason it contests.
- Integrity12
- Offline12
- Authorization11
- Chain anchor6
- Freshness6
- Policy5
- Valuation cross-check4
- Coverage2
- Conflict1
- Evidence1
- Materiality1
By severity
- fail 27
- review 17
- warn 12
- info 5
Next
Reviewers and engineers have different next questions.
A reviewer would ask what the registry entry discloses and what can be withheld. An engineer would look for the schemas, the offline verifiers and the conformance corpus.