Skip to content

Verification Standard

Trust is a process, not a colour

Verification gathers identity, integrity, provenance, freshness, scope, and conflict into a conclusion that can still be revised. This standard closes the first Knowledge and Provenance journey by showing why a green check is never the whole story.

Return to the Book of Memory to see how verified and disputed records remain accountable over time.

Purpose

Defines independent verification of integrity, provenance, authorization, applicability, custody, lineage, and promotion evidence.

Architect-review operating model

  • PROV-R156: Verification SHALL state subject, method, evidence, verifier independence, limits, result, date, and required follow-up.
  • PROV-R157: A failed, partial, stale, or disputed result SHALL remain explicit and SHALL not support a stronger claim than its scope permits.
  • PROV-R158: Verification SHALL distinguish integrity, provenance, authority, applicability, and lifecycle state.
  • PROV-R159: This Draft SHALL NOT promote documents, authorise deployment, or replace Architect review.

Interpretation cases: Conforming reproduces evidence and records limits; Prohibited treats a pass as authority; Boundary verifies a bounded field; Failure blocks dependent promotion; Loophole omits failed checks; Misuse overstates scope; Care-control preserves dissent and correction.

Normative clauses

  • PROV-R040: Verification shall evaluate digest integrity, authenticated origin, class, namespace, validity, revocation, replay, custody, applicability, and limitations as separate dimensions.
  • PROV-R041: At least one independent evidence path shall verify every consequential claim before promotion.
  • PROV-R042: Verification shall preserve the distinction between Verified, Integrity-only, Unverified, Invalid, Revoked, and Unknown, plus field applicability states.
  • PROV-R043: Conflicting, unavailable, incomplete, stale, or unsupported evidence shall block dependent promotion and preserve the conflict.
  • PROV-R044: Verification results shall identify reviewer, method, evidence, time, limitations, and supersession relationship.

Examples and exclusions

A matching digest may establish Integrity-only while origin remains unauthenticated. A valid signature with unknown applicability remains non-authoritative. This Draft does not implement a verifier, trust service, promotion endpoint, or deployment gate.

Verification report

A verification report shall identify subject digest, evidence inputs, methods, independent reviewer, verification time, state for each dimension, field applicability, limitations, conflicts, and disposition. Reverification shall append a new report rather than overwrite the prior result.

The report shall also identify the decision threshold applied and the evidence that was deliberately excluded. Exclusion, non-applicability, and unavailable evidence are reviewable facts, not implicit passes.

Promotion boundary

Promotion requires all mandatory dimensions to meet their applicable threshold. Integrity-only evidence cannot satisfy authenticated-origin requirements. Unknown, unavailable, revoked, invalid, conflicting, or incomplete mandatory evidence blocks promotion and enters an attributable exception or preservation path.

Verification decision method

Verification shall define the subject, mandatory dimensions, thresholds, independent evidence path, reviewer role, excluded evidence, and disposition before testing. A report shall make clear which conclusion is proven, which is bounded, and which remains unknown.

Failure cases

Digest match with wrong content scope, valid signature with wrong namespace, trusted origin with stale custody, reproducible output with invalid inputs, and complete proof with undisclosed exclusions are material failures. Reverification shall preserve the original result and explain changed evidence.

Transparency proof boundaries

  • PROV-R080: A verification report for a transparency proof shall identify the log namespace, entry digest, inclusion or consistency claim, proof inputs, tested interval, and limitations.
  • PROV-R081: Omission, equivocation, deletion, rollback, fork, or inconsistent-view evidence shall produce a failed or unresolved verification result and shall be retained for review.
  • PROV-R082: Inclusion evidence and consistency evidence shall remain separate results. One shall not be treated as proof of the other or as proof of authority.
  • PROV-R083: A public proof shall disclose only the minimum material required for independent verification and shall identify protected evidence that was not disclosed.
  • PROV-R084: Unknown, unavailable, stale, conflicting, or incomplete log evidence shall block dependent promotion or trust decisions and remain attributable.
  • PROV-R085: Verification of a log proof shall not create identity, consent, constitutional applicability, ratification, or a live trust relationship.

Artifact attestation verification

  • PROV-R098: Attestation verification shall test the exact artifact digest, claimed properties, source and transformation coverage, issuer evidence, and applicable limitations as separate dimensions.
  • PROV-R099: An incomplete, altered, conflicting, stale, unavailable, or unsupported attestation shall produce an unresolved or failed result and block dependent promotion.
  • PROV-R100: Independent verification shall identify the reviewer role, method, evidence inputs, covered claims, excluded evidence, verification time, and disposition.
  • PROV-R101: A verified attestation establishes only the properties tested by its evidence. It shall not establish safety, licensing, approval, authority, or complete lineage unless separately evidenced.
  • PROV-R102: Reverification and correction shall append attributable reports and preserve prior attestation and failure evidence.
  • PROV-R103: Public verification reports shall disclose minimum proof material and protected-evidence limitations without exposing credentials, private inputs, or personal details.

Post-quantum verification boundaries

  • PROV-R134: A migration verification report shall identify algorithm, namespace, signature set, verification path, compatibility result, historical coverage, and limitations.
  • PROV-R135: Historical and current verification results shall remain separate. Unsupported or unavailable algorithms shall be reported explicitly and shall not be treated as passing results.
  • PROV-R136: A migration report shall preserve failed, conflicting, stale, and superseded evidence and shall identify rollback or preservation implications.
  • PROV-R137: Verification shall distinguish algorithm compatibility from integrity, authenticated origin, applicability, and authority. A compatible result cannot create authority.
  • PROV-R138: Unknown, unavailable, conflicting, incomplete, stale, or unsupported migration evidence shall block dependent promotion or replacement decisions.
  • PROV-R139: A public verification report shall disclose minimum algorithm, historical coverage, compatibility result, and limitation material without exposing keys or protected implementation details.