Developers
Reading order
Seven canonical objects carry the protocol: the receipt, the registry entry, the trust registry and four summaries. Every object is closed: a field its schema does not define is rejected, so an implementation has no extension fields to handle. The evidence bundle the issuer keeps is specified apart from them.
{"object_type": "verification_receipt","schema_version": "…","bundle_id": "…","asset_type": "fund_nav | property","verification_mode": "…","verified_at": "…","policy_id": "…","policy_version": "…","status": "pass | warning | review | fail","reason_codes": "…","manifest_sha256": "…","reason_code_vocabulary_version": "…"}
- 7 canonical objects, all closed to fields their schema does not define.
- The receipt requires 12 of its 20 fields, and the registry entry 19 of its 23.
- Names only: types, descriptions and worked examples are in the schemas and the specification.
In order
Read these four in order
- 01
Scope and its limits
Loquitur records how the evidence behind a NAV or valuation was checked, not whether the NAV or valuation is right. What else falls outside its scope is on the security and limits page.
- 02
Objects and what stays private
Of the 7 canonical objects, only the registry entry is written for publication. The bundle, defined in the specification, stays with the issuer. The protocol overview shows what an entry may carry.
- 03
Current state of each component
Each component carries one release label, Preview (Alpha) or Planned. The implementation status page lists the label and the limits of each.
- 04
Verification checks
The protocol defines what each check establishes. Structure, integrity, link and authorization need no network. Transparency and anchoring, reserved and not implemented, could not be checked offline, because each asks about something recorded elsewhere.
The receipt
Receipt fields
The receipt records one check: the policy applied and its version, the outcome, the coded reasons behind it, and the digest of the file manifest the check ran over. An object missing any of these is rejected.
Identity
- object_type
- schema_version
- bundle_id
what this object is, and which version of its schema it was written against
Subject
- asset_type
the kind of asset the checked figure belongs to
The check
- verification_mode
- verified_at
how far the verification went, and when it ran
Policy
- policy_id
- policy_version
which rules were applied, and at which version, so the same check can be run again
Outcome
- status
- reason_codes
- reason_code_vocabulary_version
the result, the coded reasons behind it, and the version of the code catalog they belong to
Commitment
- manifest_sha256
the digest of the manifest listing every file the check ran over
The public entry
Registry entry fields
The entry is the object written for publication. It carries identifiers, two digests of the evidence, a salted subject reference, the policy and its version, the verdict with its reasons, and the key that signed. It carries no document, no figure and no evidence. A reviewer holding the bundle can put the two side by side. Anyone holding only the entry learns that a check happened, under which policy and with what outcome, and nothing about what was checked or which of two entries for one subject replaced the other.
Identity
- object_type
- schema_version
- registry_entry_id
- receipt_id
what this object is, and the receipt it was written for
Signer
- issuer_id
- issuer_key_id
who signed, and with which of their keys: the pair an authorization check is made against
Subject
- asset_type
- workflow
- subject_ref_hash
the asset type and workflow this entry is for, and a reference to the subject that does not name it
Commitments
- manifest_hash
- receipt_hash
two digests of the evidence, not the manifest or the receipt behind them, and a salted subject reference: all the entry says about the evidence
Policy
- policy_id
- policy_version
- reason_code_catalog_version
the rules applied and the catalog its reason codes are drawn from, both versioned
Outcome
- verdict
- reason_codes
the verdict and the coded reasons for it, so a dispute can name the one reason it contests
Disclosure
- issued_at
- privacy_classification
- disclosure_profile
when it was issued, and how much of the evidence its holder may pass on
Vocabulary
Value lists
Some fields take no free text. A closed list is fixed by the schema, and a value outside it fails validation. A registered list is a versioned file in loquitur-protocol, for the asset type, the workflow and the anchoring method. An asset type or workflow the verifier does not know makes the run REVIEW rather than PASS, and a value that is not a well-formed identifier makes it FAIL. No check reads the anchoring method in this version. Registering a value changes no schema and no protocol version.
| Field | On | List | Values |
|---|---|---|---|
| asset_type | registry_entry | registered |
|
| workflow | registry_entry | registered |
|
| anchor.method | registry_entry | registered |
|
| status | verification_receipt | closed |
|
| verdict | registry_entry | closed |
|
| disclosure_profile | registry_entry | closed |
|
| privacy_classification | registry_entry | closed |
|
Authorization
Key scope
A key in the trust registry is not authorized for everything an issuer does. The registry names the asset types and workflows each key may sign for, and the authorization check tests the signing key against them. A property entry signed with a key authorized for fund NAVs can come with an intact bundle, matching hashes and a genuine signature, and still fail, on authority. Authorization is a separate check because a reviewer responds to a missing authority differently from a hash that does not match.
Implementing
Field contracts
This page gives the names: which objects exist, what each must carry, which values a field accepts. Types, descriptions and worked examples are in the schemas and the specification, published in the loquitur-dev organization on GitHub.