For Investors
The next institution could build on a check the last one already ran.
Every auditor or lender handed a NAV, a valuation or a collateral figure re-gathers the evidence behind it, because nothing from the last review travels with the number. The protocol specifies a receipt that records which policy was applied, the verdict and the reason codes behind it, so one review could stand for the next, and its record could be confirmed offline. Loquitur is a project, not a company, and has not yet published its specification or any package.
Scope
The scope starts with fund NAVs and property, and the next asset type is a version, not a rewrite.
The first version covers two asset types. That is where the protocol starts. The receipt, the registry entry and the reason codes stay the same whatever asset stands behind them, so the next asset type would cost a new version of the schemas, with no second protocol to maintain.
Fund NAV
An initial NAV and each update, passed from the administrator to the auditor and on to investors.
Property
A valuation before listing and under review, relied on by lenders and servicers, and by each venue where a tokenized asset trades.
Progress
Two verifiers and a schemas package implement the specification.
A specification on paper is a claim. Two separately written verifiers, compared case by case over one corpus, turn it into a claim that can be proved wrong. Every count is read from the schemas, the catalog and the corpus themselves, so none can drift from what the repositories hold.
Specification and schemas
The JSON Schemas cover 7 canonical objects, and a versioned catalog holds 61 reason codes in 11 categories.
Verifiers and a corpus
One verifier is written in Python and one in TypeScript. Both cover levels L0 to L3, and a conformance gate checks that they agree on structure and integrity (L0 and L1).
Roadmap
Publication would come before any operated registry, though neither step has a date.
The order follows what each step would be worth to a reviewer holding someone else's figure. The offline levels need no operated infrastructure, so publication alone would put that check in their hands. An operated registry would answer a later question: where to look an entry up.
Publication
A first release would publish the specification, the schemas and the offline verifiers, and later an API contract and SDKs.
Operated infrastructure
A public registry would first need four things: the trust-registry root key in a hardware security module, an operated transparency log, a deployed anchor, and a decision on how an entry refers to its asset.
Investors and grant providers
Ask where the project stands and what the next step would take.
Which step would interest you: publication or operated infrastructure?