Reason codes

Status: normative.

loquitur.reason_codes.v1 is the closed vocabulary of machine-readable grounds that a verification outcome cites. This document is the register for it: it enumerates every code with its category and severity, and states the rules that bind a code to a verdict. The register is what an implementer reads the codes from; everything below it is the rule set that the schemas’ enum cannot express.

Non-normative note on citations. The one citation of the form <module>.py::<name> in this document names the module docstring of src/loquitur/verify/narrative.py in loquitur-verify-py, the reference implementation, which is a separate repository and not part of this one. It resolves in release 0.1.0 of loquitur-verify-py, once that repository is published, and names no line, and this repository’s tests check it against the source of a loquitur-verify-py checkout placed beside it, and that checkout’s version against the release named here. The citation is evidence, not part of the protocol.

Included from loquitur-protocol/docs/specification/reason-codes.md, opening. CC BY 4.0.

The rules that bind a code to a verdict are in the reason-code register; what a run reports is in the report contract.

The catalog catalog.json, version 2.0.0 of the vocabulary loquitur.reason_codes.v1: 57 codes in 11 categories. Each entry is shown with its technical text; the catalog’s texts for other audiences are in the file itself.

Register

Code	Category	Severity	Technical headline
AUTHORIZATION_ISSUER_KEY_EXPIRED	authorization	review	The issuing key had already expired at the evaluation time.
AUTHORIZATION_ISSUER_KEY_NOT_YET_EFFECTIVE	authorization	review	The issuing key had not yet come into force at the evaluation time.
AUTHORIZATION_ISSUER_KEY_REVOKED	authorization	fail	The issuing key was revoked in the trust registry.
AUTHORIZATION_ISSUER_KEY_SUSPENDED	authorization	fail	The issuing key is suspended in the trust registry.
AUTHORIZATION_ISSUER_NOT_RECOGNISED	authorization	fail	The issuer or issuing key is absent from the trust registry.
AUTHORIZATION_SCOPE_MISMATCH	authorization	fail	The issuing key is authorized, but not for this asset type or workflow.
AUTHORIZATION_SIGNATURE_NOT_VERIFIED	authorization	fail	The registry entry signature did not verify against the authorized key.
AUTHORIZATION_SIGNING_METHOD_UNSUPPORTED	authorization	fail	The registry entry was signed by a method this verifier does not accept.
AUTHORIZATION_TRUST_MATERIAL_OUTSIDE_VALIDITY_WINDOW	authorization	review	The trust registry itself was outside its validity window.
AUTHORIZATION_TRUST_REGISTRY_AMBIGUOUS_KEY	authorization	fail	The trust registry lists the same issuer key more than once.
AUTHORIZATION_VERIFIED	authorization	info	The issuing key was authorized by the trust registry at the evaluation time.
BUNDLE_EXTRA_FILES	integrity	warn	Bundle contains undeclared files, reported as a warning.
COMPLETENESS_OFFLINE_CHECKS_SKIPPED	offline	review	One or more offline checks were skipped due to missing material.
COMPLETENESS_OFFLINE_MATERIAL_MISSING	offline	review	Material required for full offline verification is missing.
COMPLETENESS_OFFLINE_MISSING_CANONICAL_INPUT	offline	review	canonical_input.json is missing from the bundle.
COMPLETENESS_OFFLINE_MISSING_MANIFEST	offline	review	manifest.json is missing from the bundle.
CONFLICTING_EVIDENCE_DETECTED	conflict	review	Two or more documents declare conflicting values for the same claim.
FRESHNESS_OK	freshness	info	All evidence is within the policy freshness window.
FRESHNESS_P1_TIMESTAMP_OOW	freshness	warn	P1 receipt timestamp is outside the policy validity window.
FRESHNESS_WARNING	freshness	warn	Evidence is approaching the freshness threshold.
INTEGRITY_CHECK_FAILED	integrity	fail	One or more integrity checks failed.
INTEGRITY_OFFLINE_CANONICALIZATION_FAILED	integrity	fail	Canonical input could not be canonicalized deterministically.
INTEGRITY_OFFLINE_ENVELOPE_LINKS_MISMATCH	integrity	fail	Envelope-declared inner hashes do not match recomputed hashes.
INTEGRITY_OFFLINE_ENVELOPE_SHA_MISMATCH	integrity	fail	Envelope (env1) hash does not match its declared value.
INTEGRITY_OFFLINE_EXTRA_FILES_STRICT	integrity	fail	Bundle contains files not declared in the manifest, under a policy that refuses them.
INTEGRITY_OFFLINE_FAIL	integrity	fail	Offline integrity verification failed.
INTEGRITY_OFFLINE_INPUT_HASH_MISMATCH	integrity	fail	Canonical input hash does not match the P1 input hash.
INTEGRITY_OFFLINE_MANIFEST_FILE_MISMATCH	integrity	fail	At least one manifest-declared file hash does not match.
INTEGRITY_OFFLINE_MANIFEST_SHA_MISMATCH	integrity	fail	Manifest content does not match manifest.sha256.
INTEGRITY_OFFLINE_SCHEMA_INVALID	integrity	fail	Bundle artifact failed schema validation.
INTEGRITY_OK	integrity	info	Bundle integrity verification completed without errors.
MARK_ASOF_UNPARSEABLE	freshness	warn	Evidence as-of date is missing or could not be parsed.
MARK_FAR_OUTSIDE_RANGE	valuation_crosscheck	review	Valuation mark is far outside the policy-acceptable range.
MARK_NEAR_BOUNDARY	valuation_crosscheck	warn	Valuation mark is near the cross-check range boundary.
MARK_OFFSET_FROM_MIDPOINT	valuation_crosscheck	warn	Valuation mark is offset from the cross-check midpoint.
MARK_OUTSIDE_RANGE	valuation_crosscheck	warn	Valuation mark falls outside the cross-check range.
MARK_STALE	freshness	warn	Evidence age exceeds the policy freshness threshold.
MATERIAL_CHANGE_DETECTED	materiality	warn	A material change was detected relative to the previous snapshot.
METHOD_BINDING_MISSING	policy	review	Valuation method binding is absent or not declared in policy.
MISSING_MARK_FIELDS	policy	review	Required mark fields are absent.
MISSING_REQUIRED_INPUTS	policy	review	Inputs required by the active policy are missing from canonical input.
NEEDS_REVIEW	policy	review	Policy evaluation requires manual review.
OFFLINE_CANONICAL_INPUT_MISSING	offline	review	Offline verifier could not locate canonical_input.json.
OFFLINE_INPUT_HASH_NOT_VERIFIED	offline	review	Input hash check could not be performed.
OFFLINE_MANIFEST_MISSING	offline	review	Offline verifier could not locate manifest.json.
OFFLINE_MATERIAL_MISSING	offline	review	Offline verification material is incomplete.
OFFLINE_REPLAY_FAILED	offline	fail	Offline replay produced a result inconsistent with the receipt.
OFFLINE_REPLAY_REVIEW	offline	review	Offline replay reached a result requiring review.
OFFLINE_REPLAY_SKIPPED	offline	review	Offline replay was not executed.
OFFLINE_REPLAY_WARN	offline	warn	Offline replay completed with warnings.
P1_TIMESTAMP_OUT_OF_WINDOW	freshness	warn	P1 receipt timestamp is outside the acceptable issuance window.
POLICY_BUNDLE_EXTRA_FILES	policy	warn	Bundle contains files outside the policy-allowed file set.
REQUIRED_CLAIMS_PRESENT	coverage	info	All required claims for the active policy are present.
REQUIRED_EVIDENCE_PRESENT	evidence	info	All evidence required by the active policy is present.
UNSUPPORTED_KEY_CLAIM	coverage	review	A key claim is present but is declared rather than document-backed.
VOCABULARY_VALUE_INVALID	vocabulary	fail	A value governed by a registered vocabulary is malformed.
VOCABULARY_VALUE_UNKNOWN	vocabulary	review	A value is well formed but is not in the registered vocabulary the reader holds.

Entries

AUTHORIZATION_ISSUER_KEY_EXPIRED

Category authorization, severity review.

The issuing key had already expired at the evaluation time.

Bundle integrity verified and the registry entry is well formed. The trust registry authorizes this key until its expires_at instant, and the operator’s evaluation time falls after it. The key is neither revoked nor suspended: its authorization had lapsed by the evaluation time. Version 0.1 has no attested signing time, so this does not show that the key had expired when the entry was signed, and the dates the issuer writes into the entry do not decide it. Note the check order: revocation and suspension are evaluated first, because they are assertions the registry makes about the key that remain true even after the registry itself has gone stale. The registry’s own validity window is evaluated next, before the key’s, because a stale registry’s judgement about a key’s expiry is not reliable evidence. So a registry outside its window reports itself and this status is not reached.

AUTHORIZATION_ISSUER_KEY_NOT_YET_EFFECTIVE

Category authorization, severity review.

The issuing key had not yet come into force at the evaluation time.

Bundle integrity verified and the registry entry is well formed. The operator’s evaluation time precedes the key’s effective_from, so at that time the signer held no authority under the supplied trust registry. Version 0.1 has no attested signing time, so the dates the issuer writes into the entry do not decide this. This is the opposite direction from an expired key: an evaluation time before the key’s authority began usually means that the evaluation time or the trust registry copy does not fit the question being asked, and it needs explaining before the record is relied on.

AUTHORIZATION_ISSUER_KEY_REVOKED

Category authorization, severity fail.

The issuing key was revoked in the trust registry.

Bundle integrity verified: manifest, P1, envelope and canonical-input replay all matched. The registry entry’s signature is well formed. Authorization failed because the trust registry marks the issuer key as revoked, which holds at every evaluation time and when none is supplied. Revocation is the containment control applied after a key is believed compromised. Note the check order: revocation is evaluated before the trust registry’s own validity window, so a stale registry does not mask it. A revocation does not un-happen, and the registry remains credible about it even once its window has lapsed. Suspension cannot mask it either: status is a single value, so an entry is suspended or revoked, never both.

AUTHORIZATION_ISSUER_KEY_SUSPENDED

Category authorization, severity fail.

The issuing key is suspended in the trust registry.

Bundle integrity verified and the registry entry is well formed. The trust registry records the issuer key status as suspended, which holds at every evaluation time and when none is supplied. The verifier observed that status and nothing more: suspension is defined as a reversible hold rather than a withdrawal, but the registry carries no reason, so this outcome is by itself evidence neither of compromise nor of its absence.

AUTHORIZATION_ISSUER_NOT_RECOGNISED

Category authorization, severity fail.

The issuer or issuing key is absent from the trust registry.

Bundle integrity verified and the registry entry is well formed. The issuer identifier, or the specific key identifier it names, has no entry in the supplied trust registry. The verifier draws no conclusion about the issuer’s legitimacy: an unknown issuer and an untrusted issuer are indistinguishable from a registry that does not list it.

AUTHORIZATION_SCOPE_MISMATCH

Category authorization, severity fail.

The issuing key is authorized, but not for this asset type or workflow.

Bundle integrity verified, the registry entry is well formed, and the issuer key is active and within its validity window. The trust registry constrains this key to a declared set of asset types and workflows, and the entry names one outside that set. Authority is scoped, so holding a valid key is not sufficient.

AUTHORIZATION_SIGNATURE_NOT_VERIFIED

Category authorization, severity fail.

The registry entry signature did not verify against the authorized key.

Bundle-level integrity verified: the manifest, P1 and envelope digests matched. The registry entry’s own signature failed verification against the public key the trust registry authorizes. This covers a missing signature, a signature that does not verify, and an entry naming a key other than the authorized one. The entry was altered after signing, or it was signed by a different key.

AUTHORIZATION_SIGNING_METHOD_UNSUPPORTED

Category authorization, severity fail.

The registry entry was signed by a method this verifier does not accept.

Bundle integrity verified and the entry is well formed. The signing algorithm, the issuer key type declared by the trust registry, or the signing payload version falls outside the accepted cryptographic capability profile. The verifier refuses rather than attempting a best-effort interpretation, because accepting an unrecognised method is how algorithm-confusion attacks succeed.

AUTHORIZATION_TRUST_MATERIAL_OUTSIDE_VALIDITY_WINDOW

Category authorization, severity review.

The trust registry itself was outside its validity window.

Bundle integrity verified and the registry entry is well formed. The failure is at the registry level rather than the key level: the supplied trust registry declares its own effective and expiry instants, and the operator’s evaluation time falls outside them. The verifier does draw one class of conclusion from material outside its window: revocation and suspension are reported before this check, because those assertions do not lapse with the document carrying them. Everything time-relative - the key’s own effective and expiry instants, and scope - is not evaluated, and this status is what the reader receives instead.

AUTHORIZATION_TRUST_REGISTRY_AMBIGUOUS_KEY

Category authorization, severity fail.

The trust registry lists the same issuer key more than once.

Bundle integrity verified and the registry entry is well formed. The supplied trust registry contains more than one entry for the same issuer and key identifier, or the entry found carries the same public key, in any encoding, as another entry of the registry, so the authority for that key is not determined by the registry. The verifier refuses rather than selecting one, because selecting by position or by label would let a revoked entry be shadowed by an active entry for the same key.

AUTHORIZATION_VERIFIED

Category authorization, severity info.

The issuing key was authorized by the trust registry at the evaluation time.

The key named by the registry entry is listed in the supplied trust registry, carries active status, falls within both the registry’s and its own validity window at the operator’s evaluation time, and is authorized for the entry’s asset type and workflow. This is authorization against the supplied trust material only: the trust registry’s own root signature is not verified, so that material is trusted as given.

BUNDLE_EXTRA_FILES

Category integrity, severity warn.

Bundle contains undeclared files, reported as a warning.

Files are present in the bundle that are not declared in manifest.json. The issuer’s policy reports them as a warning rather than a failure. The undeclared files are not within the receipt’s commitment scope, and a verifier reports each of them as an undeclared member.

COMPLETENESS_OFFLINE_CHECKS_SKIPPED

Category offline, severity review.

One or more offline checks were skipped due to missing material.

The offline verifier reports that at least one check was not performed because its required input was absent. Examples: canonical_input.json missing means input-hash check skipped; envelope absent means envelope check skipped. The check did not fail; it did not run.

COMPLETENESS_OFFLINE_MATERIAL_MISSING

Category offline, severity review.

Material required for full offline verification is missing.

The bundle is missing material that the offline verifier needs to perform a complete replay (typically canonical_input.json, p1.json, or envelope). The verifier proceeds with partial coverage and emits this code so the gap is explicit in the verdict.

COMPLETENESS_OFFLINE_MISSING_CANONICAL_INPUT

Category offline, severity review.

canonical_input.json is missing from the bundle.

The canonical input file is absent. Without it the verifier cannot recompute the input hash or replay the policy evaluation. The verdict drops to REVIEW; presence of canonical_input is required for a full offline replay.

COMPLETENESS_OFFLINE_MISSING_MANIFEST

Category offline, severity review.

manifest.json is missing from the bundle.

The manifest is absent. Without it no declared file can be enumerated and no per-file hash confirmed, so the bundle is not well-formed. A verifier given such a bundle fails its manifest check; the record cannot be relied upon until the issuer provides the manifest.

CONFLICTING_EVIDENCE_DETECTED

Category conflict, severity review.

Two or more documents declare conflicting values for the same claim.

The conflict detector identified at least one claim for which two source documents in this bundle declare different values for the same asset on the same effective date. The conflict is recorded with evidence pointers to both documents. The verdict drops to REVIEW; conflicts must be explicitly resolved before PASS.

FRESHNESS_OK

Category freshness, severity info.

All evidence is within the policy freshness window.

Each evidence document’s effective date falls within the configured freshness threshold for its document_class. For property appraisals this is typically 90 days; for monthly NAV statements 30 days; thresholds are set per asset type in the policy pack.

FRESHNESS_P1_TIMESTAMP_OOW

Category freshness, severity warn.

P1 receipt timestamp is outside the policy validity window.

The P1 receipt’s issuance timestamp (p1.timestamp) is outside the policy-configured validity window relative to the snapshot effective date. Receipts are time-bound; a receipt issued well before or after the period it claims to attest to is not credible.

FRESHNESS_WARNING

Category freshness, severity warn.

Evidence is approaching the freshness threshold.

At least one evidence document’s age is within the warning band of the freshness threshold (typically the second-to-last quartile before staleness). The verdict is not affected, but the bundle should be regenerated soon with refreshed evidence to avoid future stale-evidence rejections.

INTEGRITY_CHECK_FAILED

Category integrity, severity fail.

One or more integrity checks failed.

At least one structural integrity check (manifest hash, P1 hash, envelope hash, or canonical input hash) did not match its declared value. The bundle cannot be replayed deterministically against its declared receipt. Inspect the per-check sub-results to identify which layer failed; common causes are post-bundling document modification, corrupted ZIP transport, or a bug in the bundle generation pipeline.

INTEGRITY_OFFLINE_CANONICALIZATION_FAILED

Category integrity, severity fail.

Canonical input could not be canonicalized deterministically.

The canonical_input.json file in the bundle could not be canonicalized under RFC 8785 (JCS). Common causes: the file contains non-JSON content, contains values that are not deterministically representable (NaN, Infinity, non-string object keys), or is malformed. A bundle whose canonical input cannot be canonicalized cannot have a stable input hash and therefore cannot be replayed.

INTEGRITY_OFFLINE_ENVELOPE_LINKS_MISMATCH

Category integrity, severity fail.

Envelope-declared inner hashes do not match recomputed hashes.

The envelope (env1) declares the SHA-256 of its inner P1 receipt and supporting artifacts. At least one of these inner-link hashes does not match the recomputed value. The envelope and its inner contents have drifted relative to each other; the envelope is no longer a faithful wrapper of the current bundle contents.

INTEGRITY_OFFLINE_ENVELOPE_SHA_MISMATCH

Category integrity, severity fail.

Envelope (env1) hash does not match its declared value.

The recomputed SHA-256 of the envelope wrapping the P1 receipt does not match the envelope_sha256 declared in the manifest or sidecar. The envelope has been modified after issuance, or the manifest reference is stale. The receipt’s outer wrapper cannot be trusted as authentic.

INTEGRITY_OFFLINE_EXTRA_FILES_STRICT

Category integrity, severity fail.

Bundle contains files not declared in the manifest, under a policy that refuses them.

The bundle contains files that are present on disk but not declared in manifest.json, and the issuer’s policy treats any undeclared file as an integrity failure: under that policy the manifest must be a complete and exhaustive inventory of the bundle’s contents.

INTEGRITY_OFFLINE_FAIL

Category integrity, severity fail.

Offline integrity verification failed.

The standalone offline verifier rejected the bundle at the integrity layer. This is the aggregate failure outcome covering manifest, P1, envelope, and canonical-input replay. Specific sub-codes (INTEGRITY_OFFLINE_*) carry the exact failing layer and should be inspected to determine the precise cause.

INTEGRITY_OFFLINE_INPUT_HASH_MISMATCH

Category integrity, severity fail.

Canonical input hash does not match the P1 input hash.

The SHA-256 of the canonicalized canonical_input.json does not match the input_hash declared inside p1.json. Either canonical_input.json was modified after the receipt was issued, or the wrong canonical_input.json is paired with this p1.json. The two are not from the same verification event.

INTEGRITY_OFFLINE_MANIFEST_FILE_MISMATCH

Category integrity, severity fail.

At least one manifest-declared file hash does not match.

A file declared in manifest.json has a recomputed SHA-256 that differs from the value in the manifest. The file has been replaced, edited, or re-exported after the manifest was produced. The check covers all files listed in the manifest; the per-file diff identifies the specific failing entries.

INTEGRITY_OFFLINE_MANIFEST_SHA_MISMATCH

Category integrity, severity fail.

Manifest content does not match manifest.sha256.

The recomputed SHA-256 of manifest.json does not match the value stored in manifest.sha256. The manifest has been edited after the sidecar hash file was produced, or the sidecar hash is stale relative to the current manifest. The bundle’s table of declared file hashes therefore cannot be trusted as authoritative.

INTEGRITY_OFFLINE_SCHEMA_INVALID

Category integrity, severity fail.

Bundle artifact failed schema validation.

One of the canonical bundle artifacts (manifest.json, p1.json, env1, canonical_input.json) failed validation against its public schema. The artifact is structurally invalid and cannot be processed downstream regardless of hash matches.

INTEGRITY_OK

Category integrity, severity info.

Bundle integrity verification completed without errors.

The manifest, P1 receipt, and envelope hashes have been recomputed and match the values declared inside the bundle. Canonical input hashing succeeded under RFC 8785 (JCS). No tampering, truncation, or canonicalization drift was detected at the bundle integrity layer.

MARK_ASOF_UNPARSEABLE

Category freshness, severity warn.

Evidence as-of date is missing or could not be parsed.

An evidence document’s as-of date is absent, malformed, or in a format the freshness evaluator cannot parse. Without a parsable date the freshness check cannot be performed for that document; the verifier emits a warning so the gap is visible to downstream review.

MARK_FAR_OUTSIDE_RANGE

Category valuation_crosscheck, severity review.

Valuation mark is far outside the policy-acceptable range.

The cross-check service compared the declared mark_value against an independent reference range (peer comparables, model-driven range, prior-period bounds). The declared mark falls outside that range by more than the policy-configured tolerance. The cross-check does not establish that the mark is wrong; it establishes that the mark requires explanation.

MARK_NEAR_BOUNDARY

Category valuation_crosscheck, severity warn.

Valuation mark is near the cross-check range boundary.

The mark falls inside the cross-check range but close to its outer edge. Informational only; recorded so that future drift toward out-of-range can be detected as a trend.

MARK_OFFSET_FROM_MIDPOINT

Category valuation_crosscheck, severity warn.

Valuation mark is offset from the cross-check midpoint.

The mark sits in the upper or lower half of the cross-check range, distinguishably away from midpoint. Informational; useful for portfolio-level drift detection across many bundles.

MARK_OUTSIDE_RANGE

Category valuation_crosscheck, severity warn.

Valuation mark falls outside the cross-check range.

The mark falls outside the policy-acceptable cross-check range but within a soft band where the policy emits a warning rather than dropping the verdict. The deviation is recorded and surfaced to the reviewer.

MARK_STALE

Category freshness, severity warn.

Evidence age exceeds the policy freshness threshold.

At least one evidence document’s effective date is older than the policy-configured freshness window. The verifier emits a warning at this layer; whether the warning escalates to REVIEW or FAIL depends on policy configuration (typically REVIEW within 2x the threshold, FAIL beyond).

MATERIAL_CHANGE_DETECTED

Category materiality, severity warn.

A material change was detected relative to the previous snapshot.

The change_summary indicates that at least one tracked claim changed by more than the policy-configured materiality threshold relative to the immediately superseded snapshot. The change is recorded with delta_pct and absolute delta values. The verdict is not affected by materiality alone; the marker exists to ensure the change is visible to downstream consumers and not silently absorbed.

METHOD_BINDING_MISSING

Category policy, severity review.

Valuation method binding is absent or not declared in policy.

The active policy requires that the valuation method (e.g. income approach, sales comparison, cost approach for property; mark-to-market, mark-to-model for other asset classes) be explicitly bound to its supporting evidence. The bundle does not declare a method binding, or declares one not recognized by the policy.

MISSING_MARK_FIELDS

Category policy, severity review.

Required mark fields are absent.

The mark object (the policy-driven valuation summary) is missing one or more fields required by the active policy. Common cases: mark_value missing, mark_currency missing, mark_method missing, mark_asof missing. The policy refuses to issue PASS on an incomplete mark.

MISSING_REQUIRED_INPUTS

Category policy, severity review.

Inputs required by the active policy are missing from canonical input.

The active policy declares a set of required canonical input fields for the asset type and workflow. One or more of these required fields is absent from canonical_input.json. The policy cannot be applied to an incomplete input; the verdict drops to REVIEW pending input completion.

NEEDS_REVIEW

Category policy, severity review.

Policy evaluation requires manual review.

The active policy returned an explicit REVIEW verdict on this bundle. The trigger is policy-specific: ambiguous evidence, edge-case method binding, or a configured manual gate. The bundle is not failing but is not eligible for unattended PASS.

OFFLINE_CANONICAL_INPUT_MISSING

Category offline, severity review.

Offline verifier could not locate canonical_input.json.

Surface code emitted by the offline verifier when canonical_input.json is not present in the bundle root. Equivalent in semantics to COMPLETENESS_OFFLINE_MISSING_CANONICAL_INPUT; emitted from the offline verifier path.

OFFLINE_INPUT_HASH_NOT_VERIFIED

Category offline, severity review.

Input hash check could not be performed.

The verifier reached the input-hash check but could not perform it (typically because canonical_input is missing or canonicalization failed earlier). The check is recorded as not-verified rather than failed; downstream reasoning treats this as partial coverage.

OFFLINE_MANIFEST_MISSING

Category offline, severity review.

Offline verifier could not locate manifest.json.

Surface code from the offline verifier when manifest.json is not present. The bundle has no declared inventory, so per-file hash checks cannot be performed; the verdict drops to REVIEW pending bundle completion.

OFFLINE_MATERIAL_MISSING

Category offline, severity review.

Offline verification material is incomplete.

Aggregate code indicating that one or more pieces of offline verification material are missing. Specific sub-codes identify which piece. The verifier proceeds with partial coverage.

OFFLINE_REPLAY_FAILED

Category offline, severity fail.

Offline replay produced a result inconsistent with the receipt.

The offline verifier executed the replay path and the result it computed disagrees with the receipt’s declared verdict, reason codes, or output structure. The receipt cannot be reproduced from the bundle on a disconnected machine.

OFFLINE_REPLAY_REVIEW

Category offline, severity review.

Offline replay reached a result requiring review.

The offline replay completed but reached a verdict of REVIEW rather than confirming PASS. The receipt is not contradicted but the replay path independently flagged REVIEW conditions.

OFFLINE_REPLAY_SKIPPED

Category offline, severity review.

Offline replay was not executed.

The replay path was skipped, typically because required material was missing earlier in the verification flow or the verifier was invoked in a mode that does not include replay. The verdict reflects only the layers that did execute.

OFFLINE_REPLAY_WARN

Category offline, severity warn.

Offline replay completed with warnings.

The replay finished without verdict-changing failures but emitted one or more warning conditions (e.g. approaching freshness threshold, undeclared files under a policy that warns on them). The verdict is not blocked but the bundle should be reviewed for warnings.

P1_TIMESTAMP_OUT_OF_WINDOW

Category freshness, severity warn.

P1 receipt timestamp is outside the acceptable issuance window.

Equivalent semantics to FRESHNESS_P1_TIMESTAMP_OOW with a different code surface. The P1 timestamp falls outside the policy-defined acceptable issuance window relative to the snapshot.

POLICY_BUNDLE_EXTRA_FILES

Category policy, severity warn.

Bundle contains files outside the policy-allowed file set.

The active policy declares a permitted file inventory. The bundle contains files outside this set. The policy reports a warning so the deviation is visible; whether the deviation requires action depends on policy and downstream consumption.

REQUIRED_CLAIMS_PRESENT

Category coverage, severity info.

All required claims for the active policy are present.

The coverage_summary indicates that every claim required by the active policy (for the asset type, workflow, and policy version) is present in the canonical input. This is a precondition for PASS; absence of any required claim drops the verdict to REVIEW or FAIL depending on policy strictness.

REQUIRED_EVIDENCE_PRESENT

Category evidence, severity info.

All evidence required by the active policy is present.

The evidence_index lists every document required by the policy for this asset type and workflow. Each document is hashed, classified by document_class, and bound to the claims it supports. This is a precondition for PASS at the evidence layer.

UNSUPPORTED_KEY_CLAIM

Category coverage, severity review.

A key claim is present but is declared rather than document-backed.

A claim required by the active policy is present in canonical input but its support_basis is ‘declared_only’, not backed by a parsed document with extraction provenance. The claim may be correct, but it is not auditable: a regulator cannot trace the value back to a specific document, page, and section.

VOCABULARY_VALUE_INVALID

Category vocabulary, severity fail.

A value governed by a registered vocabulary is malformed.

A member governed by a registered vocabulary (an asset type, a workflow or an anchoring method) carries a value that does not match the identifier grammar ^[a-z0-9][a-z0-9_]{0,63}$: it is not a string, or it holds an upper-case letter, a hyphen, a space, or more than 64 characters. The object breaks its contract, whatever any vocabulary holds.

VOCABULARY_VALUE_UNKNOWN

Category vocabulary, severity review.

A value is well formed but is not in the registered vocabulary the reader holds.

A member governed by a registered vocabulary (an asset type, a workflow or an anchoring method) carries an identifier that matches the grammar ^[a-z0-9][a-z0-9_]{0,63}$ but is not a value of the version of that vocabulary the reader holds. The object satisfies its contract. The value may be registered in a later version of the vocabulary, or belong to a vertical the reader does not support; no other finding depends on it.