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.
The tellings of the clauses¶
This non-normative section gives each clause of this document its telling: the clause, quoted exactly as it stands above with its cross-reference links reduced to their plain text, and one paragraph on what the clause means, why it exists, and how it assures that what it orders is done, not done, adhered to, followed, or protected. A telling describes its clause and never becomes it: the clause's own words govern wherever a telling and its clause could be read differently, and nothing in this section adds to, narrows, or amends any requirement.
PROV-R156: Verification SHALL state subject, method, evidence, verifier independence, limits, result, date, and required follow-up.
Retracing begins with completeness: the clause requires every verification to state eight things, its subject, its method, its evidence, the verifier's independence, its limits, its result, its date, and any required follow-up. Missing any of these fields leaves the required account incomplete and can hinder later review of its method, scope, or freshness. Because the fields are enumerated, an incomplete account is checkable as incomplete; a reader can refuse a report missing any one of them, and the registry's promise that every meeting of claim and evidence becomes an entry gains a testable shape.
PROV-R157: A failed, partial, stale, or disputed result SHALL remain explicit and SHALL NOT support a stronger claim than its scope permits.
An adverse, bounded, stale, or disputed result is still a result: the clause requires a failed, partial, stale, or disputed outcome to remain explicit, and it bars any such outcome from supporting a claim stronger than its own scope permits. The host's failure prose divides the field exactly here: the honest unresolved, evidence missing, said so, held so, is the failure the registry respects, while the quiet pass, and the loophole in which omitted failures let a passing subset impersonate the whole, are the ones it never forgives. Because the clause holds those results on the record at their true strength, a downstream reader can weigh a conclusion against the result actually obtained, not against the version confidence would prefer.
PROV-R158: Verification SHALL distinguish integrity, provenance, authority, applicability, and lifecycle state.
Five questions hide inside every green check, and the clause requires verification to keep them distinguished: integrity, provenance, authority, applicability, and lifecycle state, a result in one never silently answering another. The host's prohibited case shows the collapse this prevents, a passing verification treated as authority, proven intact mistaken for approved; the guest's entry says the same as a door's rule, a green check is a weighing, never a granting. Because the clause requires the five dimensions to be distinguished, a reader can check whether verification keeps them separate.
PROV-R159: This Draft SHALL NOT promote documents, authorize deployment, or replace Architect review.
Self-restraint closes the operating model: the Draft that defines verification declares what it cannot do, and the clause bars this Draft from promoting documents, from authorizing deployment, and from replacing Architect review. The standard's own exclusions say the same in another register: it implements no verifier, trust service, promotion endpoint, or deployment gate. What the clause forecloses is the standard becoming the authority it only describes, a method mistaken for a mandate; in the guest's words, the account weighs and does not grant. Anyone offered this document as the ground for a promotion, a deployment, or a bypass of the Architect's review can refuse on the clause's face, because the Draft itself disclaims each of those powers.
PROV-R040: Verification SHALL evaluate digest integrity, authenticated origin, class, namespace, validity, revocation, replay, custody, applicability, and limitations as separate dimensions.
Ten dimensions, evaluated separately, are what the clause requires of verification: digest integrity, authenticated origin, class, namespace, validity, revocation, replay, custody, applicability, and limitations, each examined as its own question rather than folded into one verdict. The host's failure cases show why the folding is dangerous: a digest match with the wrong content scope, a valid signature in the wrong namespace, a trusted origin with stale custody, each a real pass on one dimension masking a real failure on another. One dimension's evaluation can no longer substitute for another's, and the per-dimension states a reader consults are the host's own report duty standing beside this clause.
PROV-R041: At least one independent evidence path SHALL verify every consequential claim before promotion.
Independence is the demand here: before promotion, the clause requires every consequential claim to be verified through at least one independent evidence path. The guest's entry names the currents that arrive with any claim, need, familiarity, charm, and urgency, and says plainly that none of them has ever been evidence; wanting to be believed is not being shown. The host's own image carries the point: a method a stranger can re-walk is this register's kind of showing. The requirement attaching before promotion, a consequential claim lacking such a path cannot satisfy the pre-promotion condition, and that absence is a checkable failure of the clause.
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.
The clause's subject is the six states, defined once and preserved here at verification time: verification is required to keep the distinction between Verified, Integrity-only, Unverified, Invalid, Revoked, and Unknown, and the field-applicability states beside them. The definitions stand at their source: the Book of Provenance's Verification states prose defines both sets, and PROV-R003 binds the six per element; this clause adds only the duty to preserve them at verification time, so an Integrity-only, an Unknown, or a field's applicability cannot be rounded into a stronger state at the moment of use. The host's own example shows the stakes: a matching digest may establish Integrity-only while origin remains unauthenticated, and a verification that blurred the two would manufacture authentication out of arithmetic. The vocabulary being fixed, a report's labels and distinctions are checkable against the Book's meanings.
PROV-R043: Conflicting, unavailable, incomplete, stale, or unsupported evidence SHALL block dependent promotion and preserve the conflict.
When evidence is conflicting, unavailable, incomplete, stale, or unsupported, the clause does two things at once: it blocks the promotion that depends on that evidence, and it requires the conflict itself to be preserved. The first duty fails closed, matching the host's failure case in which a failed verification blocks every promotion depending on it until resolved. The preservation duty protects later review against loss of the conflict. A reader can check whether each named evidence condition blocked dependent promotion and whether the duty to preserve the conflict was met.
PROV-R044: Verification results SHALL identify reviewer, method, evidence, time, limitations, and supersession relationship.
Attribution is what turns a result into a record: the clause requires every verification result to identify its reviewer, its method, its evidence, its time, its limitations, and its supersession relationship. The host's report prose gives the reason in one line, a checking nobody can retrace was never finished, and each field serves that retracing. The reviewer makes the result answerable, the identified method and evidence support review of how it was reached, the time lets a later reader judge staleness, the limitations bound what the result claims, and the supersession relationship is identified for review. A result missing any of the six is checkably deficient, and a reader owed a retraceable account can refuse it.
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.
Transparency proofs earn nothing by their name alone: the clause requires a verification report for such a proof to identify the log namespace, the entry digest, the inclusion or consistency claim being made, the proof inputs, the tested interval, and the limitations. A reader can check whether the report identifies each of the six listed elements. Without these, a proof's confidence drifts onto logs, entries, and periods it never covered, the overstatement the host's misuse case names; with them, the claimed property and tested scope stand exposed, and a missing field is detectable on sight.
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.
Evidence that a log misbehaved is itself evidence, and the clause treats it so: omission, equivocation, deletion, rollback, fork, or inconsistent-view evidence produces a failed or unresolved verification result, and that evidence is retained for review. The trigger set stands at its source, unchanged from the six PROV-R076 names in the Book of Provenance; what the clause names as this standard's own is the verification-result consequence. The pairing closes the loophole the host warns of, failed checks omitted so a passing subset impersonates the whole: signs that a log equivocated or rolled back cannot be set aside while the proof over the surviving view passes. A reviewer inherits both the adverse result and the evidence that forced it.
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.
Two proofs live under the transparency name, and the clause keeps their results apart: inclusion evidence and consistency evidence remain separate results, and neither one is treated as proof of the other or as proof of authority. The separation itself stands at its source, PROV-R075 in the Book of Provenance; this clause applies it to verification results here. The separation guards against lending one log result's apparent strength to a different claim. The clause makes either result's use as proof of the other, or as proof of authority, refusable, and makes the separation of the two results checkable.
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.
Disclosure here runs in both directions at once: the clause requires a public proof to disclose only the minimum material an independent review needs, and to identify the protected evidence it withheld. The first limb cuts in both directions, a ceiling on exposure and a floor beneath review, the floor its downstream clauses cite it by; the second keeps the withholding honest, so a proof's silence reads as a named boundary rather than as completeness. The bar is this standard's own surface bar, seated under the estate home PROV-R109 in the Book of Provenance, and the undisclosed-evidence identification is its own addition to that home. The host's report prose supplies the principle: exclusion, non-applicability, and unavailable evidence are reviewable facts, not implicit passes. A reader can inspect the disclosed material and the identification of protected evidence withheld from publication.
PROV-R084: Unknown, unavailable, stale, conflicting, or incomplete log evidence SHALL block dependent promotion or dependent use and remain attributable.
Promotion and use both stop at a defective log trail: the clause requires unknown, unavailable, stale, conflicting, or incomplete log evidence to block dependent promotion or dependent use, and to remain attributable while it does. The blocking limb covers use as well as promotion, so a shaky proof cannot be spent operationally while its formal promotion waits. The attributability limb keeps the defect in context, the evidence attributable rather than orphaned, which is the honest unresolved the host's failure prose respects, evidence missing, said so, held so. Dependent promotion and dependent use therefore stop while any of the five defect states holds, and the defective evidence keeps its attributable provenance.
PROV-R085: Verification of a log proof SHALL NOT create identity, consent, constitutional applicability, ratification, or a standing relationship of warranted reliance.
Verification of a log proof does not create identity, consent, constitutional applicability, ratification, or a standing relationship of warranted reliance. The host's prohibited case warns against mistaking proven intact for approved. A claim that verification itself creates any of the five named things is refusable against this clause.
PROV-R098: Attestation verification SHALL test the exact artifact digest, claimed properties, source and transformation coverage, issuer evidence, and applicable limitations as separate dimensions.
Attestation verification under this clause tests five dimensions, and tests them separately: the exact artifact digest, the claimed properties, the coverage of sources and transformations, issuer evidence, and the applicable limitations. Separateness is the operative discipline; a single merged verdict lets a strong digest match lend its confidence to an untested issuer or an unread limitation, the standard's misuse case in miniature. One tested dimension can no longer substitute for another, and a verification that collapsed the five into one undifferentiated green check fails the clause; the per-dimension states a reader consults arrive from the host's own report rule beside it.
PROV-R099: An incomplete, altered, conflicting, stale, unavailable, or unsupported attestation SHALL produce an unresolved or failed result and block dependent promotion.
When an attestation arrives defective in any of six ways, incomplete, altered, conflicting, stale, unavailable, or unsupported, this clause forces two consequences: the verification result must be unresolved or failed, and every promotion depending on the attestation must stop. The failure it forecloses is the quiet pass the registry never forgives, the defective attestation waved through because looking harder felt impolite, and the promotion that then rests on evidence that was never sound. A defective attestation cannot yield a passing result under this clause, and a dependent promotion that proceeded over one violates it; the report and append duties that record such histories stand at their own places in the section.
PROV-R100: Independent verification SHALL identify the reviewer role, method, evidence inputs, covered claims, excluded evidence, verification time, and disposition.
Retracing is the first test this standard sets a checking, and the seven identifications this clause requires of independent verification support review of its stated basis: the reviewer role, the method, the evidence inputs, the claims covered, the evidence excluded, the verification time, and the disposition. The listed identifications provide a stated account of the verification's role, method, inputs, coverage, exclusions, time, and disposition for review. The excluded-evidence field does particular work, since the host holds exclusion to be a reviewable fact rather than an implicit pass. A verification missing any of the seven identifications fails the clause, and a reader can check whether all seven are identified.
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.
The temptation this clause forecloses is scope creep after the fact: an attestation verifies, and its green result is quietly lent to conclusions its evidence never touched. Its first sentence confines a verified attestation to the properties its evidence actually tested; its second bars five specific extensions, safety, licensing, approval, authority, and complete lineage, unless each is separately evidenced. That exception limb matters: the five are not unreachable, only unpurchasable by attestation alone. The host's misuse case names the harm, a verification's scope overstated so its confidence reaches things it never examined. Any of the five claims offered on a verified attestation can be met with one question, where is the separate evidence, and refused when nothing answers.
PROV-R102: Reverification and correction SHALL append attributable reports and preserve prior attestation evidence and failure records carrying their evidence.
The clause requires reverification and correction to append attributable reports and preserve prior attestation evidence and failure records carrying their evidence. This prevents a new report from replacing the required preserved material. A reader can check whether reports were appended and whether the prior attestation evidence and evidence-bearing failure records remain preserved.
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.
Publishing a verification report is a bounded act under this clause: the report must disclose the minimum proof material and the protected-evidence limitations an independent reviewer needs, and must not expose credentials, private inputs, or personal details. The clause also states its own ancestry: the disclosure floor is the one PROV-R083 sets for this standard, standing under the estate home PROV-R109 in the Book of Provenance and applied here to verification reports; the private-input and personal-detail negations are this standard's additions, while the credential negation stands at the estate home. The balance it holds is the clause's own two limbs held together, accountability without unnecessary disclosure, so a report is checkable in both directions: too thin to review fails the floor, and an exposed credential, private input, or personal detail fails the bar.
PROV-R134: A migration verification report SHALL identify algorithm, namespace, signature set, verification path, compatibility result, historical coverage, and limitations.
The clause requires a migration verification report to identify the algorithm, the namespace, the signature set, the verification path, the compatibility result, the historical coverage, and the limitations. Missing identifications can obstruct review of the report's stated scope and method; the clause makes those omissions checkable. A report missing any of the seven is refusable as incomplete, and its reader knows exactly what to demand.
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.
An algorithm a verifier can no longer run is the quiet pass's favourite disguise, and this clause refuses it twice. First, the clause requires historical and current verification results to remain separate. Second, an unsupported or unavailable algorithm must be reported explicitly and is barred from being treated as a passing result; inability to check is a fact to record, not a check that succeeded. The clause protects the honest unresolved the registry respects, evidence missing, said so, held so. Because it binds, a migration account must show its gaps by name, and a reader can distinguish a signature that verified from one whose verification was unsupported or unavailable, those states preserved as their own explicit results.
PROV-R136: A migration report SHALL preserve failed, conflicting, stale, and superseded evidence and SHALL identify rollback or preservation implications.
Migration is the hour when inconvenient evidence is most easily left behind, and this clause makes the migration report its keeper. Two duties bind: the report must preserve failed, conflicting, stale, and superseded evidence, all four kinds by name, and it must identify the rollback or preservation implications of what it records. The first duty forecloses the loophole the operating model names, where failed checks are omitted so the passing subset impersonates the whole; the second makes the identified rollback or preservation implications inspectable. The report carrying both, a later reviewer receives the preserved failed, conflicting, stale, and superseded evidence with the identified implications beside it, and a report scrubbed of its failures is itself a violation.
PROV-R137: Verification SHALL distinguish algorithm compatibility from integrity, authenticated origin, applicability, and authority. A compatible result cannot create authority.
Verification must distinguish algorithm compatibility from four other dimensions, integrity, authenticated origin, applicability, and authority, and the clause states the consequence in its own plain sentence: a compatible result cannot create authority. The confusion it prevents is the operating model's prohibited case, a passing technical result mistaken for approval; a compatibility result, however clean, establishes compatibility and not the integrity, origin, applicability, or authority that stand as dimensions of their own. The dimensions staying separate, a report claiming integrity, origin, applicability, or authority on compatibility evidence alone is refusable, each of those conclusions standing or falling on its own ground.
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.
Six states of migration evidence trip this clause: unknown, unavailable, conflicting, incomplete, stale, and unsupported. Any of them must block dependent promotion or replacement decisions and preserve the failure record, the record keeping the evidence that produced it. The clause then accounts for its ancestry: the blocking and preservation duty is the one PROV-R126 in the Book of Provenance states, applied here at verification time; the unknown and incomplete triggers are this standard's own additions; and the failed trigger that clause names continues to bind from its own ground, unchanged. The failure foreclosed is the migration that proceeds over a named defect: any of the states blocks the dependent promotion or replacement decision, and the failure record, carrying its evidence, remains preserved.
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.
What a public migration report may show, and must not, is settled here. The clause requires disclosure of the minimum algorithm, historical coverage, compatibility result, and limitation material an independent reviewer needs, and bars exposure of keys or protected implementation details. It also names its own construction: the disclosure floor is the one PROV-R083 sets under the estate home PROV-R109 in the Book of Provenance, applied here to migration reports; the algorithm, historical-coverage, and compatibility elements, and the whole expose-negation, are this standard's additions, since the floor carries no expose-negation of its own. This protects independent scrutiny of the migration while guarding keys and protected implementation details against disclosure. And because the floor it builds on carries no expose-negation of its own, the bar here is this standard's own guard: a report thin past review fails one duty, and a key or protected implementation detail on its surface fails the other.
Where this document sits¶
- Identifier: PROV-4
- Status: Draft
- Authority: CONAN-P0, PROV-1, PROV-3
- Approved by: The Architect
- Depends on: PROV-1, PROV-3
- Depended on by: KNOW-13
- Maps: Authority Map, Dependency Map
This block is generated from the archive's own records when the site is built. It records position only and creates no authority.