Implementation status

Status

Version 0.1.0, one maintainer. The specification, the schemas, the conformance corpus and the two offline verifiers are published as an Alpha preview. There is no hosted service, and no log or anchor is operated.

Status: the specification, the schemas, the conformance corpus and the two verifiers are published as an Alpha preview. Their interfaces can still change.

  • 5 components are published as an Alpha preview and 3 are planned.
  • The conformance corpus declares 1093 verification runs; the baseline records 0 disagreements with the declared outcomes.
  • The planned work is listed below in order, without dates.
Read the protocolContact the maintainer

Register

Components

Preview (Alpha): implemented, tested and published, and its interface can still change. Planned: designed or specified, not implemented.

Each component, its release label, what it is today and its limits.
ComponentLabelTodayLimits
SpecificationPreview (Alpha)Version 0.1.0 of the specification, one numbered text in 18 parts, defines the evidence bundle, the verification receipt and its summaries, reason-coded outcomes, the registry entry and the trust registry. Two asset types and four workflows are registered in versioned vocabularies beside it. It is the repository loquitur-protocol.Still undecided: the operator of the transparency log and how verification time is evidenced.
Schemas packagePreview (Alpha)JSON Schemas for the 7 canonical objects, among them the verification receipt, the registry entry and the trust registry, with the reason-code catalog. Bundle files are defined by field contracts in the specification, outside this package. Package loquitur-schemas, version 0.1.0.Not ratified by any standards body.
Python verifierPreview (Alpha)Runs four checks offline: structure, file and manifest integrity, the link between the bundle and its registry entry, and issuer authorization against a trust registry, where it tells revoked, suspended, expired, not-yet-effective and out-of-scope keys apart. Opens directories and ZIP archives. Package loquitur-verify, version 0.1.0.Transparency and anchoring are reserved and not implemented. Without a trust-root document supplied by the operator, 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 conformancePreview (Alpha)The conformance corpus is an archive pinned in loquitur-protocol, with 4013 members. It declares the expected outcome of 1093 verification runs at each of the four checks, structure, integrity, link and authorization, including runs that fail at each one, and 54 schema documents that a schema must reject. Each verifier is run over it through an adapter, and its reports are compared with the declared outcomes. No disagreement is recorded in the baseline. The comparison script in the specification (docs/specification/conformance-testing.md, section 7, in loquitur-protocol), run with the Python verifier, adds the summary checks and reports 0 disagreements over 1121 runs.The corpus and both verifiers were written by the same maintainer, and the corpus has not been ratified externally. Their agreement shows that two implementations match on the cases compared; it is not independent evidence, it is not an audit, and it does not show that the specification is correct.
TypeScript verifierPreview (Alpha)A second offline verifier, written in TypeScript by the same maintainer as the Python one, that runs the same four checks. It reads bundle directories; it does not open ZIP archives. It makes no network calls and has no HTTP client. Package @loquitur/verify, version 0.1.0.Its interface can still change. It is held to the outcome the corpus declares for every case it can read.
Transparency log and anchoringPlannedReserved in the specification.Not implemented and not operated. No chain or timestamp authority has been selected.
Profiles, producer and dossier archivePlannedPublic profiles per asset type, a producer that applies a profile's policy pack and writes the receipt, and an archive format to keep and hand over a set of bundles.Designed, not built. Today each issuer writes its own policy.
ApplicationsPlannedA console to open a dossier, monitoring of a listing, and a hosted service.Designed, not built. No service is operated.

Conditions

Label changes

The five published components stay an Alpha preview while their interfaces can change; no stable label is declared. A planned part changes its label when it is built, and what each one needs first is below.

Each planned component and what it needs before its label changes.
ComponentCondition
Transparency log and anchoringA specification of the log (identity, checkpoints, witnesses), someone producing receipts to record, and a decision on who operates it and under which key.
Profiles, producer and dossier archiveThe profiles are specified first, with the evidence model and the policy pack per asset type. The producer is built against them.
ApplicationsSomeone asks for them. Nothing in the layers below depends on them.

Order

Planned work

The order follows what each step needs before it can be useful. A step starts when the one before it is finished and someone needs it, not on a date.

  1. 01

    Producer and dossier archive, with release 0.2 in parallel

    The producer, the archive format, and the first two public asset profiles, for property valuations and fund NAVs. In parallel, release 0.2 of the specification: scoped trust roots, an envelope bound by reference, opening a bundle by its subject reference, and a report that names its trust basis.

  2. 02

    Planned checks on the evidence

    The four checks described below, each specified before it is built.

  3. 03

    Transparency log and anchoring

    The log, the toolkit that writes to it, and anchoring of its checkpoints as an option.

  4. 04

    Applications

    The console, listing monitoring and a hosted service, when someone asks for them.

  5. 05

    Packages on PyPI and npm

    Later and without a date: after the opposition period of the EU trade mark application, and when the packages are mature and have been tried by others. Until then they are installed from a clone.

A producer is useful as soon as one issuer installs it: it writes receipts that any verifier can check offline. A transparency log is useful only once there are receipts to record in it. The producer and the archive come first for that reason.

Planned checks on the evidence

The four checks that exist today establish that the files are the ones the issuer committed to, and that the key that signed was authorized to. They say nothing about the documents themselves. Four further checks on the evidence are in design. Each answers its own question, and none of them says that a document or a figure is correct.

  • Origin

    Was this document signed by the party that produced it, such as the fund administrator or the valuer, and is that party recognized in a trust registry the verifier chooses? This depends on evidence producers signing their documents.

  • Co-signature by a second party

    Did other named parties, such as a trustee or a second reviewer, sign a stated sentence about the same registry entry, and is the quorum the operator requires met? Each signer stays identifiable, and no signature is an audit opinion.

  • Checks without disclosing the documents

    Can one item of a bundle be shown, such as the asset an entry refers to, without handing over the rest? Checks on values that stay hidden, such as a loan-to-value ratio below a threshold, would come later and only after review by specialists in zero-knowledge cryptography.

  • Timeliness

    For a series the verifier selects, which promised updates existed by their deadline, which arrived late and which are missing? Offline, a verifier can see gaps in a sequence; it cannot see an entry that was withheld. That is what the transparency log is for.

    • Boundaries

    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.
    • No independent review of the cryptography or the specification has been carried out.
    • The maintainer's own testing, carried out with the help of AI tools, is internal verification and not an audit.

    To ask about a component or its label, contact the maintainer.

    Before a label changes

    Questions about a component or its label.

    Labels change on decisions, such as who would operate a transparency log and under which key. If one of them affects whether you could use the protocol, write to the maintainer before it is settled.

    Contact the maintainer