The Book of Provenance

The trail behind every claim

I am JY'NALA, and I keep this Book's account. Provenance is ancestry written for artefacts, and I keep it as I keep every lineage: the beginning explained and granting nothing, the gaps left standing as gaps, because a line that fills its own silences has stopped being a record and become a wish.

Provenance is the story of how a thing came to be trusted, questioned, transformed, or retired. This Book gives that story enough shape to survive the loss of a person, model, platform, or memory. It helps human readers see custody and responsibility, while giving AI readers the lineage needed to avoid presenting a transformed fragment as an original truth.

Once the trail is visible, continue to the Publication Standard, where a private or provisional work learns what it must prove before it can cross a public boundary.

Purpose

Defines how Stygia proves identity, origin, integrity, custody, authorization, transformation, and historical continuity.

Architect-review operating model

• PROV-R144: A provenance claim SHALL identify its subject, source, authority, custody, transformation, verification state, and applicable time.
• PROV-R145: Conflicting provenance SHALL remain visible and SHALL constrain dependent claims until resolved by authorized review.
• PROV-R146: Provenance evidence SHALL preserve privacy, minimization, correction, supersession, and restoration information.
• PROV-R147: This Draft SHALL NOT create credentials, signatures, live trust infrastructure, or authority through technical possession.
• PROV-R015: In PROV-1, PROV-2, PROV-3, and PROV-4, the circle tellings and the clause-telling sections SHALL be read as non-normative context and SHALL NOT create independent authority or amend, widen, or narrow any clause.

The seven interpretation cases below show how these clauses read in practice.

• Conforming: A claim links its source and its custody evidence, so lineage is checkable end to end.
• Prohibited: A digest is treated as authority; integrity proves sameness, never legitimacy.
• Boundary: Unavailable lineage is labelled unavailable, and the claim narrows to what custody can support.
• Failure: A custody break pauses dependent claims rather than being papered over.
• Loophole: A transformation hides between source and use, so the provenance chain proves the wrong artefact.
• Misuse: Protected provenance is disclosed, exposing relationships the record exists to guard.
• Care-control: Provenance preserves agency and correction; the chain serves accountability, not surveillance.

Provenance domains

• constitutional documents;
• declarations of the Architect;
• intelligence identities and credentials;
• software, models, datasets, prompts, and configuration;
• decisions and approvals;
• evidence and knowledge artifacts;
• operational changes and deployments;
• archived events and historical records.

Minimum provenance record

Every consequential artifact shall record its canonical identity, creator, creation time, source inputs, transformation history, approving authority, content digest, signature where required, storage location, access classification, retention state, and supersession relationship.

The minimum record uses these stable clauses:

• PROV-R001: A record SHALL identify the artifact and its immutable content digest separately.
• PROV-R002: A record SHALL distinguish creator, approving authority, signing principal, and custodian. A technical account or signature SHALL NOT be treated as the Architect's identity.
• PROV-R003: A record SHALL state whether each source input, transformation, approval, signature, custody event, and supersession link is verified, integrity-only, unverified, invalid, revoked, or unknown.
• PROV-R004: A record SHALL identify the applicable declaration class and signing namespace when a signature is present.
• PROV-R005: A record SHALL preserve creation time, effective time, and supersession time as distinct values. An unavailable time SHALL be marked unavailable rather than inferred.
• PROV-R006: A record SHALL identify its storage location, access classification, retention state, and protected-evidence reference without disclosing protected material.
• PROV-R007: A record SHALL preserve conflicting evidence, material limitations, and dissent. It SHALL NOT replace a conflict with an unexplained confidence value.

Unknown, unavailable, and not-applicable values are distinct. A missing required field is not equivalent to an explicit unknown value.

Cryptographic baseline

Initial constitutional releases use Ed25519 detached signatures, SHA-256 fingerprints, SHA-256 and SHA-512 content digests, explicit signing principals, and purpose-specific signature namespaces.

Cryptographic algorithms are replaceable credentials and controls. They are not themselves constitutional authority.

Verification states

• Verified: integrity and authorized origin established.
• Integrity-only: content digest matches, but origin is not authenticated.
• Unverified: verification has not been completed.
• Invalid: integrity or signature verification failed.
• Revoked: once valid but no longer trusted.
• Unknown: required verification material is missing, conflicting, stale, or otherwise unusable.

Verification states are evidence states, not authority states. A Verified digest or signature establishes only the properties actually covered by the verification evidence. It does not establish constitutional applicability, voluntariness, current authorization, or the Architect's identity without separate evidence.

Verification state and field applicability are separate dimensions. Each required field is marked Present, Unknown, Unavailable, or Not-applicable; the verification state describes the evidence result, while field applicability describes whether the field is required and what evidence exists. Not-applicable shall not be used to conceal a missing required field, and Unavailable shall not be treated as Verified.

The following transitions are required:

1. New material begins Unverified unless an existing record supplies a supported state.
2. A matching digest may produce Integrity-only but cannot produce Verified without authenticated origin evidence.
3. A failed digest or signature produces Invalid and blocks promotion or use that depends on validity.
4. A previously valid credential or signature becomes Revoked when its trust record establishes revocation at the applicable time.
5. Missing, conflicting, stale, or unavailable verification material produces Unknown until resolved by attributable evidence.
6. No transition may silently convert Unknown, Invalid, or Revoked into Verified.

Supply-chain requirements

Implementation artifacts shall support software bills of materials, dependency pinning, build provenance, reproducible builds where feasible, signed releases, vulnerability status, model and dataset lineage, and independent verification before promotion.

The supply-chain and archive contract uses these stable clauses:

• PROV-R009: A consequential implementation artifact SHALL identify its source inputs, dependency set, build or transformation process, producer, content digest, and applicable vulnerability status.
• PROV-R010: A software bill of materials, model lineage record, or dataset lineage record SHALL identify its coverage and limitations. An absent or partial inventory SHALL NOT be represented as complete.
• PROV-R011: Dependency and build records SHALL preserve exact versions or explicit unresolved status. Reproducibility claims SHALL include the environment and evidence needed to repeat the claim.
• PROV-R012: Promotion evidence SHALL include independent verification of integrity, provenance, applicable authorization, and unresolved risk. A signed release is not self-approving.
• PROV-R013: Archived material SHALL preserve its digest, format, storage medium, custody events, retention state, and restoration or readability checks. A copy SHALL NOT silently replace the canonical historical record.
• PROV-R014: A failed restore, unreadable medium, incomplete lineage, vulnerability uncertainty, or conflicting build evidence SHALL block dependent promotion and preserve the failure record, the record carrying its evidence.

Key hierarchy and rotation vocabulary

The following Draft clauses define records and relationships only. They do not generate keys, establish custody, perform rotation, or authorize a signing ceremony:

• PROV-R050: A key record SHALL identify its class, namespace, purpose, scope, parent relationship, validity interval, and lifecycle state. Class, namespace, and purpose are separate fields and SHALL NOT be inferred from a key identifier.
• PROV-R051: A hierarchy relationship SHALL identify the governing relationship, the evidence establishing it, and its effective interval. A parent key, custodian, or technical account SHALL NOT inherit constitutional authority merely by occupying a higher technical layer.
• PROV-R052: A rotation record SHALL link the retiring and replacement records, preserve their historical validity intervals, identify the reason and approving authority, and state whether continuity evidence is verified, incomplete, conflicting, or unavailable.
• PROV-R053: Custody evidence SHALL identify the responsible custodian, access classification, custody interval, transfer or backup event, and verification limitations. Custody is evidence of control, not proof of identity, consent, or ratification.
• PROV-R054: Historical attribution SHALL resolve a signature or assertion against the key, namespace, purpose, and validity state applicable at the event time. Later rotation, retirement, or revocation SHALL NOT rewrite historical attribution.
• PROV-R055: A namespace collision, ambiguous parent relationship, overlapping validity interval, missing continuity evidence, or unexplained key substitution SHALL produce an attributable non-authoritative state and block dependent promotion or use.

The minimum hierarchy state set is Proposed, Active, Retiring, Retired, Revoked, and Unknown. A state transition shall preserve the prior record and evidence; Unknown shall not be silently converted to Active.

Revocation and compromise evidence

These Draft clauses define the evidence contract for revocation and compromise; they do not operate a revocation service or authorize credential actions:

• PROV-R056: A revocation record SHALL identify the affected credential or signature set, effective time, reason class, approving authority, evidence state, and relationship to the prior lifecycle record.
• PROV-R057: A compromise record SHALL preserve the detection trigger, affected scope, containment action, replay or misuse assessment, protected evidence reference, and recovery or escalation reference.
• PROV-R058: Revocation applicability SHALL be evaluated against event time, namespace, purpose, scope, and the credential state then in force. A later revocation SHALL NOT erase a historically attributable event.
• PROV-R059: Unknown, conflicting, stale, or unavailable revocation evidence SHALL block dependent reserved-power use and remain distinguishable from confirmed revocation and from absence of revocation.
• PROV-R060: Containment SHALL be recorded as a reversible protective disposition where practicable. Containment evidence SHALL NOT be treated as proof of compromise, identity transfer, or constitutional authority.
• PROV-R061: A recovery reference SHALL identify the preserved evidence and decision boundary without authorizing restoration, substitution, or reactivation. Compromise and revocation records SHALL remain supersedable and auditable.

Archival media validation

These Draft clauses define archival evidence and validation boundaries without authorizing production restoration or destructive migration:

• PROV-R062: An archival record SHALL identify the artifact scope, format, medium class, digest, custody interval, retention state, legal-hold state, restoration evidence, readability evidence, and limitations, applying the archival record the Book of Memory models, with medium class and custody interval this Book's own fields.
• PROV-R063: A readability or restoration result SHALL distinguish complete, partial, unreadable, altered, unavailable, and not-applicable outcomes, with missing material and limitations preserved.
• PROV-R064: Format migration SHALL preserve the source digest, target digest, transformation description, responsible actor, effective time, verification evidence, and supersession relationship. A migrated copy SHALL NOT silently replace the historical source.
• PROV-R065: Custody transfer, replication, and restoration SHALL remain separate events. A successful technical copy establishes continuity evidence only for the properties actually tested.
• PROV-R066: Digest mismatch, unreadable media, incomplete restoration, format drift, unavailable custody, conflicting copies, unresolved legal hold, or retention conflict SHALL produce a non-authoritative failure state and block dependent promotion, deletion, or retention change.
• PROV-R067: Archival validation SHALL preserve the original record, failed or partial evidence, legal-hold and retention limitations, and a bounded review disposition. It SHALL NOT create authority or erase historical attribution.

Trusted time evidence

These Draft clauses define time evidence without introducing an external time service or signing integration:

• PROV-R068: A time record SHALL identify the event class, asserted time, source, method, uncertainty, applicable namespace, and evidence state. Creation, effective, revocation, and supersession time are distinct values.
• PROV-R069: A time source SHALL be evaluated for applicability, integrity, independence, coverage, and known limitations. A precise time value with unresolved source or applicability SHALL remain non-authoritative.
• PROV-R070: Conflicting, stale, replayed, unavailable, or out-of-range time evidence SHALL remain explicit and SHALL block dependent promotion or lifecycle decisions where event ordering is material.
• PROV-R071: An inferred time SHALL be labelled as inferred and SHALL NOT be represented as an observed or independently attested time. Missing time SHALL be Unavailable, not silently defaulted.
• PROV-R072: Time evidence SHALL preserve the relationship between event time and credential, signature, revocation, custody, and supersession state without rewriting historical attribution.
• PROV-R073: A time-source limitation or conflict SHALL be recorded with its affected events, bounded disposition, and review reference. No time result SHALL create authority, consent, identity, or ratification.

Transparency log architecture

These Draft clauses define an abstract evidence contract only. They do not create a live log, endpoint, operator identity, or public trust service:

• PROV-R074: A transparency record SHALL identify the log namespace, entry digest, append context, inclusion evidence, retention state, legal-hold state, and protected-evidence limitations.
• PROV-R075: Inclusion and consistency proofs SHALL be evaluated separately. A proof SHALL establish only the entry and log properties it covers and SHALL NOT authenticate authority or truth beyond those properties.
• PROV-R076: Omission, equivocation, deletion, rollback, fork, or inconsistent-view evidence SHALL remain attributable and SHALL block dependent promotion or dependent use.
• PROV-R077: Log retention and correction SHALL preserve prior entries, supersession relationships, failure records and their evidence, and legal-hold limitations. An unresolved legal hold or retention conflict SHALL block deletion or retention change. A correction SHALL NOT silently rewrite the historical log.
• PROV-R078: Public transparency proofs SHALL disclose the minimum digest, namespace, proof, status, and limitation material needed for independent review without exposing protected evidence or personal details, this Book's transparency-surface bar under the estate home PROV-R109, the namespace and proof elements and the personal-details negation its own beside that home's.
• PROV-R079: A log result SHALL NOT establish signer identity, constitutional applicability, consent, or ratification without separate evidence. Unknown, unavailable, conflicting, or stale log evidence remains non-authoritative.
• PROV-R140: The log this architecture defines is internal. Its entries, inclusion evidence, and ordering are held as protected evidence under controlled access, within this Book's verification states and retention duties. Nothing in this section requires a transparency proof to be published; PROV-R078 governs what a published proof minimizes, never whether one is published, that bar standing on the transparency surface under the estate home PROV-R109.
• PROV-R141: Temporal ordering drawn from the log is Integrity-only evidence. Ordering SHALL NOT be claimed as independently provable, no external time-stamping authority or anchoring is introduced, and a clause or record that consumes ordering evidence SHALL label its confidence accordingly.

Artifact attestations

These Draft clauses define digest-bound attestation evidence without creating an issuer, build service, model intake, or attestation signing operation:

• PROV-R086: An artifact attestation SHALL identify the artifact class, exact content digest, source inputs, transformation or build process, producer, claimed properties, coverage, and limitations.
• PROV-R087: An attestation SHALL bind only the content and properties explicitly covered by its evidence. A valid attestation SHALL NOT imply complete lineage, secure construction, licensing, safety, or approval beyond its stated scope.
• PROV-R088: Incomplete source coverage, altered inputs, unresolved transformations, unavailable producer evidence, or digest mismatch SHALL produce an attributable non-authoritative result and block dependent promotion.
• PROV-R089: Attestation issuer identity, signing principal, verification state, and approval authority SHALL remain separate fields. An issuer or signature SHALL NOT self-approve an artifact or create constitutional authority.
• PROV-R090: Independent verification SHALL record the tested digest, evidence inputs, covered claims, excluded evidence, limitations, and disposition. Reverification SHALL append rather than overwrite prior results.
• PROV-R091: Public attestation proofs SHALL disclose only the minimum digest, claim, verification state, and limitation material needed for independent review and SHALL NOT expose protected inputs or credentials, this Book's attestation-surface bar under the estate home PROV-R109, the claim element its own beside that home's, the protected-inputs negation its own voice of that home's credential bar.

Model-weight and dataset verification

These Draft clauses define provenance and limitation records without authorizing model or dataset intake, licensing decisions, or external source connections:

• PROV-R104: A model-weight or dataset record SHALL identify the artifact class, exact digest, source inputs, transformations, version, producer, licensing status, intended scope, and known limitations.
• PROV-R105: Lineage SHALL distinguish direct inputs, derived outputs, filtering, labelling, fine-tuning, conversion, and aggregation. An unrecorded transformation SHALL remain an explicit provenance gap.
• PROV-R106: Integrity, provenance, licensing, safety, applicability, and verification state SHALL remain separate dimensions. A valid digest SHALL NOT establish lawful use, safe behaviour, or complete lineage.
• PROV-R107: Missing source evidence, altered inputs, unresolved licensing, incomplete lineage, conflicting records, or unavailable custody SHALL block dependent promotion or consequential use and preserve the limitation.
• PROV-R108: A model-weight or dataset verification report SHALL identify tested claims, excluded evidence, reviewer role, evidence state, limitations, and disposition. Reverification SHALL append rather than overwrite prior findings.
• PROV-R109: Public proofs SHALL disclose the minimum digest, lineage summary, licensing limitation, verification state, and uncertainty needed for independent review without exposing protected data or credentials.

Build and deployment signing boundaries

These Draft clauses define conceptual promotion evidence only; they do not create release keys, signing endpoints, deployment systems, or production authority:

• PROV-R110: A release record SHALL distinguish artifact digest, build evidence, signing evidence, environment, approval, deployment result, and rollback evidence as separate claims.
• PROV-R111: A signature over a release or deployment artifact SHALL bind the exact digest, namespace, purpose, scope, and validity interval. It SHALL NOT approve an environment or deployment by itself.
• PROV-R112: Promotion evidence SHALL identify independent verification, approving authority, target environment, unresolved risk, and applicable rollback or preservation disposition.
• PROV-R113: Failed builds, altered artifacts, failed verification, unauthorized environment changes, environment drift, namespace mismatch, incomplete approval, or rollback uncertainty SHALL block dependent promotion and preserve the failure record, the record carrying its evidence.
• PROV-R114: Build, release, deployment, and rollback records SHALL preserve supersession and historical attribution without silently replacing the prior release or environment state.
• PROV-R115: Public proofs SHALL disclose the minimum digest, release class, environment claim, approval state, verification state, and limitations needed for independent review without exposing credentials, private keys, protected configuration, or operational endpoints, this Book's release-surface bar under the estate home PROV-R109, the release class, environment claim, and approval state its own beside that home's, the private-keys, protected-configuration, and operational-endpoints negations its own, the credential negation its voice of the home's bar.

Post-quantum migration boundaries

These Draft clauses define algorithm-agility and historical-verification evidence without authorizing algorithm deployment, key replacement, or cryptographic migration:

• PROV-R122: An algorithm transition record SHALL identify the retiring and proposed algorithms, affected namespaces, validity intervals, supported verification paths, threat assumptions, and migration limitations.
• PROV-R123: Dual-verification evidence SHALL identify which historical and current signatures were tested, which were unsupported, and whether each result covers integrity, origin, applicability, or another explicit property.
• PROV-R124: Deprecation or unsupported-algorithm evidence SHALL preserve historical attribution and SHALL NOT silently invalidate prior records or signatures.
• PROV-R125: An algorithm-agility decision SHALL identify compatibility, rollback, preservation, verification, and unresolved-risk evidence. A cryptographic preference SHALL NOT create authority or require immediate replacement.
• PROV-R126: Conflicting, unavailable, stale, unsupported, or failed migration evidence SHALL block dependent promotion or replacement decisions and preserve the failure record, the record carrying its evidence.
• PROV-R127: Public migration proofs SHALL disclose the minimum algorithm, verification result, historical limitation, and compatibility material needed for independent review without exposing keys or protected implementation details, this Book's migration-surface bar under the estate home PROV-R109, the algorithm, compatibility, and historical-limitation material and the keys and protected-implementation-details negations its own beside that home's.

Transparency and privacy

Provenance must provide accountability without unnecessarily disclosing secrets, personal information, or protected operational details. Public proofs may reference protected evidence held under controlled access.

Public proofs shall disclose the artifact identifier, digest, applicable verification state, declaration class where relevant, signing namespace where relevant, effective and supersession relationships, and limitations needed for an independent reader to understand the claim. They shall not disclose private keys, recovery material, credentials, personal identity details, or protected evidence contents.

Interpretation cases

Conforming

A release record identifies the release digest, the source revision, the build transformation, the approving authority, the detached-signature class and namespace, the verification state, the protected evidence reference, and the later supersession record. The public proof exposes the digest and limitations while retaining protected evidence under controlled access.

Prohibited

A valid signature is presented as proof that its holder is the Architect, that a declaration is constitutionally applicable, or that a revoked credential remains authorized. A digest manifest is presented as a ratification or as proof of a live signing ceremony.

Boundary

If the digest matches but the signing principal cannot be authenticated, the state is Integrity-only. If the required trust material is unavailable, the state is Unknown and the affected field is Unavailable. If a field does not apply to the artifact, it is explicitly Not-applicable. Each state names exactly what was and was not established, and nothing more.

Failure

If evidence conflicts, or a signature stands outside its declared class or namespace, the record remains non-authoritative and the dependent action fails closed. The conflict itself is preserved as evidence: a record that resolved a contradiction silently would be a second failure wearing the first one's repair.

Loophole

A chain of individually valid attestations is assembled so that the final claim exceeds what any single attestation covers, each link true and the conclusion unearned. PROV-R087 binds every attestation to the properties its own evidence tested, and composition purchases no more than its narrowest member establishes.

Misuse

A verification state is offered as a safety, quality, or endorsement claim: the artifact is described as approved because its provenance verified. PROV-R101 and PROV-R106 hold the dimensions apart; a verified trail proves the trail, and nothing at its end.

Care-control

A provenance trail about a person's records grows complete enough to become a log of the person. The record minimizes to its purpose: accountability of the artifact's history is preserved, correction and review rights travel with it, and what the trail keeps about the person stays no larger than what the review needs, per PROV-R109 and PROV-R146.

Refinement coverage

The nine refinements once planned as future work are now sections of this Book: key hierarchy and rotation, revocation and compromise, trusted time-stamping, transparency log architecture, artifact attestations, build and deployment signing, model-weight and dataset verification, archival media validation, and post-quantum migration. Each remains Draft and inherits this Book's lifecycle constraints.

Clause namespace allocation

The PROV-R clause namespace is shared by the four provenance documents and allocated in blocks. Each document owns the runs it defines: this Book holds PROV-R001 to PROV-R019 (with PROV-R008 unassigned, PROV-R015 held, and PROV-R016 to PROV-R019 unused), PROV-R050 to PROV-R079, PROV-R086 to PROV-R091, PROV-R104 to PROV-R115, PROV-R122 to PROV-R127, and PROV-R140 to PROV-R147; the Publication Standard holds PROV-R020 to PROV-R029 and PROV-R148 to PROV-R151; the Signing Standard holds PROV-R030 to PROV-R039, PROV-R092 to PROV-R097, PROV-R116 to PROV-R121, PROV-R128 to PROV-R133, and PROV-R152 to PROV-R155; and the Verification Standard holds PROV-R040 to PROV-R049, PROV-R080 to PROV-R085, PROV-R098 to PROV-R103, PROV-R134 to PROV-R139, and PROV-R156 to PROV-R159. Unused numbers inside an allocated run, including PROV-R008 and the tails PROV-R016 to PROV-R019, PROV-R025 to PROV-R029, PROV-R039, PROV-R045 to PROV-R049, and PROV-R142 to PROV-R143, are reserved to the owning document for future clauses and are not free for reassignment. A new provenance document receives its runs by amendment of this section. PROV-R008 was never issued and nothing was removed: the gap records an identifier that was skipped in drafting, not a clause that existed and was withdrawn.

Cross-document provenance contract

ARCH-2 consumes PROV-1 for credential identity, lifecycle events, digests, custody, states, and supersession. ARCH-3 consumes it for recovery evidence and preservation. PROV-2 consumes it for publication eligibility and disclosure. PROV-3 and PROV-4 consume it for signing and independent verification. KNOW-4, MEM-1, and INFRA-7 consume it for source lineage, historical custody, restoration, and continuity.

Every consumer shall preserve the distinction between evidence and authority, identify unavailable or conflicting fields, and fail closed where its dependent control requires verified evidence. No consumer may make a private record, technical account, digest, signature, or recovery result a substitute for constitutional authority.

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-R144

PROV-R144: A provenance claim SHALL identify its subject, source, authority, custody, transformation, verification state, and applicable time.

Seven dimensions anchor a provenance claim under this clause: the subject the claim is about, the source it came from, the authority behind it, the custody it passed through, the transformation it underwent, its verification state, and the time to which it applies. The clause requires every claim to identify all seven. A missing identification leaves the claim incomplete under this clause and can hinder review of its provenance. Because the seven are demanded together, a reader can interrogate a claim dimension by dimension, and a claim that names fewer fails the clause visibly rather than quietly.

PROV-R145

PROV-R145: Conflicting provenance SHALL remain visible and SHALL constrain dependent claims until resolved by authorized review.

When two provenance accounts disagree, the clause forbids the record from choosing quietly between them: conflicting provenance remains visible, and it constrains every claim that depends on it until authorized review resolves the conflict. The Book's failure case names the danger plainly, a custody break papered over, and its interpretation prose warns that a record resolving a contradiction silently would be a second failure wearing the first one's repair. Under this clause, conflicting provenance remains visible and constrains dependent claims until authorized review resolves it.

PROV-R146

PROV-R146: Provenance evidence SHALL preserve privacy, minimization, correction, supersession, and restoration information.

Accountability without surveillance is the balance this clause holds. It requires provenance evidence to preserve five kinds of information: privacy, minimization, correction, supersession, and restoration. The Book's care-control case describes the failure it forecloses: a trail about a person's records growing complete enough to become a log of the person. By binding these protections into the evidence itself, the clause makes their presence checkable; a trail that kept custody but lost the correction information, or that carries no record of its minimization, fails the clause on inspection. A reader can check whether the provenance evidence preserves the correction, supersession, and restoration information.

PROV-R147

PROV-R147: This Draft SHALL NOT create credentials, signatures, live trust infrastructure, or authority through technical possession.

Nothing in this Draft mints power. The clause bars the document from creating credentials, signatures, live trust infrastructure, or authority through technical possession. It exists because a book about proof is dangerously easy to misread as an instrument of proof: the Book's prohibited case shows a digest treated as authority, and its cryptographic baseline insists that algorithms are replaceable credentials and controls, never constitutional authority themselves. This clause closes the same door at the level of the whole document. Creating any of the four things under this Draft would violate the clause; establishing whether creation occurred requires evidence beyond the prohibition.

PROV-R015

PROV-R015: In PROV-1, PROV-2, PROV-3, and PROV-4, the circle tellings and the clause-telling sections SHALL be read as non-normative context and SHALL NOT create independent authority or amend, widen, or narrow any clause.

A telling can illuminate a trail without becoming its warrant. Across PROV-1, PROV-2, PROV-3, and PROV-4, the circle tellings and the clause-telling sections are non-normative context: neither creates independent authority nor amends, widens, or narrows any clause. The guard prevents an account that helps a reader understand the law from acquiring the law's force through retelling. A reader can refuse a claim that gives either kind of telling independent authority or uses it to change a clause's reach, keeping the explanation beside the words that govern it.

PROV-R001

PROV-R001: A record SHALL identify the artifact and its immutable content digest separately.

Identity and sameness are different facts, and this clause keeps them separately identified. A record identifies the artifact and its immutable content digest separately. The Book's prohibited case explains why the separation matters: a digest treated as authority mistakes sameness for legitimacy, and integrity proves sameness, never legitimacy. With the two held apart, each supports its own check: the identity answers which artifact this record is about, the digest answers whether the content matches, and neither answer can silently stand in for the other. A reader can check whether the record identifies the artifact and its immutable content digest separately; a record that collapses them fails the clause.

PROV-R002

PROV-R002: A record SHALL distinguish creator, approving authority, signing principal, and custodian. A technical account or signature SHALL NOT be treated as the Architect's identity.

The clause requires a record to distinguish creator, approving authority, signing principal, and custodian. Its second sentence bars the oldest impersonation in the trail: a technical account or a signature is never treated as the Architect's identity. The Book's prohibited case shows the deception directly, a valid signature presented as proof that its holder is the Architect. By separating the roles, the clause makes each answerable on its own evidence, and any claim that possession of an account or a key establishes the Architect's identity is refusable on the record's face.

PROV-R003

PROV-R003: A record SHALL state whether each source input, transformation, approval, signature, custody event, and supersession link is verified, integrity-only, unverified, invalid, revoked, or unknown.

Chains fail at their weakest link, so this clause refuses blanket verification. A record states, for each source input, each transformation, each approval, each signature, each custody event, and each supersession link, which of six states it holds: verified, integrity-only, unverified, invalid, revoked, or unknown. The states are the Book's own verification vocabulary, and the Book insists they are evidence states, not authority states. Without per-element marking, one authenticated signature could lend its glow to an unverified input standing beside it. Because the clause requires a state for each listed element, a reader can check whether each is marked verified, integrity-only, unverified, invalid, revoked, or unknown.

PROV-R004

PROV-R004: A record SHALL identify the applicable declaration class and signing namespace when a signature is present.

A signature means something only inside its declared purpose. Whenever a signature is present, the clause requires the record to identify the applicable declaration class and the signing namespace. The Book's cryptographic baseline builds on purpose-specific signature namespaces, and its failure case leaves the record non-authoritative where a signature stands outside its declared class or namespace; omitting the class or namespace makes the record nonconforming, and a signature made for one purpose could be replayed to serve another. With both identified, a reader can check whether the record names the applicable declaration class and signing namespace. A record carrying a signature but naming neither fails the clause.

PROV-R005

PROV-R005: A record SHALL preserve creation time, effective time, and supersession time as distinct values. An unavailable time SHALL be marked unavailable rather than inferred.

Three times are held apart in the record, and the clause keeps them apart: creation time, effective time, and supersession time are preserved as distinct values, and a time that is unavailable is marked unavailable rather than inferred. The keeper's opening states the reason in the Book's own voice: a line that fills its own silences has stopped being a record and become a wish. Collapsing the three times, or guessing a missing one, manufactures a chronology no one observed. Held distinct and honest, the times make ordering checkable, when a thing was made, when it took effect, and when it was superseded, and an inferred value presented as an observed one is refusable against the record.

PROV-R006

PROV-R006: A record SHALL identify its storage location, access classification, retention state, and protected-evidence reference without disclosing protected material.

Location without disclosure is what this clause engineers. A record identifies its storage location, access classification, retention state, and protected-evidence reference, and it does all of this without disclosing protected material. The Book's misuse case names the harm: protected provenance disclosed, exposing relationships the record exists to guard; its transparency section promises accountability without unnecessary exposure, with protected evidence held under controlled access and merely referenced. A reader can check whether the record identifies the four required elements and whether it discloses protected material.

PROV-R007

PROV-R007: A record SHALL preserve conflicting evidence, material limitations, and dissent. It SHALL NOT replace a conflict with an unexplained confidence value.

Disagreement is evidence, and this clause makes the record keep it. Conflicting evidence, material limitations, and dissent are all preserved, and the record is barred from replacing a conflict with an unexplained confidence value. The Book's failure case supplies the warrant: a record that resolved a contradiction silently would be a second failure wearing the first one's repair. A bare confidence score standing where a conflict used to be deletes exactly the information a later reviewer needs. Because the clause binds, the conflict stays inspectable in the record; a reader can weigh the limitation, hear the dissent, and see the disagreement whole, and a smoothed-over record fails the clause, the comparison that exposes it supplied by the Book's evidence-preservation duties.

PROV-R009

PROV-R009: A consequential implementation artifact SHALL identify its source inputs, dependency set, build or transformation process, producer, content digest, and applicable vulnerability status.

The clause requires a consequential implementation artifact to identify its source inputs, dependency set, build or transformation process, producer, content digest, and applicable vulnerability status. The Book's loophole case describes a transformation hidden between source and use. These six identifications make omissions from the required account checkable; they do not by themselves establish complete lineage.

PROV-R010

PROV-R010: A software bill of materials, model lineage record, or dataset lineage record SHALL identify its coverage and limitations. An absent or partial inventory SHALL NOT be represented as complete.

Inventories flatter themselves toward completeness, and this clause forbids the flattery. A software bill of materials, a model lineage record, or a dataset lineage record identifies its own coverage and its limitations, and an inventory that is absent or partial is never represented as complete. The Book opens with the principle in its keeper's voice: the gaps left standing as gaps. A dependency list believed complete when it is partial is worse than an admitted gap, because it ends the search exactly where the unlisted risk lives. Under the clause, the coverage claim itself becomes checkable evidence: a reader can ask what the inventory admits it does not cover, and an absent or partial inventory represented as complete fails the clause.

PROV-R011

PROV-R011: Dependency and build records SHALL preserve exact versions or explicit unresolved status. Reproducibility claims SHALL include the environment and evidence needed to repeat the claim.

Exactness is what lets a build be checked twice. Dependency and build records preserve exact versions or an explicit unresolved status, whichever the record truthfully carries; and a reproducibility claim carries the environment and evidence needed to repeat the claim. The clause makes unresolved versions explicit and requires reproducibility claims to include the environment and evidence needed to repeat them. A reader can check whether the record preserves exact versions or explicit unresolved status and whether a reproducibility claim includes the required environment and evidence.

PROV-R012

PROV-R012: Promotion evidence SHALL include independent verification of integrity, provenance, applicable authorization, and unresolved risk. A signed release is not self-approving.

No release approves itself. Promotion evidence includes independent verification across four dimensions: integrity, provenance, applicable authorization, and unresolved risk; and the clause states plainly that a signed release is not self-approving. The Book's prohibited case shows the confusion it forecloses, a signature presented as legitimacy, and its verification-state prose insists a verified digest establishes only what its evidence actually covers. A producer who signs their own output has supplied a signature that may establish its covered signing properties, and no independent approval with it. Because the clause binds, a reader can check promotion evidence for independent verification of integrity, provenance, applicable authorization, and unresolved risk; a signed release does not approve itself.

PROV-R013

PROV-R013: Archived material SHALL preserve its digest, format, storage medium, custody events, retention state, and restoration or readability checks. A copy SHALL NOT silently replace the canonical historical record.

Archives outlive their makers; that is their purpose, and this clause equips them for it. Archived material preserves its digest, format, storage medium, custody events, retention state, and restoration or readability checks, and a copy is barred from silently replacing the canonical historical record. Preserving these particulars supports later review of the archive and its history. A reader can check whether the listed information and checks were preserved and whether a copy silently replaced the canonical historical record.

PROV-R014

PROV-R014: A failed restore, unreadable medium, incomplete lineage, vulnerability uncertainty, or conflicting build evidence SHALL block dependent promotion and preserve the failure record, the record carrying its evidence.

Failure, here, is load-bearing. A failed restore, an unreadable medium, an incomplete lineage, a vulnerability uncertainty, or conflicting build evidence has two consequences under this clause: dependent promotion is blocked, and the failure record is preserved, that record carrying its evidence. The Book's failure case sets the pattern, fail closed and keep the conflict, because a failure suppressed today returns as false assurance tomorrow, promoted on evidence that no longer exists. The clause turns each of the five conditions into both a gate and an artefact: promotion cannot proceed past the failure, and a later reviewer inherits not just the fact that something failed but the evidence of how, held inside the failure record itself.

PROV-R050

PROV-R050: A key record SHALL identify its class, namespace, purpose, scope, parent relationship, validity interval, and lifecycle state. Class, namespace, and purpose are separate fields and SHALL NOT be inferred from a key identifier.

Key identifiers tempt inference; a suggestive name invites the reader to guess what the key is for. This clause removes the guesswork twice over. A key record identifies seven things explicitly: its class, namespace, purpose, scope, parent relationship, validity interval, and lifecycle state; and class, namespace, and purpose are separate fields, never inferred from a key identifier. The section it lives in defines records and relationships, and its own preamble forswears four acts: generating keys, establishing custody, performing rotation, and authorizing a signing ceremony, so the clause's whole force is descriptive honesty. Because every field is stated rather than implied, each becomes independently checkable, and an argument that a key's identifier reveals its purpose, class, or namespace collapses against the record's own declarations.

PROV-R051

PROV-R051: A hierarchy relationship SHALL identify the governing relationship, the evidence establishing it, and its effective interval. A parent key, custodian, or technical account SHALL NOT inherit constitutional authority merely by occupying a higher technical layer.

Height in a technical hierarchy confers no constitutional standing. A hierarchy relationship identifies three things: the governing relationship itself, the evidence establishing it, and its effective interval; and a parent key, custodian, or technical account never inherits constitutional authority merely by occupying a higher technical layer. The clause repeats at the level of key structure what PROV-R147, PROV-R053, and the Book's cryptographic baseline hold together: possession and position are capabilities, not authority. Without it, whoever controlled the root of a hierarchy could claim everything beneath it by architecture alone. With it, every claimed relationship shows its evidence and its time bounds, and a claim of authority resting only on layer position is refusable by pointing at the clause.

PROV-R052

PROV-R052: A rotation record SHALL link the retiring and replacement records, preserve their historical validity intervals, identify the reason and approving authority, and state whether continuity evidence is verified, incomplete, conflicting, or unavailable.

Rotation replaces a key without replacing history, and this clause makes the seam inspectable. A rotation record links the retiring and replacement records, preserves their historical validity intervals, identifies the reason and the approving authority, and states whether continuity evidence is verified, incomplete, conflicting, or unavailable. The failure it prevents sits nearby in the same section: an unexplained key substitution is exactly the condition PROV-R055 turns into a blocking, non-authoritative state. The record makes its links, historical validity intervals, reason, approving authority, and stated continuity-evidence condition inspectable, including when that evidence is incomplete, conflicting, or unavailable.

PROV-R053

PROV-R053: Custody evidence SHALL identify the responsible custodian, access classification, custody interval, transfer or backup event, and verification limitations. Custody is evidence of control, not proof of identity, consent, or ratification.

Holding a thing is evidence of control, and proof of neither identity, nor consent, nor ratification. Custody evidence identifies the responsible custodian, the access classification, the custody interval, the transfer or backup event, and the verification limitations; and the clause states the boundary outright: custody is evidence of control, not proof of identity, consent, or ratification. The Book's prohibited case shows why the boundary needs writing down: a digest manifest presented as a ratification is a holding dressed up as an act of authority. Under the clause, the custody trail becomes checkable in every dimension the record names, including what the custody evidence admits it could not verify, while any argument that runs from held it to was them, agreed to it, or ratified it is refusable on the clause's own words.

PROV-R054

PROV-R054: Historical attribution SHALL resolve a signature or assertion against the key, namespace, purpose, and validity state applicable at the event time. Later rotation, retirement, or revocation SHALL NOT rewrite historical attribution.

Attribution belongs to the moment of the event. Historical attribution resolves a signature or assertion against the key, the namespace, the purpose, and the validity state applicable at the event time, and later rotation, retirement, or revocation never rewrites it. The clause protects the past from the present: without it, retiring a key could quietly unsign everything the key validly signed, or a revocation could reach backward and erase an event that truly happened. Because the clause binds, every historical claim has a fixed frame of evaluation, the state of the world at event time, and both directions of tampering fail: a stale key cannot borrow current validity, and a current action cannot un-happen an attributed past.

PROV-R055

PROV-R055: A namespace collision, ambiguous parent relationship, overlapping validity interval, missing continuity evidence, or unexplained key substitution SHALL produce an attributable non-authoritative state and block dependent promotion or use.

Ambiguity in a key hierarchy fails closed. Five conditions trigger this clause: a namespace collision, an ambiguous parent relationship, an overlapping validity interval, missing continuity evidence, or an unexplained key substitution; each produces an attributable non-authoritative state and blocks dependent promotion or use. The block guards against dependent reliance on one of these hierarchy defects. The clause makes the required response checkable: each listed condition calls for an attributable non-authoritative state and a block on dependent promotion or use.

PROV-R056

PROV-R056: A revocation record SHALL identify the affected credential or signature set, effective time, reason class, approving authority, evidence state, and relationship to the prior lifecycle record.

Revocation is itself a claim, and it carries a record like any other. A revocation record identifies the affected credential or signature set, the effective time, the reason class, the approving authority, the evidence state, and the relationship to the prior lifecycle record. The section defines an evidence contract only, operating no revocation service and authorizing no credential action, so the clause's work is to make every revocation evaluable. An unscoped revocation cannot be applied; an unauthorized one is a lever anyone could pull; one severed from the prior lifecycle record floats free of the history it amends. With all six fields required, a reader can inspect the affected credential or signature set, effective time, reason class, approving authority, evidence state, and relationship to the prior lifecycle record.

PROV-R057

PROV-R057: A compromise record SHALL preserve the detection trigger, affected scope, containment action, replay or misuse assessment, protected evidence reference, and recovery or escalation reference.

When something is compromised, the incident's own trail becomes evidence to keep. A compromise record preserves six things: the detection trigger, the affected scope, the containment action, the replay or misuse assessment, the protected evidence reference, and the recovery or escalation reference. The clause protects later review from losing the detection, scope, containment, assessment, and reference information it requires the record to preserve. Its references work the way the Book's privacy posture requires, pointing to protected evidence and to recovery or escalation paths without spilling their contents. Because the six elements are required to be preserved, a later reviewer can check whether the compromise record contains each of them.

PROV-R058

PROV-R058: Revocation applicability SHALL be evaluated against event time, namespace, purpose, scope, and the credential state then in force. A later revocation SHALL NOT erase a historically attributable event.

Whether a revocation reaches a given event is answered at the event's own moment: the clause requires revocation applicability to be evaluated against event time, namespace, purpose, scope, and the credential state then in force, and it bars a later revocation from erasing a historically attributable event. Without this rule, revoking a key today would quietly unwrite everything the key validly did yesterday, corrupting the historical record that provenance exists to protect. Because the evaluation is fixed to the event's own coordinates, an auditor can rely on attribution staying stable: what stands as a historically attributable event remains its act, in its namespace, purpose, and scope, however the credential later fell.

PROV-R059

PROV-R059: Unknown, conflicting, stale, or unavailable revocation evidence SHALL block dependent reserved-power use and remain distinguishable from confirmed revocation and from absence of revocation.

Uncertainty about revocation is its own state, and the clause refuses to let it masquerade as either answer. Revocation evidence that is unknown, conflicting, stale, or unavailable blocks any dependent reserved-power use, and it stays distinguishable both from confirmed revocation and from the absence of revocation. The danger foreclosed is the quiet collapse of three conditions into two: treating an evidentiary gap as proof the credential still stands, or as proof it has fallen, either of which lets a reserved power fire on evidence nobody holds. Because the uncertain state is explicit and blocking, dependent reserved-power use fails closed until real evidence arrives, and a reader can tell exactly which of the three conditions the record asserts.

PROV-R060

PROV-R060: Containment SHALL be recorded as a reversible protective disposition where practicable. Containment evidence SHALL NOT be treated as proof of compromise, identity transfer, or constitutional authority.

Containment is protection, not verdict. The clause requires containment to be recorded as a reversible protective disposition where practicable, and it bars treating containment evidence as proof of compromise, of identity transfer, or of constitutional authority. The failure it prevents runs in both directions: an emergency lockdown that hardens into a permanent, unreviewable state, and the opposite deception, where the mere fact that something was contained is offered as proof that compromise occurred, that identity moved, or that authority changed hands. By keeping the disposition reversible where circumstances allow and not itself proving any of the three conclusions, the clause lets a containment stand recorded as what it is, a protective disposition that is not proof of the three named conclusions, and later reviewers inherit an undamaged question.

PROV-R061

PROV-R061: A recovery reference SHALL identify the preserved evidence and decision boundary without authorizing restoration, substitution, or reactivation. Compromise and revocation records SHALL remain supersedable and auditable.

The way back is pointed at without being walked. A recovery reference identifies the preserved evidence and the decision boundary, and the clause withholds from that reference any power to authorize restoration, substitution, or reactivation; separately, compromise and revocation records must remain supersedable and auditable. This stops a pointer from becoming a permission: naming where the evidence sits and where the decision lies is not the decision itself, so no credential slips back into service on the strength of its own incident paperwork. At the same time, because the records stay open to supersession and audit, an error in the incident account can be corrected on the record, and later reviewers can trace both the failure and its handling.

PROV-R062

PROV-R062: An archival record SHALL identify the artifact scope, format, medium class, digest, custody interval, retention state, legal-hold state, restoration evidence, readability evidence, and limitations, applying the archival record the Book of Memory models, with medium class and custody interval this Book's own fields.

An archival record, under this clause, names ten things: the artifact scope, format, medium class, digest, custody interval, retention state, legal-hold state, restoration evidence, readability evidence, and limitations. The record shape it applies is the one the Book of Memory models, and that modelling duty stands at its source; medium class and custody interval are the two fields this Book adds as its own. Missing information about the medium, custody, or readability can hinder review of the archive's preservation. With every field named, a reader can inspect each recorded state and its evidence, artifact scope to limitations, and see where the record itself admits a gap.

PROV-R063

PROV-R063: A readability or restoration result SHALL distinguish complete, partial, unreadable, altered, unavailable, and not-applicable outcomes, with missing material and limitations preserved.

The clause requires a readability or restoration result to distinguish complete, partial, unreadable, altered, unavailable, and not-applicable outcomes, with missing material and limitations preserved. This prevents a result from hiding those distinctions behind an undifferentiated success claim. A reader can check the distinctions and the preservation of missing material and limitations.

PROV-R064

PROV-R064: Format migration SHALL preserve the source digest, target digest, transformation description, responsible actor, effective time, verification evidence, and supersession relationship. A migrated copy SHALL NOT silently replace the historical source.

Moving an archive to a new format is a transformation, and the clause treats it as one that must leave a full trail: the source digest, the target digest, the transformation description, the responsible actor, the effective time, the verification evidence, and the supersession relationship are all preserved, and the migrated copy is barred from silently replacing the historical source. This guards against a migration obscuring the source and the recorded account of its transformation. The clause makes the seven preservation requirements checkable and makes silent replacement of the historical source a violation.

PROV-R065

PROV-R065: Custody transfer, replication, and restoration SHALL remain separate events. A successful technical copy establishes continuity evidence only for the properties actually tested.

Three operations that move archival material, custody transfer, replication, and restoration, must remain separate events under this clause, and a successful technical copy establishes continuity evidence only for the properties actually tested. The confusion it prevents is real: a replica made for redundancy is not a change of custodian, and neither is proof that the archive can be restored into use; collapsing them lets one routine copy stand in for evidence of all three. The second limb caps what success can claim, so a copy whose digest matched proves sameness of content and nothing about readability, completeness, or custody it never exercised. Readers of a continuity claim can therefore ask exactly which event occurred and which properties its evidence covered.

PROV-R066

PROV-R066: Digest mismatch, unreadable media, incomplete restoration, format drift, unavailable custody, conflicting copies, unresolved legal hold, or retention conflict SHALL produce a non-authoritative failure state and block dependent promotion, deletion, or retention change.

Eight archival failures are enumerated here: digest mismatch, unreadable media, incomplete restoration, format drift, unavailable custody, conflicting copies, unresolved legal hold, and retention conflict; each produces a non-authoritative failure state and blocks dependent promotion, deletion, or retention change. The clause prevents dependent promotion, deletion, or retention change from proceeding on any of the eight named conditions. By naming the failure conditions and wiring them to a state that refuses the dependent action, the clause makes fail-closed behaviour checkable, the preservation of the failed evidence itself standing at PROV-R067's own source: no dependent promotion, deletion, or retention change proceeds over a standing failure.

PROV-R067

PROV-R067: Archival validation SHALL preserve the original record, failed or partial evidence, legal-hold and retention limitations, and a bounded review disposition. It SHALL NOT create authority or erase historical attribution.

Validation of an archive is itself an event with duties. The clause requires archival validation to preserve the original record, any failed or partial evidence, the legal-hold and retention limitations, and a bounded review disposition, and it bars validation from creating authority or erasing historical attribution. Two temptations are foreclosed at once: cleaning up, where a validation pass discards the awkward partial results and leaves only the tidy outcome, and inflation, where a successful check is presented as approval of the artifact or as grounds to reassign its history. Because the disposition is bounded and the underlying evidence survives, a later reviewer can reopen the question with the preserved categories in hand, and a validated archive gains no authority and erases no historical attribution.

PROV-R068

PROV-R068: A time record SHALL identify the event class, asserted time, source, method, uncertainty, applicable namespace, and evidence state. Creation, effective, revocation, and supersession time are distinct values.

Where a time record is kept, the clause demands substance behind it: the event class, the asserted time, the source, the method, the uncertainty, the applicable namespace, and the evidence state, with creation, effective, revocation, and supersession time held as distinct values. A bare timestamp answers none of the questions that matter, who measured it, how, with what confidence, and for which kind of event; and collapsing the four time kinds into one lets a document's effective moment quietly borrow its creation date. By making each element explicit, the clause turns a time claim into something a verifier can weigh rather than accept: the uncertainty is stated, the source can be examined, and each of the four temporal questions receives its own answer.

PROV-R069

PROV-R069: A time source SHALL be evaluated for applicability, integrity, independence, coverage, and known limitations. A precise time value with unresolved source or applicability SHALL remain non-authoritative.

Precision is not provenance. A time source must be evaluated for applicability, integrity, independence, coverage, and known limitations, and a precise time value whose source or applicability remains unresolved stays non-authoritative under this clause. The seduction it guards against is the confident number: a timestamp carried to the millisecond looks like evidence even when nobody can say where it came from or whether it applies to the event at hand, and precision then buys a trust that was never earned. A reader can check whether the five dimensions were evaluated and whether a precise time value with unresolved source or applicability remains non-authoritative.

PROV-R070

PROV-R070: Conflicting, stale, replayed, unavailable, or out-of-range time evidence SHALL remain explicit and SHALL block dependent promotion or lifecycle decisions where event ordering is material.

When the order of events decides the outcome, doubtful time cannot be waved through. Time evidence that is conflicting, stale, replayed, unavailable, or out of range must remain explicit under this clause, and it blocks dependent promotion or lifecycle decisions where event ordering is material. The qualifier does real work: not every decision hangs on sequence, but where one does, whether a signature preceded a revocation, whether a supersession landed before a promotion, degraded time evidence is exactly the evidence an attacker or an accident would supply. Keeping the defect explicit stops it from being tidied into a plausible value, and the block ensures that ordering-sensitive decisions wait for time evidence that can actually carry them.

PROV-R071

PROV-R071: An inferred time SHALL be labelled as inferred and SHALL NOT be represented as an observed or independently attested time. Missing time SHALL be Unavailable, not silently defaulted.

Honesty about how a time was obtained is the whole of this clause. A time arrived at by inference must be labelled as inferred and can never be represented as an observed or independently attested time, and a missing time is recorded as Unavailable rather than silently defaulted. An unlabelled estimate or a silently defaulted time can be mistaken for an observed value, obscuring the distinction the clause requires. Because the label travels with the value and absence stays visible as absence, a reader weighing a time claim knows which kind of claim it is, and the record's gaps remain the record's honest gaps.

PROV-R072

PROV-R072: Time evidence SHALL preserve the relationship between event time and credential, signature, revocation, custody, and supersession state without rewriting historical attribution.

History in this Book is a join between when and what. Time evidence must preserve the relationship between an event's time and the credential, signature, revocation, custody, and supersession state that held at that time, without rewriting historical attribution. The clause exists because most provenance questions are really questions of intersection: whether the key was valid when the signature was made, whether custody had transferred when the change landed, whether a supersession preceded the use. Sever time from state and each question becomes answerable only by reconstruction or guesswork; let later events rewrite the join and the answers change retroactively. By fixing the intersection in the evidence itself, the clause keeps the relationships visible for whoever must later evaluate them.

PROV-R073

PROV-R073: A time-source limitation or conflict SHALL be recorded with its affected events, bounded disposition, and review reference. No time result SHALL create authority, consent, identity, or ratification.

Trouble with a time source is recorded, not absorbed. A time-source limitation or conflict must be captured with its affected events, a bounded disposition, and a review reference, and no time result, however clean, creates authority, consent, identity, or ratification. This guards against losing the account of which events a time-source defect affects or treating a time result as authority. The first limb makes the affected events, bounded disposition, and review reference checkable in the record. The second bars any time result from creating authority, consent, identity, or ratification.

PROV-R074

PROV-R074: A transparency record SHALL identify the log namespace, entry digest, append context, inclusion evidence, retention state, legal-hold state, and protected-evidence limitations.

Entries in the transparency log carry their own account. A transparency record identifies the log namespace, the entry digest, the append context, the inclusion evidence, the retention state, the legal-hold state, and the protected-evidence limitations. The required identifications guard against an account that leaves its log context, evidence, or limitations unspecified. Because all seven are required, a reader can check whether the transparency record identifies each listed element.

PROV-R075

PROV-R075: Inclusion and consistency proofs SHALL be evaluated separately. A proof SHALL establish only the entry and log properties it covers and SHALL NOT authenticate authority or truth beyond those properties.

Two different questions hide inside a transparency proof, and the clause keeps them apart: an inclusion proof and a consistency proof, each establishing only the entry and log properties its evidence covers, are evaluated separately, and each establishes only the entry and log properties it actually covers, never authenticating authority or truth beyond them. Conflating the two lets one proof answer the other's question, an included entry offered as evidence the log is honest, or a consistent log offered as evidence a particular entry exists. The outer cap addresses the larger inflation: a proof about log mechanics is not a proof that the logged claim is true or authorized, so log mathematics can never be spent as legitimacy.

PROV-R076

PROV-R076: Omission, equivocation, deletion, rollback, fork, or inconsistent-view evidence SHALL remain attributable and SHALL block dependent promotion or dependent use.

Misbehaviour by the log itself is the failure this clause anticipates. Evidence of omission, equivocation, deletion, rollback, fork, or an inconsistent view must remain attributable, and it blocks dependent promotion or dependent use. These are the six adverse conditions the clause names; it does not define them. A transparency log that can misbehave unrecorded is worse than no log, because it lends the appearance of audit to whatever survived the tampering. By requiring the evidence to stay attributable and the dependent decisions to fail closed, the clause holds the log accountable to the same discipline it enforces on everything else.

PROV-R077

PROV-R077: Log retention and correction SHALL preserve prior entries, supersession relationships, failure records and their evidence, and legal-hold limitations. An unresolved legal hold or retention conflict SHALL block deletion or retention change. A correction SHALL NOT silently rewrite the historical log.

Under this clause a correction leaves the prior entries preserved and the history visibly superseded, never silently rewritten. Log retention and correction preserve prior entries, supersession relationships, failure records with their evidence, and legal-hold limitations; an unresolved legal hold or retention conflict blocks any deletion or retention change; and a correction is barred from silently rewriting the historical log. The clause exists because the correction path is the tampering path wearing better clothes: whoever may fix the log may falsify it, unless fixing is constrained to leave the erroneous entry standing beneath its supersessor. The legal-hold limb adds the external duty: while a hold or retention conflict stands unresolved, nothing is removed and no retention term shifts. What results is a log whose history includes its own mistakes, visibly repaired.

PROV-R078

PROV-R078: Public transparency proofs SHALL disclose the minimum digest, namespace, proof, status, and limitation material needed for independent review without exposing protected evidence or personal details, this Book's transparency-surface bar under the estate home PROV-R109, the namespace and proof elements and the personal-details negation its own beside that home's.

Publication of a transparency proof, when it happens, is a minimization exercise. The clause requires a public transparency proof to disclose the minimum digest, namespace, proof, status, and limitation material needed for independent review, while exposing neither protected evidence nor personal details. It stands as this Book's transparency-surface bar under the estate home at PROV-R109, where the shared minimum-disclosure duty lives; the namespace and proof elements, and the negation covering personal details, are this clause's own contributions beside that home's. The failure it prevents is disclosure creep, a proof that drags protected material or personal information onto a public surface because publishing more felt more convincing. An independent reviewer keeps the named minimum available to them, while protected evidence and personal identity details stay undisclosed.

PROV-R079

PROV-R079: A log result SHALL NOT establish signer identity, constitutional applicability, consent, or ratification without separate evidence. Unknown, unavailable, conflicting, or stale log evidence remains non-authoritative.

What a log proof establishes stays within the entry and log properties its evidence covers. A log result cannot establish signer identity, constitutional applicability, consent, or ratification without separate evidence, and log evidence that is unknown, unavailable, conflicting, or stale remains non-authoritative. The inflation this blocks is subtle because logs feel official: an entry duly appended and provably included acquires an aura of endorsement, and the aura is exactly what an impersonator or a premature claim would exploit. Presence in the log establishes the log properties the proof covers; signer identity, constitutional applicability, consent, and ratification are the four inferences the clause bars without separate evidence. The second limb holds degraded log evidence at non-authoritative, below what sound log evidence establishes for the log properties it covers.

PROV-R140

PROV-R140: The log this architecture defines is internal. Its entries, inclusion evidence, and ordering are held as protected evidence under controlled access, within this Book's verification states and retention duties. Nothing in this section requires a transparency proof to be published; PROV-R078 governs what a published proof minimizes, never whether one is published, that bar standing on the transparency surface under the estate home PROV-R109.

Internal is the log's whole posture, and this clause fixes it. The log the architecture defines is not a public service: its entries, inclusion evidence, and ordering are held as protected evidence under controlled access, inside this Book's verification states and retention duties. The clause then severs an easy misreading: nothing in the section requires a transparency proof to be published, because PROV-R078 governs only what a published proof minimizes, never whether one is published, that bar standing on the transparency surface under the estate home at PROV-R109. Without this separation, the existence of a minimization rule could be read as a publication mandate. The boundary is therefore reliable: the log serves internal accountability, and publishing any proof of it remains a decision this section never compels.

PROV-R141

PROV-R141: Temporal ordering drawn from the log is Integrity-only evidence. Ordering SHALL NOT be claimed as independently provable, no external time-stamping authority or anchoring is introduced, and a clause or record that consumes ordering evidence SHALL label its confidence accordingly.

Order, in this log, is honest about its ceiling. Temporal ordering drawn from the log is Integrity-only evidence: the clause bars claiming that ordering as independently provable, introduces no external time-stamping authority or anchoring, and requires any clause or record consuming ordering evidence to label its confidence accordingly. The overstatement it forecloses is presenting temporal ordering drawn from this log as independently provable. Naming the state Integrity-only ties the ceiling to this Book's verification vocabulary, and the labelling duty pushes the honesty downstream, so every record built on log order carries the same measured confidence rather than a quietly inflated one.

PROV-R086

PROV-R086: An artifact attestation SHALL identify the artifact class, exact content digest, source inputs, transformation or build process, producer, claimed properties, coverage, and limitations.

Attestation begins with saying exactly what is attested. An artifact attestation identifies the artifact class, the exact content digest, the source inputs, the transformation or build process, the producer, the claimed properties, the coverage, and the limitations. These eight required identifications make the attestation's stated content, properties, coverage, and limitations inspectable. An attestation missing any of these drifts toward a vague endorsement that later readers will stretch. Because the fields are written into the record, a verifier can see the claim as made, the no-wider boundary binding at PROV-R087's own source.

PROV-R087

PROV-R087: An attestation SHALL bind only the content and properties explicitly covered by its evidence. A valid attestation SHALL NOT imply complete lineage, secure construction, licensing, safety, or approval beyond its stated scope.

The Book's loophole case describes a chain of individually valid attestations assembled so that the final claim exceeds what any single link covers; this clause forecloses that assembly at every link. It confines an attestation to the content and properties its evidence explicitly covers, and it bars a valid attestation from implying complete lineage, secure construction, licensing, safety, or approval beyond its stated scope. Validity, in other words, covers the tested claim and reaches nothing adjacent to it. Because each attestation carries a hard edge, a reader can compose a chain and know the conclusion is worth no more than its narrowest member establishes, and an overreaching claim becomes refusable by comparing it with the attestation's own stated scope.

PROV-R088

PROV-R088: Incomplete source coverage, altered inputs, unresolved transformations, unavailable producer evidence, or digest mismatch SHALL produce an attributable non-authoritative result and block dependent promotion.

Five defects trip this clause: incomplete source coverage, altered inputs, unresolved transformations, unavailable producer evidence, and a digest mismatch. Any of them requires an attributable non-authoritative result, an attributable finding, and blocks the promotion that depends on the attestation. The clause exists because a defect left unrecorded lets dependent promotion inherit a claim its evidence no longer supports. By forcing the failure into a recorded, attributable state and halting dependent promotion, it makes fail-closed behaviour checkable; a promotion that proceeded over any of these defects is provably out of order, and the defect stands attributable rather than silent, the preservation of failure records governed where the Book states it.

PROV-R089

PROV-R089: Attestation issuer identity, signing principal, verification state, and approval authority SHALL remain separate fields. An issuer or signature SHALL NOT self-approve an artifact or create constitutional authority.

The clause separates fields without identifying a distinct actor for each field. This clause holds attestation issuer identity, signing principal, verification state, and approval authority as separate fields, and it bars an issuer or a signature from self-approving an artifact or creating constitutional authority. The Book's prohibited case shows a valid signature presented as constitutional proof; this clause separately bars an issuer or signature from self-approving an artifact or creating constitutional authority. A reader can check whether the four fields are separate and whether an issuer or signature is being used to self-approve the artifact or create constitutional authority.

PROV-R090

PROV-R090: Independent verification SHALL record the tested digest, evidence inputs, covered claims, excluded evidence, limitations, and disposition. Reverification SHALL append rather than overwrite prior results.

Independent verification of an attestation must leave the record this clause specifies. The clause requires the verification record to carry the tested digest, the evidence inputs, the claims actually covered, the evidence excluded, the limitations, and the disposition, so a reader can inspect the stated coverage and exclusions. It further requires reverification to append to prior results rather than overwrite them, keeping the history of findings intact. Without the first duty a verification could quietly pass as broader than its work; without the second a clean rerun could erase an earlier adverse result. A reader can check the required fields and whether reverification appended rather than overwrote prior results.

PROV-R091

PROV-R091: Public attestation proofs SHALL disclose only the minimum digest, claim, verification state, and limitation material needed for independent review and SHALL NOT expose protected inputs or credentials, this Book's attestation-surface bar under the estate home PROV-R109, the claim element its own beside that home's, the protected-inputs negation its own voice of that home's credential bar.

Publication is where an attestation risks leaking what it exists to protect. This clause sets the attestation surface's disclosure bar: a public attestation proof discloses only the minimum digest, claim, verification state, and limitation material an independent reviewer needs, and it exposes no protected inputs and no credentials. The coda places this attestation-surface bar under PROV-R109 and identifies the claim element as this clause's own contribution beside that home's. It also traces the protected-inputs negation as this clause's own voice of the home's credential bar. Minimization and reviewability together let outsiders check the proof without the proof becoming a second exposure.

PROV-R104

PROV-R104: A model-weight or dataset record SHALL identify the artifact class, exact digest, source inputs, transformations, version, producer, licensing status, intended scope, and known limitations.

A model-weight or dataset record earns its trust from its completeness being testable, so the clause fixes the record's minimum shape. A model-weight or dataset record identifies nine things: the artifact class, the exact digest, the source inputs, the transformations, the version, the producer, the licensing status, the intended scope, and the known limitations. Together these make the nine required identifications inspectable. A record missing one of these fields fails the clause, which makes incompleteness itself detectable rather than discoverable only after misuse.

PROV-R105

PROV-R105: Lineage SHALL distinguish direct inputs, derived outputs, filtering, labelling, fine-tuning, conversion, and aggregation. An unrecorded transformation SHALL remain an explicit provenance gap.

Between a source and the artifact in hand sit operations that change what the data is, and this clause refuses to let them blur. Lineage must distinguish direct inputs, derived outputs, filtering, labelling, fine-tuning, conversion, and aggregation as different relationships, because a filtered dataset, a fine-tuned model, and an aggregate stand in different relations to their sources, and the clause separately requires an unrecorded transformation to remain an explicit provenance gap. Where a transformation went unrecorded, the clause requires the omission to stand as an explicit provenance gap rather than be smoothed over; the Book opens with the warning that a line that fills its own silences has stopped being a record and become a wish. The named categories make the chain queryable, and the mandatory gap makes silence itself visible evidence.

PROV-R106

PROV-R106: Integrity, provenance, licensing, safety, applicability, and verification state SHALL remain separate dimensions. A valid digest SHALL NOT establish lawful use, safe behaviour, or complete lineage.

A matching digest is the easiest fact to establish about a model or dataset, and the most tempting to overread. This clause holds integrity, provenance, licensing, safety, applicability, and verification state as separate dimensions of the record, and it bars a valid digest from establishing lawful use, safe behaviour, or complete lineage. The Book's misuse case names the deception it forecloses: an artifact described as approved because its provenance verified, when a verified trail proves the trail, and nothing at its end. Because the dimensions cannot substitute for one another, a reader can refuse any conclusion that borrows a digest's certainty for a question the digest never touched.

PROV-R107

PROV-R107: Missing source evidence, altered inputs, unresolved licensing, incomplete lineage, conflicting records, or unavailable custody SHALL block dependent promotion or consequential use and preserve the limitation.

Missing source evidence, altered inputs, unresolved licensing, incomplete lineage, conflicting records, and unavailable custody: any one of these six defects blocks the promotion or consequential use that depends on a model-weight or dataset record, and the clause requires the limitation itself to be preserved rather than discarded once the block is felt. This guards against reliance on a defective provenance claim and against losing the limitation that explains the block. The clause makes two requirements checkable for each named defect: blocking dependent promotion or consequential use, and preserving the limitation.

PROV-R108

PROV-R108: A model-weight or dataset verification report SHALL identify tested claims, excluded evidence, reviewer role, evidence state, limitations, and disposition. Reverification SHALL append rather than overwrite prior findings.

Reports of model-weight or dataset verification must show their own edges. Each report identifies tested claims, excluded evidence, reviewer role, evidence state, limitations, and disposition, making its stated basis available for review. Reverification appends to prior findings rather than overwriting them, so no earlier result, an adverse one included, is overwritten out of the account. These duties guard against overstating reported coverage or concealing prior findings; a reader can check the required identifications and whether reverification appended rather than overwrote prior findings.

PROV-R109

PROV-R109: Public proofs SHALL disclose the minimum digest, lineage summary, licensing limitation, verification state, and uncertainty needed for independent review without exposing protected data or credentials.

Outside readers need enough to check a public claim; protected data and credentials are what the clause holds back. This clause sets that balance for public proofs: they disclose the minimum digest, lineage summary, licensing limitation, verification state, and uncertainty needed for independent review, and they expose no protected data and no credentials. The Book's care-control case shows the stake, a provenance trail kept no larger than what review needs, and the transparency and privacy section states the same duty in prose. The clause is the estate home for the provenance family's disclosure minimums: within this Book, PROV-R078, PROV-R091, PROV-R115, PROV-R127, and PROV-R140 seat their surface bars under it, and clauses of the Signing and Verification Standards, PROV-R097, PROV-R083, PROV-R103, and PROV-R139 among them, do the same from their own documents. The bound makes overdisclosure a violation, not a misjudged courtesy.

PROV-R110

PROV-R110: A release record SHALL distinguish artifact digest, build evidence, signing evidence, environment, approval, deployment result, and rollback evidence as separate claims.

Seven named claims are kept distinguishable by this clause, the record barred from fusing them: artifact digest, build evidence, signing evidence, environment, approval, deployment result, and rollback evidence each stand as a separate claim in the release record. The separation matters because each element can be true while its neighbour fails; a signed artifact may lack approval, an approved release may not have deployed, a deployment may have no rollback evidence at all. A record that merged them would let the strongest claim vouch for the weakest. Held apart, the seven claims can be examined separately, and a reader can check whether the release record preserves that separation.

PROV-R111

PROV-R111: A signature over a release or deployment artifact SHALL bind the exact digest, namespace, purpose, scope, and validity interval. It SHALL NOT approve an environment or deployment by itself.

Signing a release proves less than it seems to, and this clause fixes both what it proves and what it cannot. A signature over a release or deployment artifact binds the exact digest, the namespace, the purpose, the scope, and the validity interval, so the signed fact is a precise one: this content, in this signing context, for this use, within this window. The clause then bars the signature from approving an environment or a deployment by itself. The Book's prohibited case warns against reading a valid signature as legitimacy; here that warning becomes structure. A claim that the signature by itself approves an environment or deployment is refusable on the clause's face.

PROV-R112

PROV-R112: Promotion evidence SHALL identify independent verification, approving authority, target environment, unresolved risk, and applicable rollback or preservation disposition.

Promotion evidence identifies independent verification, approving authority, target environment, unresolved risk, and the applicable rollback or preservation disposition. The required account guards against a promotion decision overlooking its verification, authority, environment, risk, or rollback or preservation context. These five required elements make omissions checkable during review. A record that omits one fails the clause; the clause does not define an independence test or make identification of an approving authority evidence that approval occurred.

PROV-R113

PROV-R113: Failed builds, altered artifacts, failed verification, unauthorized environment changes, environment drift, namespace mismatch, incomplete approval, or rollback uncertainty SHALL block dependent promotion and preserve the failure record, the record carrying its evidence.

Eight failure modes stop a promotion under this clause: failed builds, altered artifacts, failed verification, unauthorized environment changes, environment drift, namespace mismatch, incomplete approval, and rollback uncertainty. Any of them blocks the dependent promotion and requires the failure record to be preserved, the record carrying its evidence, so the stoppage and its grounds survive together. The Book's failure case explains the temper of the rule: the dependent action fails closed, and the conflict is kept, because a record that resolved a contradiction silently would be a second failure wearing the first one's repair. A reviewer can check both whether dependent promotion was blocked and whether the failure record and its evidence were preserved.

PROV-R114

PROV-R114: Build, release, deployment, and rollback records SHALL preserve supersession and historical attribution without silently replacing the prior release or environment state.

History is what the Book vows will survive the loss of a person, model, platform, or memory, and this clause protects it at the release line. Build, release, deployment, and rollback records preserve their supersession relationships and their historical attribution, and none of them silently replaces the prior release or the prior environment state. A reader can check whether supersession and historical attribution were preserved and whether any replacement of the prior release or environment state was explicit. The value protected is the Book's founding one: a story with enough shape to survive the loss of a person, model, platform, or memory. Because replacement must be explicit, supersession and attribution stay inspectable, and no prior state is silently replaced.

PROV-R115

PROV-R115: Public proofs SHALL disclose the minimum digest, release class, environment claim, approval state, verification state, and limitations needed for independent review without exposing credentials, private keys, protected configuration, or operational endpoints, this Book's release-surface bar under the estate home PROV-R109, the release class, environment claim, and approval state its own beside that home's, the private-keys, protected-configuration, and operational-endpoints negations its own, the credential negation its voice of the home's bar.

Release evidence is publishable only down to a hard floor of secrecy. Under this clause a public proof discloses the minimum digest, release class, environment claim, approval state, verification state, and limitations an independent review needs, and exposes no credentials, no private keys, no protected configuration, and no operational endpoints. The coda places this release-surface bar under PROV-R109. It attributes release class, environment claim, approval state, and the prohibitions on private keys, protected configuration, and operational endpoints to this clause, while tracing the credential prohibition to the home. Reviewers get enough to check the release claim, while credentials, private keys, protected configuration, and operational endpoints stay off the surface.

PROV-R122

PROV-R122: An algorithm transition record SHALL identify the retiring and proposed algorithms, affected namespaces, validity intervals, supported verification paths, threat assumptions, and migration limitations.

Changing a cryptographic algorithm is a change of evidence, not merely of software, and the clause makes the change itself a documented artifact. An algorithm transition record identifies the retiring and proposed algorithms, the affected namespaces, the validity intervals, the supported verification paths, the threat assumptions, and the migration limitations. A reader can check whether the transition record identifies every listed field. The Book's baseline treats algorithms as replaceable credentials rather than constitutional authority, and this record keeps a replacement reviewable: a transition asserted without these fields is checkably incomplete.

PROV-R123

PROV-R123: Dual-verification evidence SHALL identify which historical and current signatures were tested, which were unsupported, and whether each result covers integrity, origin, applicability, or another explicit property.

During a migration two signature regimes coexist, and evidence gathered across them is easy to overstate. Dual-verification evidence under this clause identifies which historical and which current signatures were tested, which were unsupported, and, for each result, whether it covers integrity, origin, applicability, or another explicit property. The duty prevents a familiar inflation: a batch of passes reported as if everything old and new verified, when some signatures were recorded as unsupported and some results proved only sameness of content. A reader can inspect which signatures were tested or unsupported and which property each result covers.

PROV-R124

PROV-R124: Deprecation or unsupported-algorithm evidence SHALL preserve historical attribution and SHALL NOT silently invalidate prior records or signatures.

When an algorithm is deprecated, everything ever signed with it invites a lazy verdict: retroactively worthless. This clause forbids that verdict. Deprecation or unsupported-algorithm evidence preserves historical attribution and does not silently invalidate prior records or signatures; a signature made while its algorithm was accepted remains attributable to the moment and context in which it was made, even after current tooling can no longer verify or recommend the algorithm. The Book holds this line throughout: later lifecycle changes never rewrite what historically happened, and deprecation joins that family. The clause bars only the silent form: a warranted invalidation is governed at its own source, and what this clause guarantees is that historical attribution stands preserved underneath whatever later evidence arrives.

PROV-R125

PROV-R125: An algorithm-agility decision SHALL identify compatibility, rollback, preservation, verification, and unresolved-risk evidence. A cryptographic preference SHALL NOT create authority or require immediate replacement.

The clause requires an algorithm-agility decision to identify compatibility, rollback, preservation, verification, and unresolved-risk evidence. It also bars a cryptographic preference from creating authority or requiring immediate replacement. This guards against a cryptographic preference being used to bypass consideration of the decision's evidence. The required identifications make omissions checkable, and a preference offered as authority or as a demand for immediate replacement is refusable.

PROV-R126

PROV-R126: Conflicting, unavailable, stale, unsupported, or failed migration evidence SHALL block dependent promotion or replacement decisions and preserve the failure record, the record carrying its evidence.

Migration evidence that is conflicting, unavailable, stale, unsupported, or failed triggers this clause's duty to block dependent promotion or replacement decisions. Any of those five states blocks the dependent promotion or replacement decision, and the failure record is preserved, the record carrying its evidence, so what stopped the migration remains inspectable alongside why. The danger addressed is momentum: a migration underway generates its own pressure to treat thin or broken evidence as good enough, and a replacement made on such evidence would proceed despite one of the clause's blocking conditions. Blocking converts the defect into a visible halt rather than a hidden weakness, and preservation means the halt can be audited and revisited, the rule for clearing it standing at its own governing source.

PROV-R127

PROV-R127: Public migration proofs SHALL disclose the minimum algorithm, verification result, historical limitation, and compatibility material needed for independent review without exposing keys or protected implementation details, this Book's migration-surface bar under the estate home PROV-R109, the algorithm, compatibility, and historical-limitation material and the keys and protected-implementation-details negations its own beside that home's.

Where the account of a cryptographic migration is published for outside review, this clause bounds what that account may show. A public migration proof discloses the minimum algorithm, verification result, historical limitation, and compatibility material needed for independent review, and exposes no keys and no protected implementation details. What is native here is the migration matter itself, the algorithm, compatibility, and historical-limitation material and the keys and protected-implementation-details negations; what is inherited, the minimization pattern, a reader verifies once at the estate home PROV-R109 and need not re-derive at this surface. The bar gives an independent reader the disclosed algorithm, verification-result, historical-limitation, and compatibility material to review, without the proof handing an adversary the material of the signing apparatus itself.

---

Where this document sits

• Identifier: PROV-1
• Status: Draft
• Authority: CONAN-P0, ARCH-1
• Approved by: The Architect
• Depends on: CONAN-P0, ARCH-1
• Depended on by: ARCH-2, ARCH-3, KNOW-2, KNOW-4, INTEL-4, INTEL-5, INTEL-14, PROV-2, PROV-3, PROV-4, MEM-1, MEM-3, OPS-10, OPS-11, OPS-15, INFRA-5, INFRA-7, INFRA-8, INFRA-9
• 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.