Implementation status
Every part of the protocol, followed from specification to operation.
Each part of Loquitur keeps its label here until something moves it: the offline verifiers published as packages, the schemas and the conformance corpus released for others to run against, or a registry, log or anchor put into operation. Each change would be recorded on its row, with what changed and when. For now, none is published yet as a package or a hosted service, and no registry, log or anchor is operated.
Components
Where each component stands today, limits included.
A candidate is implemented and tested but unpublished. A private preview is unpublished too, and its content or interface can still change. A future component is specified and not yet operated.
| Component | Label | Today | Limits |
|---|---|---|---|
| Specification | PRIVATE PREVIEW | Version 0.1 of the specification defines the evidence bundle, the verification receipt and its summaries, reason-coded outcomes, the registry entry and the trust registry, for two asset types and four workflows. | Not published. Still undecided: the derivation of the subject reference, the operator of the transparency log and the attestation of verification time. |
| Schemas package | CANDIDATE | JSON Schemas for the 7 canonical objects, among them the verification receipt, the registry entry and the trust registry, held to a compatibility baseline. Bundle files are defined by field contracts in the specification, outside this package. | Not published, and not ratified by any standards body. |
| Python verifier | CANDIDATE | Checks a bundle offline at four levels: structure (L0), file and manifest integrity (L1), the cryptographic link between the bundle and its registry entry (L2), and issuer authorization against a trust registry (L3), where it tells revoked, suspended, expired, not-yet-effective and out-of-scope keys apart. | Inclusion proofs (L4) and anchor finality (L5) are not implemented. No production root key exists, so none is pinned; without a pinned root the verifier returns REVIEW rather than PASS. A root obtained out of band can be supplied at verification time, and it then counts as pinned. |
| Cross-implementation conformance | CANDIDATE | The conformance gate runs 36 adversarial vectors through 4 checkers (the Python and TypeScript verifiers, the schemas package and a schema oracle), and 7 bundles through the Python and TypeScript implementations, and fails on any disagreement. It currently reports none. | Its bundle cases carry no registry entry and no trust registry, so the gate does not yet exercise the link (L2) or authorization (L3) checks. The corpus was written within the project and has not been ratified externally. Agreement shows that two separate readings of the specification match on the cases compared; it does not show that the specification is correct. |
| API contract | PRIVATE PREVIEW | An unpublished draft of the API contract, kept inside the project. No service implements it. | No hosted endpoint exists, and the draft can still change. |
| TypeScript verifier | PRIVATE PREVIEW | A second offline verifier, written separately in TypeScript, that checks the same four levels (L0 to L3). The conformance gate holds it in agreement with the Python verifier on structure, integrity and the schema contract. It is built to make no network calls and contains no HTTP client. | Not published to npm, and its interface can still change. |
| Public registry | FUTURE | The specification defines the registry entry format, and the repository holds a skeleton. | Not operated. No log head has been anchored, and no chain has been selected for anchoring. |
Label changes
What has to happen before each label changes.
| Component | Condition |
|---|---|
| Specification | Publication, with the schemas and the offline verifiers. |
| Schemas package | Publication as a package, with generated reference documentation. |
| Python verifier | Publication as a package. |
| Cross-implementation conformance | Extension to the link (L2) and authorization (L3) checks. |
| TypeScript verifier | The conformance gate extended to the link (L2) and authorization (L3) checks, then publication to npm. |
| API contract | Published packages, an authentication model, compatibility checks and integration documentation. |
| Public registry | A decision on who operates the transparency log and under which key, the trust-registry root key held in a hardware security module, a decision on how the subject reference is derived, and a deployed anchor. |
Not claimed
What Loquitur does not claim.
No interface is declared stable, and no SDK exists.
No external audit, SOC 2 report, ISO certification, SLA or bug bounty exists.
No partnership, customer, pilot or endorsement exists.
To ask about a component or its label, contact the project.
Before a label changes
Ask about a component, or about what would move it.
Every label waits on a decision, not a date: which component is published first, who operates a transparency log, under which key. If one of those decides whether you could use this, say so now, while it is still open.