The Book of Provenance

The trail behind every claim

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 authorised review.
PROV-R146: Provenance evidence SHALL preserve privacy, minimisation, correction, supersession, and restoration information.
PROV-R147: This Draft SHALL NOT create credentials, signatures, live trust infrastructure, or authority through technical possession.

Interpretation cases: Conforming links source and custody evidence; Prohibited treats a digest as authority; Boundary labels unavailable lineage; Failure pauses dependent claims; Loophole hides transformation; Misuse discloses protected provenance; Care-control preserves agency and correction.

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 unavailable.

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 authorisation, 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:

New material begins Unverified unless an existing record supplies a supported state.
A matching digest may produce Integrity-only but cannot produce Verified without authenticated origin evidence.
A failed digest or signature produces Invalid and blocks promotion or use that depends on validity.
A previously valid credential or signature becomes Revoked when its trust record establishes revocation at the applicable time.
Missing, conflicting, stale, or unavailable verification material produces Unknown until resolved by attributable evidence.
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 authorisation, 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 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, and restoration or readability evidence.
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 trust decisions.
PROV-R077: Log retention and correction shall preserve prior entries, supersession relationships, failure 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 verification without exposing protected evidence or personal details.
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.

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.

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, incomplete approval, or rollback uncertainty shall block dependent promotion and preserve the failure record.
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 minimum digest, release class, environment claim, approval state, verification state, and limitations without exposing credentials, private keys, protected configuration, or operational endpoints.

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

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.

Conforming and failure examples

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 authorised. A digest manifest is presented as a ratification or as proof of a live signing ceremony.

Boundary and failure

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. If evidence conflicts or a signature is outside its declared class or namespace, the record remains non-authoritative and the dependent action fails closed.

Required future sections

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;
post-quantum migration.

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.