Developer surface
Integration surfaces remain status-labeled.
Loquitur is shaped as API/SDK-first verification middleware, but public developer wording stays conservative: preview, candidate, private preview or sandbox. Nothing on this page should be read as a stable public API or production package claim.
1{2 "object_type": "registry_entry",3 "registry_entry_id": "re_••••",4 "receipt_id": "rcpt_••••",5 "issuer_id": "iss_••••",6 "manifest_hash": "sha256:••••",7 "receipt_hash": "sha256:••••",8 "policy_id": "policy.rwa.review",9 "verdict": "pass",10 "reason_codes": ["INTEGRITY_OK", "AUTHORIZATION_VERIFIED"],11 "anchor": null12}Surface ledger
Limits travel with the surface.
Developer artifacts are preview/candidate materials for integration review. They are not SLA-backed endpoints, externally audited packages or stable public contracts.
Integration posture
Disclosure comes before developer marketing.
1.Status labels travel with every surface.
2.Private evidence is not exposed through public registry-preview routes.
3.Verifier claims remain scoped until release gates prove higher levels.
4.Integration review starts from policy, evidence and disclosure boundaries, not generic API marketing.
Docs bridge
Docs before endpoints.
The docs surface should orient engineers around identity, architecture, registry commitments and verification limits before any generated client or endpoint list is treated as stable.
Use the docs subpage to orient engineers before discussing endpoints or generated clients.
Keep protocol identity, two-layer architecture, registry-entry boundaries and verification modes visible during integration review.
Treat the docs surface as a public-safe bridge, not as an API reference, production portal or partner handoff.
Readiness checks
Integration readiness is a set of gates.
The developer surface is useful only when contract, verification and SDK posture remain explicitly bounded.