End-to-end workflow

One NAV update, stage by stage

A NAV update goes through seven stages, from the issuer's documents to the parties that rely on the result. The issuer assembles the evidence, checks it under a named policy, records the policy and the verdict in a receipt, and signs an entry that commits to it. An auditor or investor who receives the bundle can check it without reaching the issuer.

Download the workflow PDFRead the protocol

Diagram

The flow at a glance

Policy is applied on the issuer's side. The structure, integrity, link and authorization checks run offline, on the verifier's own machine. A transparency log and an anchor, both planned, would sit on the public side. Dashed outlines mark planned extensions at the step where each would act; none of them is implemented.

Loquitur verification workflow The private side runs left to right: issuer inputs, policy evaluation, an evidence bundle held by the issuer, and the canonical objects derived from it. A rule separates the private side from the public one, and one signed registry entry crosses it, under a trust registry that lists which issuer keys may sign. Planned extensions are drawn with a dashed outline and the word Planned, at the step where each would act: the producer, a tool that would write the receipt without holding the signing key, under policy evaluation; origin, each document signed by the party that prepared it, under the evidence bundle; co-signature by a second party, checks without disclosing the documents, and timeliness judged over a series of updates, under the registry entry. An anchor that would record the state of a transparency log is planned and not implemented: no log is operated, and no chain or timestamp authority has been selected. None of the planned extensions is implemented. Along the bottom are the checks the model defines: structure, integrity, link and authorization run on the files alone, on the verifier's machine, and are implemented and tested, not published; transparency and anchoring are reserved and not implemented, drawn dashed, and would need information from outside that machine. Private side Issuer custody 01 Issuer inputs Documents · structured claims a versioned policy 02 Policy evaluation Canonicalize (RFC 8785), hash evaluate policy → status 03 Evidence bundle Portable, hashed file by file stays with the issuer 04 Canonical objects Receipt and its summaries derived from the bundle Planned · Producer Writes the receipt; never holds the key Planned · Origin of each document Signed by the party that prepared it Public side Hashes, identifiers and the result Lists which issuer keys may sign Trust registry Authorized issuers and their public keys registry_entry Registry entry Receipt hash · issuer id · manifest hash · policy id · verdict Commits to the receipt. Discloses no evidence. anchor Anchor Would record a transparency log's state Planned · reserved, not implemented Planned Co-signature by a second party; not an audit opinion Checks without disclosing the documents; timeliness over a series Verification The bundle Structure and integrity Read the bundle alone, rebuild the manifest hash Bundle and entry Link Confirms bundle and entry belong together Entry and trust registry Authorization Was the issuer's key allowed to sign it Planned · reserved Transparency and anchoring Would need a log and an anchor

Reading

The seven stages

  1. Issuer inputsDocuments, claims and policy

    Business

    In the protocol, the issuer is the party that signs the registry entry for a figure, for example the fund or a tokenization platform. The documents come from evidence producers such as the fund administrator or the valuer, who may also act as issuer. The inputs are the source documents, the figures they support, and the policy that defines an acceptable result.

    Technical

    Inputs are typed: documents, structured claims (each an assertion with an explicit support basis) and a versioned policy.

  2. Policy evaluationPolicy applied, status recorded

    Business

    The issuer writes and versions its own policy and applies it to its evidence. A claim like "the NAV is X" comes out as a status, with reason codes that say why. Whether the NAV or valuation itself is right stays the reviewer's call.

    Technical

    Inputs are canonicalized with JCS (RFC 8785) and hashed with SHA-256. The policy then produces a status (pass, warning, review or fail) and versioned reason codes; the registry entry states the same result as a verdict (PASS, WARN, REVIEW or FAIL).

    • Planned

      Producer. An installable tool that applies a published policy pack to the evidence and writes the receipt.

  3. Evidence bundleHeld by the issuer

    Business

    The documents, the inputs and the result are packaged into one portable bundle. It stays with the issuer, who decides whom to share it with.

    Technical

    The bundle is a directory or ZIP archive holding the canonical inputs, the supporting documents, the policy outcome, a change delta and a manifest of SHA-256 file digests. Every file must be declared in the manifest, and an undeclared file sends the run to review. The Python verifier opens both; the TypeScript verifier reads directories.

    • Planned

      Origin. Each document signed by the party that prepared it, such as the administrator or the valuer.

  4. Canonical objectsStandard summaries

    Business

    An auditor or investor usually asks four things: what passed, what changed, what came before, and what is covered or missing. The protocol defines one standard summary for each, derived from the bundle.

    Technical

    The schemas define the canonical objects. The review is described by verification_summary, verification_receipt, change_summary, lineage_summary and coverage_summary; the public side by registry_entry, the signed entry, and trust_registry. The registry entry commits to the receipt by its hash.

  5. Registry entryPublic, minimal

    Business

    The issuer signs a registry entry: a short statement that a verification took place, under which policy and with which result. The entry reveals none of the evidence.

    Technical

    A registry_entry is a signed projection of the receipt: receipt id, issuer id, manifest and receipt hashes, policy id and version, verdict, reason codes and signature, plus an optional anchor that names its method, system and reference and sits outside the signature. The trust registry lists authorized issuers, their public keys and the asset types and workflows each key may sign for, and authorization is checked against it offline.

    • Planned

      Co-signature by a second party. A named party signs a stated sentence about the entry. It is not an audit opinion.

    • Planned

      Checks without disclosing the documents. Show one item of a bundle without handing over the rest.

    • Planned

      Timeliness. Each update names the one before it, so a check can tell which arrived on time.

  6. VerificationOffline: structure, integrity, link, authorization

    Business

    Without calling the issuer or any server, an auditor learns whether the bundle is the one the issuer committed to, and whether the issuer's key was allowed to sign that commitment.

    Technical

    The verifier runs four checks. Structure and integrity read the bundle alone and rebuild the manifest hash. The link check takes the bundle and the registry entry and confirms that one commits to the other. The authorization check verifies the issuer's signature against the trust registry and tells revoked, suspended, expired, not-yet-effective and out-of-scope keys apart, so an authority failure is reported separately from an integrity failure. Transparency and anchoring are reserved and not implemented.

    • Planned

      Timeliness, judged over a series. Which updates in a series arrived on time, which late and which are missing.

    • Planned

      Transparency log and anchoring. Reserved: an append-only log of entries, its state anchored on a public chain or by timestamp.

  7. Who relies on the resultInvestors, platforms, auditors

    Business

    An investor about to allocate, a platform listing the asset or an auditor checking each update could use the same receipt as a starting point for their own review, without needing one another's systems.

    Technical

    The four checks are deterministic: given the same bundle, registry entry, trust registry, pinned trust-root document and evaluation time, they produce the same report.

Items marked planned are designed, not built. Their order is on the status page, under what comes next.

A planned check enters the specification only after an independent review of its cryptography. No such review has taken place yet.

Architecture

What stays with the issuer

The boundary runs between the issuer's own environment and what it shares: the signed registry entry.

An entry commits to the receipt's existence and integrity; the issuer shares the bundle itself only with the reviewers who need to check it.

The history stays private too, in the issuer's summaries: an entry names no earlier entry, so each check crosses the boundary on its own.

Planned

Why a transparency log is planned

A verifier answers for the party holding the files, at the moment it runs: these documents match this manifest, the manifest matches this entry, and the key that signed was authorized for this asset type and workflow.

It cannot answer a later question: whether this receipt existed before its outcome became convenient. The issuer holds its own evidence, so it could run a policy, dislike the result and commit only to a later run. Nothing in the files would show it.

A transparency log would narrow that question: an entry logged before an outcome was known would show its order, and a log watched from outside would make it harder to show different histories to different readers. It would record nothing about what was checked, and it would not show a run that was never logged.

The four offline checks do not depend on it. The log is planned, after the producer; it is not implemented.

  1. 01

    A verifier

    Answers for the party holding the files, at the moment it runs.

  2. 02

    The later question

    Whether this receipt existed before its outcome became convenient.

  3. 03

    A registry entry

    Commits to a receipt without carrying it.

  4. 04

    A transparency log

    Would show the order of entries logged before an outcome was known, and nothing about what was checked.

Principles

Design rules

hashing

Same inputs, same hash

Given the same inputs, canonicalization produces the same bytes and the same hash, so two parties can compare their results.

receipt

A pass cites a reason

A pass must cite at least one informational code and list the checks that ran.

lineage

Updates supersede

An update produces a new receipt, and the change and lineage summaries name the earlier bundle it supersedes. They stay with the issuer, so nothing outside the issuer's files shows whether that history was later rewritten; that is what the planned log is for.

bundle

No server needed

Verifying a bundle needs no server and no network: only the bundle, its registry entry, the trust registry, the trust-root document the verifier pins, and an evaluation time.

log

An append-only log, planned

A planned transparency log would be append-only: no entry could be edited or removed. It is not implemented.

Download

The workflow as a PDF

The diagram and the seven stages, each with its business and technical reading.

Download the workflow PDF