What a PASS means

A verifier answers a few precise questions about the material you give it, and reports the answers as a verdict. This page puts together the parts of the specification that say what those answers are worth. Each part below is quoted from the specification, or linked to it, and the specification is what binds.

A verdict answers named questions

A check names which question has been answered, not how well. Checks are cumulative in evidence and independent in meaning: establishing authorization does not make integrity stronger, and a run that did not request authorization has not failed it: it has not been asked.

A check is never a quality score, a risk rating, or a statement about the asset. It is a statement about what a holder of the evidence was able to recompute.

A report names the checks a run requested and the checks it established (report-contract.md §3.2). It names no level, number or rank: the names below are the only identifiers of the checks.

Included from loquitur-protocol/docs/specification/verification-checks.md, section 1. CC BY 4.0.

What a PASS asserts, and what it does not

A verdict is one of PASS, REVIEW or FAIL, reported alongside a status (OFFLINE_OK / OFFLINE_REVIEW / OFFLINE_FAIL) and a process exit code:

exit	meaning
0	OFFLINE_OK / PASS
1	OFFLINE_FAIL / FAIL
2	OFFLINE_REVIEW / REVIEW
3	internal error: the verifier failed, not the evidence
4	unsupported version: an object of a later version; upgrade the verifier, no verdict was computed
5	host failure: the host failed on the operator’s path or working space; no verdict was computed
64	usage error: the invocation was wrong; no verdict was computed

The taxonomy, the status a run reaches and the reasons it reports are normative in report-contract.md §3 to §5; this table restates them.

A PASS asserts exactly this, and only for the checks the report lists in checks_established (report-contract.md §3.2):

Every digest recomputed from the material supplied recomputes to the value some other supplied document declares, every supplied document satisfies its closed field contract, and, where authorization was requested, the entry’s signature verifies under a key that the trust registry supplied to the verifier authorizes for that issuer, that scope, and the operator’s evaluation time, and a root the operator pinned authenticates that registry.

A PASS does not assert that the trust registry is authentic beyond the root the operator pinned (section 5), that the key was inside its window when the entry was signed (section 6), that the evidence describes the world correctly, that the entry appears in any registry anyone else can see, that a value is right, or that any party is who it says it is outside the trust material handed over.

REVIEW means not established, not bad. It is the verdict for questions the verifier could not answer: canonical input absent so the input-hash link cannot be rebuilt (bundle-objects.md §6), bundle members present that the manifest never declared (bundle-objects.md §1), a registry entry whose committed verdict is WARN or REVIEW (registry-link.md §6), no evaluation time, or no pinned trust root (trust-root.md §2). The report lists each such question in review_reasons (report-contract.md §3.3). A consumer that treats REVIEW as success has taken on the risk the verifier explicitly refused to absorb. The CLI’s --accept-review option does that for the reasons the operator names, and only for them; section 10 says what follows from using it.

Absence of a check is not a negative finding. A report whose checks_established is ["structure","integrity"] has not failed authorization; it was not asked. The report states the checks the caller requested and the checks that were established (report-contract.md §3.2), and a consumer must read them rather than infer a scope from a verdict.

Included from loquitur-protocol/docs/specification/threat-model.md, section 2. CC BY 4.0.

Status, verdict and exit code

Every report carries a status, a verdict and an exit code that agree with each other. A failure of the verifier or of the host has a status and an exit code but no verdict, a usage error (exit 64) writes no report, and only --accept-review makes the process exit differently from the report’s exit_code. The outcome table of the report contract lists every combination, section 3.2 says how the checks requested and established are reported, and section 4 defines the process exit codes.

Who vouches for the trust registry

A trust registry says which keys may sign registry entries. Nothing in the bundle can make a trust registry trustworthy: an issuer could produce one alongside the entry it authorizes. That is why the verifier authenticates a trust registry only against a trust root you pin, and why section 5 of the threat model states the property exactly.

Obtaining the root document through a channel the issuer does not control is the operator’s problem entirely, and no flag makes it. threat-model.md §10 states the rest.

Included from loquitur-protocol/docs/specification/trust-root.md, section 7. CC BY 4.0.

Whose clock

The windows of a trust registry, of an issuer key and of a trust root are judged at an evaluation time you supply, never at a date the issuer wrote. Release 0.1 has no attested signing time, so a PASS does not say when an entry was signed. Section 6 of the threat model explains the evaluation clock.

What stays with you

The verifier answers questions. These are decisions, and no flag makes them:

1. Obtain a trust root out of band and pin it. Without --trust-root, the trust registry proves that some key signed the entry and that the registry the verifier was given vouches for it. Whoever supplied that registry can make both true. Pinning is the difference between section 5 case A and case B. Obtaining the root through a channel the issuer does not control is the operator’s problem entirely.
2. Supply the evaluation time. --evaluation-time is the only clock that judges a key, a registry and a root. Without it, authorization is not established and the run is REVIEW.
3. Refresh trust material. A registry copy is a snapshot. Decide how old is too old, and enforce it; the tool checks the window written in the file, not whether the file is current.
4. Treat REVIEW as a stop, or name what you accept. --accept-review converts an OFFLINE_REVIEW run to exit 0 only when every review reason of the run is in the list the operator gives (report-contract.md §4). Accepting registry_entry_verdict_requires_review does not accept trust_registry_root_not_pinned: each reason accepted is a decision the operator takes on, and a gate that accepts the unpinned root has given up section 5.
5. Read more than the exit code. At minimum outcome.reason, checks_requested, checks_established, review_reasons, evaluation_time and, when the trust registry was evaluated, trust_registry.authorization_status, trust_registry.signature_status and trust_registry.trust_registry_root_signature_status. These are normative members (report-contract.md §2), so every conforming verifier reports them.
6. Bind issuer identifiers to real entities. Out of scope for the protocol and unavoidable for the relying party.
7. Decide what a REVIEW from an undeclared bundle member means. The verifier reports the names in manifest.extra_files; whether the content is material cannot be decided by hashing (bundle-objects.md §1).
8. Handle disclosed evidence. Retention, access control and destruction of a bundle after verification are entirely the operator’s.
9. Keep the verifier honest about itself. Verify the package you run, from a source you trust; a verifier is a trusted computing base, and this document assumes the one executing is the one described.

Included from loquitur-protocol/docs/specification/threat-model.md, section 10. CC BY 4.0.

What release 0.1 does not claim

This section is informative.

For release 0.1:

• no independent security or cryptographic review of the specification or of either implementation has been done, and no audit of any kind; the maintainer’s own testing, carried out with the help of AI tools, the conformance corpus included, is internal verification and not an audit;
• conformance to this specification, or to the conformance corpus, is not compliance with any law, regulation or standard, and no certification of any kind exists;
• the release is a preview and is not presented as fit for production use or for decisions of real value;
• the specification names no adopter, deployment, customer or partner, and claims none;
• no registry, log, anchoring or other service is operated under this specification;
• a verdict says what section 2 of threat-model.md says it asserts and nothing more: it does not say that the evidence is true, that a value is right, or that an issuer is who it claims to be;
• the verdict path contains no AI: no machine-learning model or other learned component takes part in any outcome, which follows from the rules of this specification applied to the inputs.

Included from loquitur-protocol/docs/specification/introduction.md, section 12. CC BY 4.0.

Read further

• The threat model, part 17 of the specification, in full.
• The limits page, with what each verifier does not check.