Reading order
Four steps to read before the first line of code.
Seven canonical objects carry the protocol: the receipt that records what was checked under which policy, the entry that commits to it, the trust registry of keys allowed to sign, and four summaries. The evidence bundle the issuer keeps is specified apart from them. Every object is closed: a field its schema does not define is rejected, so there is nothing to implement beyond what the specification names.
In order
Scope comes first, verification levels last.
- 01
Scope and its limits
Loquitur records how a figure's evidence was checked, not whether the figure is right. What else falls outside its scope is on the disclosure and review page.
- 02
Objects and what stays private
Of the 7 canonical objects, only the registry entry leaves the issuer. The bundle, defined in the specification, stays behind. The protocol overview shows what an entry may carry.
- 03
Current state of each component
Each component carries one release label (candidate, private preview or future) and a stated condition for changing it. The implementation status page lists both.
- 04
Verification levels
The protocol defines what each level proves. L0 to L3 need no network; L4 and L5 cannot be checked offline, because each asks about something that happened elsewhere.
The receipt
What a verification receipt must carry.
The receipt is the record of 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. Required means required. An object missing any of these is rejected, and a verifier that accepted it would be checking something the protocol does not define.
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, 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
What crosses into the registry entry.
The entry is the only object that leaves the issuer. Read it for what is absent: no document, no figure, no evidence of any kind. What crosses: identifiers, three hashes, the policy and its version, the verdict with its reasons, and the key that signed. 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. They learn nothing about what was checked, nor 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, not the manifest or the receipt behind them: 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 attack one reason rather than the result
Disclosure
- issued_at
- privacy_classification
- disclosure_profile
when it was issued, and how much of the evidence its holder may pass on
Closed lists
Where a value has to come from.
Some fields take no free text: they draw from a list the schema fixes, and a value outside it fails validation. Two of those lists set the protocol's scope: it covers the asset types and workflows below and no others. Adding to either means a new version of the protocol, not just a longer list.
| Field | On | Accepts |
|---|---|---|
| asset_type | registry_entry |
|
| workflow | registry_entry |
|
| status | verification_receipt |
|
| verdict | registry_entry |
|
| disclosure_profile | registry_entry |
|
| privacy_classification | registry_entry |
|
Key scope
What one issuer key is allowed to sign.
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 L3 checks 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, not integrity. That is why L3 is a level of its own. A reviewer would respond to a missing authority differently than to a hash that does not match.
Implementing
The names are here; the field-level contracts are not.
The names give an implementer the shape: which objects exist, what each must carry, which values a field accepts. Types, descriptions and worked examples are in the schemas and the specification, and neither is published yet. Tell us which object you would implement first, and what you would need from it.