Protocol model

Private evidence. Public commitments.

Loquitur separates the evidence basis of an asset or financial claim from the public commitment surface used to check integrity, policy identity, reason codes and lineage without disclosing private material.

Review object modelReview compliance boundary

Protocol objects

Bounded objects. Clear disclosure.

Each object has a defined role and status label. Public commitments stay intentionally smaller than private evidence bundles.

bundle

Issuer-controlled private package for documents, claims, canonical inputs, policy context and replay material.

Private by default; kept confidential to the issuer across the registry-preview surface.
receipt

Structured verification result carrying status, policy identity and version, reason codes, manifest and policy-pack hashes, and the time it was verified. The public registry entry calls the same fact `verdict`; the names differ by surface, deliberately.

A portable verification output, informational for review context.
registry_entry

Minimal public commitment to receipt material and lineage metadata without exposing the private evidence bundle.

Sandbox/default-safe website preview, scoped to demonstration.
policy

Policy ID, version and reason-code catalog context used to explain how the receipt outcome was produced.

Traceability layer that documents how the outcome was produced.
lineage

Supersession and snapshot relationship model across bundles, receipts and public commitments.

Explains update and supersession relationships.

Verification lifecycle

Receipt before commitment.

The sequence is deliberately staged: private support first, structured output second, minimal public commitment last.

1

Prepare private evidence

Evidence, claims, canonical inputs and workflow metadata are structured inside an issuer-controlled bundle.

2

Evaluate policy context

Support, coverage, freshness, conflicts and material-change context are evaluated under an explicit policy identity.

3

Issue a receipt

The result becomes a verification receipt with status, reason codes, policy version and cryptographic references.

4

Commit minimal public material

A public registry-entry model commits to the receipt without exposing raw evidence or sensitive values.

5

Verify offline

A verifier reads the bundle with no network access and checks four things: its structure, its file and manifest integrity, its cryptographic link to the registry entry, and whether the issuer's key was authorized to sign it.

Verification modes

One receipt, three ways to check it today.

A receipt can be checked for structure and integrity from the bundle alone; linked cryptographically to its public commitment; and checked for issuer authorization against a trust registry. All three run offline, with no network and no dependency on us. A fourth path — looking a record up in a public registry — is specified and not built: it is waiting on a deployment and on how a subject reference is derived, not on a transparency log.

offline

A verifier reads a bundle with no network access, recomputes every file digest and the manifest hash, and rebuilds the canonical input under RFC 8785 to confirm the bundle is internally consistent.

Levels L0 and L1. Proves the bundle has not been altered since it was sealed; proves nothing about who sealed it. Like the two checks below, it runs with no network access — every level up to L3 is offline.
link

A verifier holding both the private bundle and the public commitment confirms the cryptographic link between them — the core commit-and-reveal check.

Level L2. Binds a specific bundle to a specific registry entry, so neither can be swapped for another.
authorization

A verifier checks the issuer's secp256k1 signature over a domain-separated envelope, then checks that key against a trust registry: active, revoked, suspended, expired, not yet effective, or outside its permitted scope.

Level L3. Distinguishes a failure of authority from a failure of integrity, which matters because the remedies differ. The trust-registry root signature is computed and reported; what is not shipped is a pinned production root, so by default an unpinned root is refused rather than assumed valid. A counterparty who obtains a root out of band can supply it with --trust-root and get a full L3 result today.
inclusion

Proving an entry appears in an append-only transparency log, and that the log head is anchored where it cannot be quietly rewritten.

Levels L4 and L5, neither implemented. RFC 6962 Merkle inclusion and consistency proofs exist as primitives; no log is operated and no anchor is live.

Verification workflow

The protocol verification steps.

Five compact steps carry the verification flow from issuer-held evidence to a public-safe commitment.

1 / 05

Private portable package containing the evidence basis, canonical inputs, claims, policy context and replay material.

Evidence bundle. PREVIEW. Private portable package containing the evidence basis, canonical inputs, claims, policy context and replay material.
2 / 05

Policy-governed checks over support, coverage, freshness, conflicts and material changes.

Policy evaluation. PREVIEW. Policy-governed checks over support, coverage, freshness, conflicts and material changes.
3 / 05

Structured result object containing verdict, reason codes, policy identity, hashes and timestamp context.

Verification receipt. PREVIEW. Structured result object containing verdict, reason codes, policy identity, hashes and timestamp context.
4 / 05

Minimal public reference that commits to a verification receipt and the integrity of the private evidence boundary.

Public commitment. SANDBOX. Minimal public reference that commits to a verification receipt and the integrity of the private evidence boundary.
5 / 05

Version relationship across bundles, receipts and registry entries to make supersession and material changes explicit.

Snapshot lineage. PREVIEW. Version relationship across bundles, receipts and registry entries to make supersession and material changes explicit.

Next review path

Protocol detail connects to compliance posture.

The protocol model explains objects and lifecycle. The compliance page explains privacy-by-design, auditability, traceability and the no-raw-sensitive-data-on-chain boundary.

Compliance & TrustDeveloper surfaces