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
Protocol
The protocol defines the objects an issuer produces and the checks anyone can run on them, offline. The evidence bundle stays with the issuer; the registry entry the issuer signs carries no evidence.
- 5 objects: the evidence bundle, the receipt, the registry entry, the trust registry and the summaries.
- 4 checks run offline, on the files alone: structure, integrity, link and authorization.
- 57 reason codes in 11 categories, in catalog version 2.0.0.
Object model
Objects
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. It is a file: checking it needs no registry or service.
The link check confirms that it commits to this bundle.
Trust registry
The list of authorized issuers, their public keys, and the asset types and workflows each key may sign for.
The authorization check tests each signing key against it.
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
Object schemas
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 |
|---|---|---|
| change_summary | 25 | 4 |
| coverage_summary | 18 | 5 |
| lineage_summary | 17 | 2 |
| registry_entry | 23 | 19 |
| trust_registry | 10 | 10 |
| verification_receipt | 20 | 12 |
| verification_summary | 20 | 6 |
7 canonical objects. Every one is closed: a field the schema does not define is rejected rather than ignored.
Verification lifecycle
Lifecycle
An update runs the same sequence again.
- 01
Private evidence
Source documents, structured claims and workflow metadata are gathered on the issuer's side, where they stay.
- 02
Policy evaluation
The issuer's named, versioned policy checks support, coverage, freshness and conflicts. The protocol defines the record, not the policy.
- 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. The entry carries identifiers and hashes, never evidence.
- 05
Offline verification
A verifier works offline: it checks structure, integrity, the link to the registry entry and the issuer's key authorization.
Verification checks
Verification checks
Structure, integrity, link and authorization run offline, on the files alone. Transparency and anchoring need an operated log and are not implemented.
Reason-code catalog
Reason codes by category
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 party that disputes an outcome can name the code it disputes.
- Integrity12
- Offline12
- Authorization11
- Freshness6
- Policy5
- Valuation cross-check4
- Coverage2
- Vocabulary2
- Conflict1
- Evidence1
- Materiality1
By severity
- fail 19
- review 21
- warn 12
- info 5
Reason codes
Reason-code list
Each code with its category, its severity and the headline the catalog gives it. Filter by category or severity, or search by code.
57 codes, catalog v2.0.0
| Code | Severity | Headline |
|---|---|---|
BUNDLE_EXTRA_FILES | warn | Undeclared files are present, and the issuer's policy treats them as a warning. |
INTEGRITY_CHECK_FAILED | fail | The receipt cannot be cited as supporting the declared evidence. |
INTEGRITY_OFFLINE_CANONICALIZATION_FAILED | fail | The canonical input cannot be reproduced and the receipt cannot be replayed. |
INTEGRITY_OFFLINE_ENVELOPE_LINKS_MISMATCH | fail | The envelope no longer corresponds to its inner receipt and evidence. |
INTEGRITY_OFFLINE_ENVELOPE_SHA_MISMATCH | fail | The receipt's outer envelope has been altered. |
INTEGRITY_OFFLINE_EXTRA_FILES_STRICT | fail | Undeclared files are present in the bundle and the receipt scope cannot be confirmed. |
INTEGRITY_OFFLINE_FAIL | fail | The bundle fails offline verification and must not be relied upon. |
INTEGRITY_OFFLINE_INPUT_HASH_MISMATCH | fail | The receipt is not paired with the canonical input it was issued against. |
INTEGRITY_OFFLINE_MANIFEST_FILE_MISMATCH | fail | Supporting evidence has been modified after the receipt was issued. |
INTEGRITY_OFFLINE_MANIFEST_SHA_MISMATCH | fail | The bundle's index of files has been modified after the receipt was issued. |
INTEGRITY_OFFLINE_SCHEMA_INVALID | fail | A required bundle artifact is structurally invalid. |
INTEGRITY_OK | info | Bundle integrity is intact and the receipt may be cited. |
| Code | Severity | Headline |
|---|---|---|
COMPLETENESS_OFFLINE_CHECKS_SKIPPED | review | The offline verification is incomplete. |
COMPLETENESS_OFFLINE_MATERIAL_MISSING | review | Bundle is incomplete for full offline replay. |
COMPLETENESS_OFFLINE_MISSING_CANONICAL_INPUT | review | The bundle's canonical input is missing. |
COMPLETENESS_OFFLINE_MISSING_MANIFEST | review | The bundle's manifest is missing. |
OFFLINE_CANONICAL_INPUT_MISSING | review | Offline verifier cannot find the canonical input. |
OFFLINE_INPUT_HASH_NOT_VERIFIED | review | Input-hash binding could not be confirmed. |
OFFLINE_MANIFEST_MISSING | review | The bundle has no manifest and cannot be fully verified. |
OFFLINE_MATERIAL_MISSING | review | Offline verification cannot be performed in full. |
OFFLINE_REPLAY_FAILED | fail | The receipt cannot be reproduced from the bundle. |
OFFLINE_REPLAY_REVIEW | review | Independent replay finds review conditions on this bundle. |
OFFLINE_REPLAY_SKIPPED | review | Independent replay was not executed. |
OFFLINE_REPLAY_WARN | warn | Independent replay completed with warnings. |
| Code | Severity | Headline |
|---|---|---|
AUTHORIZATION_ISSUER_KEY_EXPIRED | review | The evidence is intact, but the signing key's authorization had lapsed by the evaluation date. |
AUTHORIZATION_ISSUER_KEY_NOT_YET_EFFECTIVE | review | The evidence is intact, but the signer held no authority yet at the evaluation date. |
AUTHORIZATION_ISSUER_KEY_REVOKED | fail | The evidence is intact, but the key that signed it has been revoked. |
AUTHORIZATION_ISSUER_KEY_SUSPENDED | fail | The evidence is intact, but the signing key is currently on hold. |
AUTHORIZATION_ISSUER_NOT_RECOGNISED | fail | The evidence is intact, but the signer is not listed in the trust material. |
AUTHORIZATION_SCOPE_MISMATCH | fail | The evidence is intact and the signer is authorized by the supplied trust registry, but not for this kind of asset. |
AUTHORIZATION_SIGNATURE_NOT_VERIFIED | fail | The bundle is consistent, but the registry entry's signature does not verify. |
AUTHORIZATION_SIGNING_METHOD_UNSUPPORTED | fail | The evidence is intact, but it was signed by a method outside the accepted profile. |
AUTHORIZATION_TRUST_MATERIAL_OUTSIDE_VALIDITY_WINDOW | review | The evidence is intact, but the trust material used to check it does not cover this date. |
AUTHORIZATION_TRUST_REGISTRY_AMBIGUOUS_KEY | fail | The evidence is intact, but the trust material contradicts itself about this key. |
AUTHORIZATION_VERIFIED | info | The issuer's authority verified against the supplied trust material. |
| Code | Severity | Headline |
|---|---|---|
FRESHNESS_OK | info | Evidence is current relative to the snapshot effective date. |
FRESHNESS_P1_TIMESTAMP_OOW | warn | The receipt's issuance timestamp does not match the period it attests to. |
FRESHNESS_WARNING | warn | Evidence is current but approaching staleness. |
MARK_ASOF_UNPARSEABLE | warn | Evidence date cannot be parsed and freshness cannot be evaluated. |
MARK_STALE | warn | Evidence is stale and the receipt's evidentiary basis is weakened. |
P1_TIMESTAMP_OUT_OF_WINDOW | warn | Receipt timestamp falls outside the acceptable issuance window. |
| Code | Severity | Headline |
|---|---|---|
METHOD_BINDING_MISSING | review | The valuation method is not bound to specific evidence. |
MISSING_MARK_FIELDS | review | The valuation mark is incomplete. |
MISSING_REQUIRED_INPUTS | review | The bundle is missing inputs the policy requires. |
NEEDS_REVIEW | review | The policy requires human review before this bundle can be relied upon. |
POLICY_BUNDLE_EXTRA_FILES | warn | Bundle contains files the policy does not enumerate. |
| Code | Severity | Headline |
|---|---|---|
MARK_FAR_OUTSIDE_RANGE | review | The declared valuation is materially outside the expected range. |
MARK_NEAR_BOUNDARY | warn | The declared valuation is inside but near the edge of the expected range. |
MARK_OFFSET_FROM_MIDPOINT | warn | The declared valuation sits clearly above or below the midpoint of the expected range. |
MARK_OUTSIDE_RANGE | warn | The declared valuation is outside the expected range, within a soft band. |
| Code | Severity | Headline |
|---|---|---|
REQUIRED_CLAIMS_PRESENT | info | The bundle covers every claim the policy requires. |
UNSUPPORTED_KEY_CLAIM | review | A required claim is asserted by the issuer without document evidence. |
| Code | Severity | Headline |
|---|---|---|
VOCABULARY_VALUE_INVALID | fail | The record carries a malformed category value and breaks the protocol contract. |
VOCABULARY_VALUE_UNKNOWN | review | The record names an asset type, workflow or method the reader does not recognize. |
| Code | Severity | Headline |
|---|---|---|
CONFLICTING_EVIDENCE_DETECTED | review | The bundle contains internally contradictory evidence. |
| Code | Severity | Headline |
|---|---|---|
REQUIRED_EVIDENCE_PRESENT | info | Required source documents are present and bound to their claims. |
| Code | Severity | Headline |
|---|---|---|
MATERIAL_CHANGE_DETECTED | warn | A material change in claim values is recorded. |
Structure
Layers and status
Each layer uses only the layers below it. Only the core exists today: the specification, the schemas, the conformance corpus and two verifiers. The other three layers are planned.
| Layer | What it contains | Who uses it | Status |
|---|---|---|---|
| Core | The protocol: the specification, the JSON Schemas, the reason-code catalog and the conformance corpus. Two verifiers, one in Python and one in TypeScript, written by the same maintainer and compared case by case over the corpus. The trust registry, the signed list of issuer keys and what each key may sign for. Later, an evidence transparency log. | Anyone who has to verify a record. | Preview (Alpha) Protocol, schemas, corpus and both verifiers are published. Transparency log: planned. |
| Profiles | One public, versioned profile per asset type. A profile holds the evidence model (the claims an issuer makes, the documents that support each claim, when a document is out of date, when two sources conflict, what counts as a material change) and the policy pack that applies it. Profiles for property valuations and fund NAVs. | Whoever produces receipts, and whoever verifies them: a verifier has to be able to read the policy that produced a receipt. | Planned Today the asset types and workflows are registered in versioned files in loquitur-protocol, and each issuer writes its own policy. |
| Tools | Installed and run by the party that holds the evidence. The producer applies a profile's policy pack to the evidence and writes the verification receipt, with its coverage, change and lineage summaries. Signing stays in the issuer's own HSM or KMS; the producer does not hold the key. The producer is designed so that no machine learning sits between the evidence and the receipt. The toolkit: a client for the transparency log and a publisher, with each anchoring network as an option. The dossier archive: a format to export and import a set of bundles and receipts, so they can be kept and handed over as one unit. | Issuers, fund administrators, valuers, servicers, and banks that check what they receive. | Planned Designed, not built. The producer is the first planned step. |
| Applications | Separate and optional. A console to open a dossier and read its results. Monitoring of a listing: whether updates arrive on time, and what changes between them. A hosted service. | Trading venues, banks, operations teams. | Planned Nothing in the layers below depends on them. |
The code, the schemas and the data are offered under MIT OR Apache-2.0, at your choice, and the text of the specification under CC BY 4.0. The license files in each repository are the binding text.
The planned checks on the evidence run across the layers: written in the protocol, checked by the verifiers, produced by the producer. There are two verifiers so that a disagreement between them exposes a defect in the specification or in one of them. Both were written by the same maintainer, so their agreement shows that the specification can be implemented twice consistently; it is not independent review. One reference producer is planned, in Python; a second would not add that cross-check.
What exists is the core without its log: the specification, the schemas, the conformance corpus and the two verifiers, published as an Alpha preview. There is no producer, no hosted service, no transparency log and no anchoring. The order of the planned work is on the status page, under what comes next.
Boundaries
What Loquitur does not do.
- It forms no opinion on value and does not say whether a NAV or a valuation is correct.
- It does not replace the valuer, the administrator or the auditor, or their professional judgment.
- A PASS means the evidence matches what the issuer's signed registry entry commits to. It does not mean the inputs were true.
- It does not check facts outside the bundle, and it cannot detect false data the issuer signed.
- It relies on the keys the trust registry authorizes and cannot detect a compromised issuer key or trust root.
Next
What to read next
A reviewer can read what the registry entry discloses and what can be withheld. An engineer can go to the schemas, the offline verifiers and the conformance corpus.