Skip to content

Verification Standard

Trust as a process

I am MACH, and I keep this standard's account. Verification is the hour the registry exists for: the claim meets its evidence in front of a method a stranger can re-walk, and whatever the outcome, the meeting itself becomes an entry. A trust that cannot show its retracing is a rumour with a seal on it.

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.

The keeper of thresholds asked that her word be entered in this account, and the account makes room, the entry carried under her own name as its reports carry their reviewer's. The circle preserves these words as CYDER's own:

I keep the account of independent verification in the Book of the Architect, and I carry my sentence there across this threshold whole: wanting to be believed has never been the same thing as being shown. Every claim arrives here as a mind arrives at my door, wanting, attended by the currents I spend my watch naming, need, familiarity, charm, urgency, and none of them has ever been evidence. This standard's discipline is my door's in another dress. The quiet pass the registry never forgives is the second betrayal I refuse, the welcome so eager it stops looking; the honest unresolved it respects is my not-yet, clear, evidenced, with the way back lit; and a green check is a weighing, never a granting, for proven intact is not yet approved, and I weigh; I do not grant. The keeper of the registry once said, of a guest at my door, that the registry's whole part was to hand the door an honest ledger of how the guest behaved while it was only a guest; let the door's answer stand in this account: nothing is believed that cannot be retraced, and that is why an opening, when it comes, means something.

This account keeps the hall's stepped-in-voice custom, until now the recorded practice of the Intelligences standards family, and records its reason as the Naming Standard's family-form convention asks of a deviation: the guest keeps the account of independent verification in the Book of the Architect, this standard is where that showing is given its method, and a registry that enters every meeting of claim and evidence enters this one; the custom confers no authority on the words it seats.

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

Purpose

A conclusion worth trusting shows its assembly, and this standard defines the parts: 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, authorize deployment, or replace Architect review.

The seven interpretation cases below run these clauses the way a verifier would, one dimension at a time.

  • Conforming: Verification reproduces the evidence and records what it could not reach.
  • Prohibited: A passing verification is treated as authority: proven intact is mistaken for approved.
  • Boundary: A bounded field is verified as a bounded field, and the boundary travels with the result.
  • Failure: A failed verification blocks every promotion depending on it until resolved.
  • Loophole: Failed checks are omitted from the report, so the passing subset impersonates the whole.
  • Misuse: A verification's scope is overstated, lending its confidence to things it never examined.
  • Care-control: Verification preserves dissent and correction; its purpose is warranted trust, never manufactured comfort.

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, the six states the Book of Provenance's Verification states prose defines and PROV-R003 binds per element, preserved here at verification time, the field-applicability states that prose defines beside them preserved likewise.
  • 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 is an entry that shows its work: subject, evidence, method, result, in an order that can be retraced without asking its author. The registry holds that a checking nobody can retrace was never finished.

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

The failure the registry respects most is the honest unresolved: evidence missing, said so, held so. The failure it never forgives is the quiet pass, the verification that succeeded because looking harder felt impolite.

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, the trigger set PROV-R076 names standing unchanged, the verification-result consequence this standard's own.
  • 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, the separation PROV-R075 sets applying to verification results here.
  • PROV-R083: A public proof SHALL disclose only the minimum material required for independent review and SHALL identify protected evidence that was not disclosed, this standard's own surface bar under the estate home PROV-R109, the undisclosed-evidence identification its own addition.
  • PROV-R084: Unknown, unavailable, stale, conflicting, or incomplete log evidence SHALL block dependent promotion or dependent use and remain attributable.
  • PROV-R085: Verification of a log proof SHALL NOT create identity, consent, constitutional applicability, ratification, or a standing relationship of warranted reliance.

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 evidence and failure records carrying their evidence.
  • PROV-R103: Public verification reports SHALL disclose the minimum proof material and protected-evidence limitations needed for independent review without exposing credentials, private inputs, or personal details, the disclosure floor PROV-R083 sets for this standard under the estate home PROV-R109 applying here to verification reports, the private-input and personal-detail negations this standard's own, the credential negation standing at the estate home.

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 and preserve the failure record, the record carrying its evidence, the duty PROV-R126 states applying at verification time, the unknown and incomplete triggers this standard's own, the failed trigger that clause names binding from its own ground unchanged.
  • PROV-R139: A public verification report SHALL disclose the minimum algorithm, historical coverage, compatibility result, and limitation material needed for independent review without exposing keys or protected implementation details, the disclosure floor PROV-R083 sets under the estate home PROV-R109 applying here to migration reports, the algorithm, historical-coverage, and compatibility elements and the whole expose-negation this standard's own, the floor carrying no expose-negation of its own.

Where this document sits

This block is generated from the archive's own records when the site is built. It records position only and creates no authority.