Developer docs preview

Protocol docs for integration review.

Orientation for engineers reviewing the protocol before any integration discussion.

Browse docs mapBack to developers

Core pattern

Private bundles. Public commitments. Replayable checks.

This is orientation material: public-safe context, integration boundaries and preview-status guidance. It is not an API reference, a production portal or a partner handoff.

Docs index

Start with the protocol boundary.

Condensed here as public-safe orientation: identity, two-layer architecture, registry-entry boundaries and verification posture.

identity

Loquitur governs the evidence behind external marks or NAV updates. It does not compute prices, issue tokens or replace compliance review.

What Loquitur is. A verifiable-record protocol for evidence about real-world and financial assets: private evidence kernel plus public commitment registry. Tokenized workflows are one application; the offline path works identically for assets that were never tokenized. Loquitur governs the evidence behind external marks or NAV updates. It does not compute prices, issue tokens or replace compliance review.
architecture

The public layer should let another party check a link without turning confidential evidence into public data.

Two-layer architecture. Private bundles, claims, canonical inputs and policy results remain issuer-controlled while public entries expose minimal commitments. The public layer should let another party check a link without turning confidential evidence into public data.
commitment

The registry entry is not a document repository and must not disclose asset addresses, valuation amounts, documents or canonical inputs by default.

Registry entry. A minimal public record for receipt identifiers, manifest hashes, policy identity, verdict, reason codes and lineage pointers. The registry entry is not a document repository and must not disclose asset addresses, valuation amounts, documents or canonical inputs by default.
verification

L4 inclusion proof and L5 anchor finality are not implemented, and the trust-registry root signature is not verified because no production root is pinned. An unpinned root is refused rather than assumed valid.

Verification quickstart. Verification runs offline over a bundle: structure (L0), file and manifest integrity (L1), the bundle-to-entry link (L2) and issuer authorization against a trust registry (L3). L4 inclusion proof and L5 anchor finality are not implemented, and the trust-registry root signature is not verified because no production root is pinned. An unpinned root is refused rather than assumed valid.

Review workflow

Read docs in the order claims can break.

Read identity first

Start with the protocol identity and non-goals so integration language does not drift toward tokenization, valuation, generic oracle or compliance claims.

Map private and public surfaces

Identify what stays inside an evidence bundle, what becomes a receipt, and what may safely be committed publicly.

Check status labels

Treat schemas, verifier, OpenAPI, SDK and registry preview as separately labeled surfaces rather than one public-ready product claim.

Review limitations before demos

A demo may show public-safe commitments and local checks, but it must not imply production anchoring, public registry availability or external assurance.

Public-safe limits

Docs clarify limits before capability claims.

No stable public API or public SDK handoff.

No production registry, live anchoring or anchor-finality claim.

No valuation correctness, legal approval, compliance approval or investment recommendation.

No external audit, SOC 2, SLA, bug bounty or certification claim.