# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-22T21:06:30Z", "synthesisSha256": "06b28867c21efe1605fa778fa4b58a30a2b17a53e6d54e305d7aa2d968482225", "providerMode": "dual-provider", "providers": [ "Claude", "Grok" ], "waivedProviders": [] }, "metaModel": { "id": "WM-XCT-012", "registryId": "vr.wm-xct-012", "name": "Provenance", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "mixin", "family": "World Models", "category": "Cross-cutting context", "industry": [ "Cross-industry" ], "domain": [ "XCT.PROV" ], "tags": [ "provenance", "xct.prov" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-xct-012-provenance/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-xct-012", "model": { "registry_id": "vr.wm-xct-012", "model_id": "WM-XCT-012", "name": "Provenance", "entry_kind": "mixin", "purpose": "Provide a format-neutral, attachable provenance dimension that lets an agent state, verify and govern where a subject came from, what acted on it, who is responsible, in what custody it has been, and how strongly each of those statements is evidenced.", "scope_statement": "Provenance is modelled as a mix-in applied to a host subject (digital asset, dataset, record, software artifact, physical item, statement or agent output). It covers the origin, derivation graph, responsible agents, activities and plans, custody history, temporal and spatial context, integrity and attestation evidence, verification outcome and confidence, regulatory disclosure, discovery/access, redaction and retention of provenance itself. It does not define the subject's own domain semantics, nor does it re-define agents, rights, retention schedules, access policy or data-quality metrics that belong to composable sibling models; it references them. The model is storage- and interface-neutral: JSON, YAML, Markdown, RDF, JUMBF, Git, MCP and MongoDB are projections of these semantics, not the semantics.", "in_scope": [ "Origination: the activity, agent, instrument, place and time at which the subject first came into being, including capture context and whether the account is first-hand or reconstructed.", "Derivation and lineage: entity-to-entity relations (derivation, revision, quotation, primary source, ingredient, aggregation, transformation) and the traversable ancestor/descendant graph.", "Activities, process steps, plans, algorithms, build definitions and their parameters and resolved dependencies.", "Agents, agent types (person, organisation, software agent, mechanism, device), qualified roles, delegation and on-behalf-of responsibility.", "Chain of custody: successive holders, accession and transfer events, and changes in ownership or control significant to authenticity.", "Time semantics: separation of event/occurrence time from record/observation time, intervals, ordering constraints, invalidation and trusted timestamping.", "Integrity evidence: fixity digests, integrity methods, hard content bindings, soft bindings (watermark/fingerprint), signatures and seals.", "Attestation layer: who asserts the provenance, the signed envelope, trust anchors, credential status, revocation and validation outcome.", "Confidence, completeness, unknown provenance, inferred versus asserted statements, and reconciliation of conflicting provenance claims.", "Regulatory disclosure duties attached to provenance: machine-readable marking of synthetic content, training-data lineage summaries, source-of-personal-data disclosure.", "Discovery of and access to provenance records, provenance-of-provenance bundling, redaction, minimisation and selective disclosure.", "Retention, disposition and deletion of provenance records considered independently of the subject's own retention." ], "out_of_scope": [ "The host subject's substantive content model, schema or domain semantics (supplied by the host model into which this mix-in is composed).", "Rights, licence terms and permissions adjudication; provenance references a rights statement but does not define rights semantics.", "The authoritative registry and resolution of agent, organisation and person identity; provenance references governed agent identifiers.", "Access-control policy definition and enforcement; provenance records that an access decision occurred as evidence, it is not the policy engine.", "Definition of data-quality metrics and thresholds; provenance supplies evidence that quality assessment consumes.", "Retention schedules and disposition authorities as legal instruments; provenance cites the applicable schedule identifier.", "Cryptographic algorithm registries, key management, PKI and trust-list operation; provenance references keys, certificates and trust lists as external artefacts.", "Storage-layer mechanics of versioning systems, object stores, ledgers or content-addressed file layouts; these are projections.", "Business-process semantics of supply-chain steps, clinical workflows or build systems beyond the provenance facts they emit.", "Physical measurement and sensor semantics; provenance records the observation act, not the observable property model." ], "boundary_notes": [ { "neighbor": "Audit log / AuditEvent model", "distinction": "Provenance describes how an entity came to be and who is responsible for it; audit logging describes who accessed or attempted an operation on a system. FHIR draws the same line: Provenance is generation-focused while AuditEvent covers usage and other activity. Read events belong to the audit sibling unless they generated a new entity.", "source_refs": [ "SRC-010", "SRC-001" ] }, { "neighbor": "Version control / revision history model", "distinction": "A revision chain is one derivation relation (prov:wasRevisionOf, dcterms:isVersionOf) among many. Commit graphs, branches and merges are a storage projection; this model captures the derivation and responsibility facts that survive migration off any given VCS.", "source_refs": [ "SRC-001", "SRC-008" ] }, { "neighbor": "Rights and licensing model", "distinction": "dcterms:provenance covers changes in ownership and custody significant to authenticity, integrity and interpretation; it is not the licence. Rights holders and licence documents are referenced as external agents and documents.", "source_refs": [ "SRC-008", "SRC-017" ] }, { "neighbor": "Archival description model (fonds / respect des fonds)", "distinction": "In archival practice 'provenance' primarily denotes the creator and the accumulating body of a fonds; here that sense is carried by origination agent plus custody history, while the transformation graph is modelled separately. The homonym must be disambiguated when mapping to RiC-CM.", "source_refs": [ "SRC-016", "SRC-017" ] }, { "neighbor": "Software bill of materials (SBOM) model", "distinction": "An SBOM enumerates composition at a point in time; provenance states how that composition was produced and by whom. SPDX Element creation information and in-toto/SLSA build predicates are alignments, not the SBOM inventory itself.", "source_refs": [ "SRC-015", "SRC-006", "SRC-007" ] }, { "neighbor": "Supply-chain traceability event model (EPCIS)", "distinction": "EPCIS what/when/where/why events are an authoritative source of physical-object provenance, but the business-step and disposition vocabularies remain in the traceability sibling; this model consumes the events as origination, transfer and transformation facts.", "source_refs": [ "SRC-014" ] }, { "neighbor": "Geospatial lineage metadata", "distinction": "ISO 19115 lineage (statement, process step, source) is a domain projection of the same activity/entity structure; the geospatial resolution, reference system and citation fields stay with the geospatial metadata sibling.", "source_refs": [ "SRC-013" ] }, { "neighbor": "Content authenticity manifest (C2PA)", "distinction": "A C2PA manifest is a signed transport of provenance bound to a media asset. This model treats manifests, claims, assertions and ingredients as artefacts and evidence; JUMBF embedding, codec-specific box hashing and trust-list operation stay outside.", "source_refs": [ "SRC-005" ] }, { "neighbor": "Data quality model", "distinction": "Provenance is evidence for quality judgements (FAIR R1.2 requires detailed provenance) but does not define accuracy, completeness or fitness metrics; a quality assessment is itself an activity with its own provenance.", "source_refs": [ "SRC-018", "SRC-013" ] }, { "neighbor": "Records retention and disposition model", "distinction": "Disposition authorities, schedules and approval flows belong to the records sibling; provenance records the disposition event and retains the evidence that it happened, and may itself be subject to a different retention period than the subject.", "source_refs": [ "SRC-019", "SRC-011" ] } ] }, "sources": [ { "id": "SRC-001", "title": "PROV-DM: The PROV Data Model", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/prov-dm/", "version_or_date": "W3C Recommendation, 30 April 2013", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Defines the core provenance types (Entity, Activity, Agent) and relations (wasGeneratedBy, used, wasInformedBy, wasDerivedFrom, wasAttributedTo, wasAssociatedWith, actedOnBehalfOf, wasInvalidatedBy, specializationOf, alternateOf, hadMember) plus Bundle, Collection, Plan, Role and Location; the structural backbone of this model." }, { "id": "SRC-002", "title": "PROV-O: The PROV Ontology", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/prov-o/", "version_or_date": "W3C Recommendation, 30 April 2013; namespace http://www.w3.org/ns/prov#", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Supplies governed global IRIs for provenance terms including startedAtTime, endedAtTime, generatedAtTime, invalidatedAtTime, atLocation, hadPrimarySource, wasRevisionOf, wasQuotedFrom and the qualified pattern (qualifiedGeneration, qualifiedDerivation, Influence, Role, Plan)." }, { "id": "SRC-003", "title": "Constraints of the PROV Data Model", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/prov-constraints/", "version_or_date": "W3C Recommendation, 30 April 2013", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Defines validity for provenance instances: uniqueness constraints, event-ordering constraints (generation precedes usage), impossibility constraints, normalisation and equivalence; the normative basis for provenance validation functions." }, { "id": "SRC-004", "title": "PROV-AQ: Provenance Access and Query", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/prov-aq/", "version_or_date": "W3C Working Group Note, 30 April 2013", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Describes locating provenance records via HTTP Link headers with the has_provenance relation, anchors, provenance query services and pingback; the interface-neutral discovery pattern. Note status: Working Group Note, not a Recommendation." }, { "id": "SRC-005", "title": "Content Credentials: C2PA Technical Specification", "organization": "Coalition for Content Provenance and Authenticity (C2PA)", "url": "https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html", "version_or_date": "Version 2.4 (current release seen 2026-08-22); version 2.2 dated 2025-05-01", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Normative structure for signed media provenance: manifest store, claim (c2pa.claim.v2) with created_assertions and gathered_assertions, actions and ingredient assertions, hard bindings (data/box hash) versus soft bindings (watermark/fingerprint), claim signature, RFC 3161 time-stamps, redaction, update manifests and validation states." }, { "id": "SRC-006", "title": "SLSA Provenance (predicate type https://slsa.dev/provenance/v1)", "organization": "Open Source Security Foundation (OpenSSF) / SLSA project", "url": "https://slsa.dev/spec/v1.1/provenance", "version_or_date": "SLSA v1.1 provenance predicate page (v1.1 marked retired; v1.2 is the current SLSA release)", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Machine-verifiable build provenance: buildDefinition (buildType, externalParameters, internalParameters, resolvedDependencies) and runDetails (builder id/version, invocationId, startedOn, finishedOn, byproducts), with UTC 'Z' timestamps and globally unique opaque invocation identifiers." }, { "id": "SRC-007", "title": "in-toto Attestation Framework — Statement layer (spec v1)", "organization": "in-toto project (Cloud Native Computing Foundation)", "url": "https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md", "version_or_date": "Statement v1 (_type https://in-toto.io/Statement/v1), main branch as accessed 2026-08-22", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Separates the attested subject (matched purely by digest) from the predicate that carries the provenance claim, and defines ResourceDescriptor (name, uri, digest, content, downloadLocation, mediaType, annotations); the model's subject-anchoring and envelope pattern." }, { "id": "SRC-008", "title": "DCMI Metadata Terms", "organization": "Dublin Core Metadata Initiative (DCMI)", "url": "https://www.dublincore.org/specifications/dublin-core/dcmi-terms/", "version_or_date": "DCMI Recommendation, 2020-01-20", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Defines dcterms:provenance as a statement of changes in ownership and custody significant for authenticity, integrity and interpretation, plus source, created, issued, modified, creator, contributor, publisher, rightsHolder, isVersionOf, replaces and the ProvenanceStatement class." }, { "id": "SRC-009", "title": "RO-Crate 1.1 Specification — Provenance of entities", "organization": "RO-Crate community / Research Object initiative", "url": "https://www.researchobject.org/ro-crate/specification/1.1/provenance.html", "version_or_date": "RO-Crate specification version 1.1", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Shows provenance expressed with schema.org CreateAction/UpdateAction linking agent, instrument (software/equipment), object and result, with actionStatus and guidance to retain prior versions rather than overwrite; a lightweight projection of the same semantics." }, { "id": "SRC-010", "title": "FHIR Provenance resource (Release 5)", "organization": "Health Level Seven International (HL7)", "url": "https://www.hl7.org/fhir/provenance.html", "version_or_date": "FHIR R5 (v5.0.0)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Normative separation of occurred[x] (when the activity happened) from recorded (when it was documented), plus target, policy, location, authorization, agent (type, role, who, onBehalfOf), entity roles (derivation, revision, quotation, source, instantiates, removal) and signature; also the Provenance/AuditEvent boundary." }, { "id": "SRC-011", "title": "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (AI Act)", "organization": "European Union (European Parliament and Council)", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202401689", "version_or_date": "Official Journal, 12 July 2024", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Imposes provenance-bearing duties: automatic event recording (logs) over the lifetime of high-risk systems (Art. 12), retention of automatically generated logs (Art. 19), machine-readable marking and detectability of AI-generated or manipulated content and deepfake disclosure (Art. 50), and a sufficiently detailed summary of training content for general-purpose models (Art. 53(1)(d))." }, { "id": "SRC-012", "title": "Regulation (EU) 2016/679 (General Data Protection Regulation)", "organization": "European Union (European Parliament and Council)", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679", "version_or_date": "Official Journal L 119, 4 May 2016", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Creates enforceable source-provenance duties for personal data: Art. 14(2)(f) source of the personal data, Art. 15(1)(g) any available information as to the source, Art. 19 communication of rectification or erasure to each recipient, Art. 30 records of processing activities, Art. 5(1)(e) storage limitation and Art. 5(2) accountability." }, { "id": "SRC-013", "title": "Metadata for Resource Lineage (MRL) XML schema, ISO 19115-3", "organization": "ISO/TC 211 Geographic information/Geomatics", "url": "https://schemas.isotc211.org/19115/-3/mrl/2.0/", "version_or_date": "MRL 2.0 (namespace https://schemas.isotc211.org/19115/-3/mrl/2.0); registry status: historical", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Normative XML encoding of ISO 19115-1/-2 lineage: LI_Lineage (statement, scope, processStep, source), LI/LE_ProcessStep (description, rationale, stepDateTime, processor, source, output, processingInformation, report), LI/LE_Source, LE_Processing and LE_Algorithm." }, { "id": "SRC-014", "title": "EPCIS and CBV Standard", "organization": "GS1", "url": "https://ref.gs1.org/standards/epcis/", "version_or_date": "EPCIS 2.0, ratified June 2022", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Event model for physical and digital object provenance across organisations: what/when/where/why dimensions, ObjectEvent, AggregationEvent, TransactionEvent, TransformationEvent and AssociationEvent, and the explicit separation of eventTime (UTC), eventTimeZoneOffset and recordTime (when an EPCIS repository recorded it)." }, { "id": "SRC-015", "title": "SPDX 3.0.1 Specification — Core model, Element class", "organization": "SPDX project (The Linux Foundation)", "url": "https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Classes/Element/", "version_or_date": "SPDX 3.0.1", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Demonstrates provenance as a base-class mix-in: every Element carries a required spdxId and creationInfo, plus optional externalIdentifier, externalRef and verifiedUsing (IntegrityMethod/Hash) — evidence that provenance attaches uniformly rather than as a separate document type." }, { "id": "SRC-016", "title": "Records in Contexts — Conceptual Model (RiC-CM) 1.0", "organization": "International Council on Archives (ICA), Expert Group on Archival Description", "url": "https://www.ica.org/app/uploads/2023/12/RiC-CM-1.0.pdf", "version_or_date": "Version 1.0, released November 2023", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Archival conceptual model relating record resources to the agents that created, used or are documented in them and to the activities, mandates and rules that contextualise them; the authority for the creator/custody sense of provenance and for treating relations as first-class." }, { "id": "SRC-017", "title": "PREMIS Data Dictionary for Preservation Metadata, Version 3.0", "organization": "PREMIS Editorial Committee / Library of Congress", "url": "https://www.loc.gov/standards/premis/v3/premis-3-0-final.pdf", "version_or_date": "Version 3.0, June 2015", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Preservation-grade provenance: the Intellectual Entity / Object / Event / Agent / Rights data model, object granularity (representation, file, bitstream), fixity via message digest, and events linked to agents and objects with roles. Direct document retrieval was refused by the host (HTTP 403); version, date and the five-entity model were confirmed from the Library of Congress PREMIS v3 index pages." }, { "id": "SRC-018", "title": "FAIR Principles (Findable, Accessible, Interoperable, Reusable)", "organization": "GO FAIR International Support and Coordination Office", "url": "https://www.go-fair.org/fair-principles/", "version_or_date": "Canonical statement of the principles published in Wilkinson et al., Scientific Data, 2016", "source_type": "scientific", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Principle R1.2 requires that (meta)data are associated with detailed provenance, and I3 requires qualified references to other (meta)data; establishes that provenance is a required reuse condition rather than an optional annotation." }, { "id": "SRC-019", "title": "Universal Electronic Records Management (ERM) Requirements", "organization": "U.S. National Archives and Records Administration (NARA)", "url": "https://www.archives.gov/records-mgmt/policy/universalermrequirements", "version_or_date": "Version 3, June 2023", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T00:00:00Z", "relevance": "Baseline functional requirements across capture, maintenance and use, disposal, transfer, metadata and reporting, distinguishing Must Have from Should Have; the authority basis for transfer/custody and disposition events and for retaining provenance metadata with the record." }, { "id": "SRC-020", "title": "PREMIS Data Dictionary for Preservation Metadata, Version 3.0", "organization": "Library of Congress", "url": "https://www.loc.gov/standards/premis/v3/", "version_or_date": "Version 3.0, updated November 2015", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T16:10:00Z", "relevance": "Preservation metadata model of Objects, Events, Agents and Rights; digital provenance as documented actions that modify objects; identifiers, eventDateTime, outcomes and linking roles." }, { "id": "SRC-021", "title": "SLSA Build Provenance", "organization": "Open Source Security Foundation (OpenSSF) SLSA", "url": "https://slsa.dev/spec/v1.2/build-provenance", "version_or_date": "SLSA specification Version 1.2", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T16:10:00Z", "relevance": "Verifiable software provenance describing where, when and how artifacts were produced: buildDefinition, runDetails, builder trust boundary, resolvedDependencies, timestamps and verification." }, { "id": "SRC-022", "title": "DCMI Metadata Terms: Provenance", "organization": "Dublin Core Metadata Initiative", "url": "https://www.dublincore.org/specifications/dublin-core/dcmi-terms/terms/provenance/", "version_or_date": "DCMI Metadata Terms, current release 2020-01-20 aligned to ISO 15836-2:2019", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T16:10:00Z", "relevance": "Defines dcterms:provenance as a statement of ownership and custody changes significant for authenticity, integrity and interpretation, ranging to ProvenanceStatement." }, { "id": "SRC-023", "title": "EPCIS and Core Business Vocabulary", "organization": "GS1", "url": "https://www.gs1.org/standards/epcis", "version_or_date": "EPCIS / CBV 2.0, ratified June 2022; also ISO/IEC 19987", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T16:10:00Z", "relevance": "Event-based traceability capturing what, when, where, why and how of products and assets, including chain of custody and transformation across supply chains." }, { "id": "SRC-024", "title": "Definition of the CIDOC Conceptual Reference Model", "organization": "CIDOC CRM Special Interest Group / ICOM", "url": "https://www.cidoc-crm.org/", "version_or_date": "CIDOC CRM version 7.2.3, 4 September 2023", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T16:10:00Z", "relevance": "Separates legal ownership (E8 Acquisition) from physical custody (E10 Transfer of Custody) and models modification, movement and actor participation in cultural-heritage provenance." }, { "id": "SRC-025", "title": "ISO 14721:2025 Space Data System Practices — Reference model for an open archival information system (OAIS)", "organization": "International Organization for Standardization / CCSDS", "url": "https://www.iso.org/standard/87471.html", "version_or_date": "ISO 14721:2025 (third edition), based on CCSDS 650.0-M-3 December 2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T16:10:00Z", "relevance": "OAIS Preservation Description Information includes Provenance Information as origin, changes and custody of Content Information, together with Reference, Context, Fixity and Access Rights Information." }, { "id": "SRC-026", "title": "in-toto Attestation Framework", "organization": "in-toto project / Linux Foundation", "url": "https://github.com/in-toto/attestation", "version_or_date": "Specification v1.2", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T16:10:00Z", "relevance": "Authenticated metadata about software artifacts: Envelope, Statement and Predicate layers used by SLSA provenance and other supply-chain attestations." }, { "id": "SRC-027", "title": "ISO 19115-1:2014 Geographic information — Metadata — Part 1: Fundamentals", "organization": "International Organization for Standardization, ISO/TC 211", "url": "https://www.iso.org/standard/53798.html", "version_or_date": "ISO 19115-1:2014, confirmed 2019, Amd 1:2018 and Amd 2:2020", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-22T16:10:00Z", "relevance": "Defines lineage as provenance, sources and production processes (LI_Lineage, LI_ProcessStep, LI_Source) and distinguishes that sense of provenance from ISO 5127's organisational meaning." }, { "id": "SRC-028", "title": "Dublin Core to PROV Mapping", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/prov-dc/", "version_or_date": "W3C Working Group Note 30 April 2013", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-22T16:10:00Z", "relevance": "Partial mapping of Dublin Core agency, date and derivation terms to PROV, and the special status of dct:provenance as a link to a ProvenanceStatement rather than a graph edge." } ], "structure": { "bundles": [ { "id": "subject-anchoring-and-record-identity", "name": "Subject Anchoring and Provenance Record Identity", "description": "Establishes precisely what the provenance is about, at what granularity, and how the provenance assertion itself is identified, versioned and made subject to its own provenance.", "rationale": "A mix-in has no meaning until its attachment point is fixed. in-toto matches subjects purely by digest, C2PA binds a claim to specified byte ranges, PREMIS distinguishes intellectual entity from representation, file and bitstream, and PROV distinguishes an entity from its specialisations and alternates. Ambiguous anchoring is the single most common way provenance becomes unverifiable.", "source_refs": [ "SRC-001", "SRC-005", "SRC-007", "SRC-017" ], "layers": [ { "id": "subject-anchor", "name": "Subject Anchor and Granularity", "description": "How the provenance statement is bound to the thing it describes, including granularity, fixed aspects and the contract by which the mix-in attaches to a host model.", "source_refs": [ "SRC-001", "SRC-007", "SRC-017", "SRC-015" ], "findings": [ { "id": "provenance-subject-anchor", "name": "Provenance subject anchor", "description": "The identified target that the provenance record describes, expressed so that a verifier can decide whether a given bitstream or record in hand is the subject.", "source_refs": [ "SRC-007", "SRC-005", "SRC-010", "SRC-001" ], "questions": [ { "id": "what-is-the-subject", "text": "Which identified entity, at which identifier authority, is this provenance record about?", "kind": "identity", "answer_data": [ "subject identifier value", "identifier scheme or issuing authority", "identifier resolution URI", "identifier priority tier used (master-system, governed IRI, minted UUID/ULID)" ] }, { "id": "how-is-subject-matched", "text": "By what mechanism does a verifier confirm that an artifact in hand is the anchored subject?", "kind": "validation", "answer_data": [ "digest set (algorithm and hex value)", "named byte or box ranges covered", "soft-binding identifier (fingerprint or watermark payload)", "match rule (digest-only, digest-plus-name, soft-binding tolerance)" ] }, { "id": "multiple-subjects", "text": "Does this record anchor more than one subject, and are the statements distributive or joint over them?", "kind": "composition", "answer_data": [ "subject list with per-subject descriptors", "distributive or joint semantics flag", "collection identifier if the subjects form a set" ] }, { "id": "anchor-stability", "text": "What happens to the anchor when the subject is re-encoded, re-serialised or migrated to another format?", "kind": "lifecycle", "answer_data": [ "anchor durability class (byte-exact, content-equivalent, perceptual)", "re-anchoring procedure reference", "successor subject identifier" ] } ], "data_elements": [ { "id": "subject-ref", "name": "subject reference", "description": "Reference to the entity the provenance describes, carrying the identifier and its authority.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-007", "SRC-010" ] }, { "id": "subject-descriptor", "name": "subject resource descriptor", "description": "Descriptor bundling name, URI, media type, digest set and download location for the anchored subject.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-007" ] }, { "id": "anchor-match-rule", "name": "anchor match rule", "description": "Coded rule stating how a candidate artifact is judged to be the anchored subject.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-007" ] } ], "artifacts": [ { "id": "subject-anchor-record", "name": "Subject anchor record", "description": "The persisted anchor binding a provenance assertion to one or more identified subjects with their descriptors and match rules.", "media_or_form": [ "structured record in any serialisation", "attestation statement subject block", "manifest binding assertion" ], "serial": false, "identity_strategy": "Identified by the provenance assertion identifier plus subject index; the subject itself is identified by authoritative master-system identifier, else governed IRI, else a UUID/ULID minted by the adopting Dimension with the minting authority recorded.", "source_refs": [ "SRC-007", "SRC-005" ] } ], "inline_only_rationale": null }, { "id": "subject-granularity-and-fixed-aspects", "name": "Subject granularity and fixed aspects", "description": "The level at which provenance is asserted (conceptual work, representation, file, bitstream, byte range, record field, physical instance) and which aspects of the entity are held fixed by the statement.", "source_refs": [ "SRC-017", "SRC-001", "SRC-013", "SRC-005" ], "questions": [ { "id": "granularity-level", "text": "At which granularity level is this provenance asserted, and is the same statement inherited by finer levels?", "kind": "classification", "answer_data": [ "granularity code (intellectual entity, representation, file, bitstream, segment, field, physical instance)", "inheritance rule to child levels", "scope statement text" ] }, { "id": "fixed-aspects", "text": "Which aspects of the entity does the statement treat as fixed, such that changing them yields a different entity?", "kind": "definition", "answer_data": [ "list of invariant aspects", "tolerated variations", "specialisation or alternate relation to a broader entity" ] }, { "id": "partial-coverage", "text": "If provenance covers only part of the subject, which part is covered and what is explicitly not covered?", "kind": "constraint", "answer_data": [ "covered region descriptor", "excluded region descriptor", "coverage completeness flag" ] } ], "data_elements": [ { "id": "granularity-code", "name": "granularity level", "description": "Coded level of the provenance subject within the intellectual-entity to bitstream hierarchy.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-017" ] }, { "id": "scope-statement", "name": "lineage scope statement", "description": "Human-readable statement of the scope to which the lineage applies, as in ISO lineage scope and statement.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "specialization-of", "name": "specialization of", "description": "Reference to a more general entity of which the subject is a more constrained specialisation.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "Granularity and fixed aspects are qualifiers of the anchor rather than separately transmissible objects; they are carried inline on the subject anchor record and on each lineage statement, and producing a distinct artifact would create a second place where scope could drift from the anchor it qualifies." }, { "id": "mixin-attachment-contract", "name": "Mix-in attachment contract", "description": "The obligations a host model accepts when it composes this provenance mix-in: which provenance elements become required, where they attach, and what the host must expose for anchoring.", "source_refs": [ "SRC-015", "SRC-009", "SRC-018", "SRC-001" ], "questions": [ { "id": "required-on-attach", "text": "Which provenance elements become mandatory for every instance of the host entity once the mix-in is applied?", "kind": "requirement", "answer_data": [ "required element list", "cardinality per element", "host entity classes in scope" ] }, { "id": "attachment-point", "text": "Where does provenance attach — on the host entity, on each of its versions, or on a separate assertion object?", "kind": "composition", "answer_data": [ "attachment pattern code (embedded, sidecar, external assertion)", "reference direction (host-to-provenance or provenance-to-host)", "cardinality of assertions per host entity" ] }, { "id": "host-obligations", "text": "What must the host model guarantee about its own identifiers and version boundaries for provenance to remain verifiable?", "kind": "interoperability", "answer_data": [ "identifier stability guarantee", "version boundary definition", "change-notification obligation" ] } ], "data_elements": [ { "id": "attachment-pattern", "name": "attachment pattern", "description": "Coded pattern by which provenance is carried relative to the host entity.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-009" ] }, { "id": "required-element-profile", "name": "required element profile", "description": "Profile naming which provenance elements the adopting Dimension makes mandatory for a given host class.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-015", "SRC-018" ] } ], "artifacts": [ { "id": "provenance-profile", "name": "Provenance application profile", "description": "A named profile stating, for one host model or one Dimension, which provenance elements are mandatory, recommended or forbidden, and the identifier and timestamp rules that apply.", "media_or_form": [ "profile document", "machine-readable constraint set", "conformance checklist" ], "serial": false, "identity_strategy": "Governed profile IRI within the adopting Dimension namespace, with a semantic version; superseded profiles retain their IRI and are marked superseded rather than deleted.", "source_refs": [ "SRC-015", "SRC-018" ] } ], "inline_only_rationale": null } ] }, { "id": "provenance-record-identity", "name": "Provenance Record Identity and Meta-Provenance", "description": "Identity, immutability and versioning of the provenance assertion itself, and the provenance of that assertion.", "source_refs": [ "SRC-001", "SRC-005", "SRC-015", "SRC-010" ], "findings": [ { "id": "provenance-assertion-record-identity", "name": "Provenance assertion record identity", "description": "How an individual provenance assertion or bundle is identified, versioned and treated as append-only, so that statements can be cited, superseded and audited without silent mutation.", "source_refs": [ "SRC-001", "SRC-005", "SRC-015", "SRC-010" ], "questions": [ { "id": "assertion-id", "text": "What identifier does this provenance assertion carry, and who minted it?", "kind": "identity", "answer_data": [ "assertion identifier", "minting authority", "identifier tier used", "creation timestamp" ] }, { "id": "assertion-immutability", "text": "Is the assertion immutable once issued, and how is a correction expressed?", "kind": "lifecycle", "answer_data": [ "immutability flag", "correction mechanism (superseding assertion, update manifest, error declaration)", "supersedes/superseded-by references" ] }, { "id": "assertion-versioning", "text": "How are successive assertions about the same subject ordered and reconciled into a current view?", "kind": "state", "answer_data": [ "sequence or generation number", "ordering key (recorded time plus tiebreaker)", "current-view derivation rule" ] }, { "id": "assertion-authorship", "text": "Which agent issued the assertion, as distinct from the agents named inside it?", "kind": "provenance", "answer_data": [ "asserting agent reference", "asserting system identifier", "assertion creation activity reference" ] } ], "data_elements": [ { "id": "assertion-id-field", "name": "provenance assertion identifier", "description": "Stable identifier of the provenance assertion or bundle, distinct from the subject identifier.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-015" ] }, { "id": "assertion-recorded-at", "name": "assertion recorded at", "description": "Timestamp at which the assertion was recorded by the asserting system, in RFC 3339 with an explicit offset or Z.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-010", "SRC-014" ] }, { "id": "supersedes-ref", "name": "supersedes", "description": "Reference to a prior assertion that this assertion corrects or replaces.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-008" ] } ], "artifacts": [ { "id": "provenance-assertion", "name": "Provenance assertion", "description": "The unit of provenance exchange: a set of provenance statements about one or more anchored subjects, issued by one asserting agent at one recorded time.", "media_or_form": [ "signed attestation", "provenance bundle", "embedded manifest", "database record set" ], "serial": true, "identity_strategy": "Authoritative identifier from the asserting master system where one exists; otherwise a governed IRI; otherwise a UUIDv7 or ULID minted by the adopting Dimension. Serial members are ordered by recorded time with the assertion identifier as tiebreaker, never by date alone.", "source_refs": [ "SRC-001", "SRC-005", "SRC-015" ] } ], "inline_only_rationale": null }, { "id": "provenance-of-provenance", "name": "Provenance of the provenance record", "description": "Treating a provenance bundle as an entity in its own right so that its own origin, author, transformations and trust can be described and audited.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004" ], "questions": [ { "id": "bundle-as-entity", "text": "Is this provenance bundle itself described as an entity with its own generation activity and responsible agent?", "kind": "provenance", "answer_data": [ "bundle entity identifier", "bundle generation activity reference", "bundle attributed-to agent" ] }, { "id": "meta-depth", "text": "How many levels of provenance-about-provenance are retained, and where does the chain terminate?", "kind": "constraint", "answer_data": [ "meta level depth limit", "termination rule", "root-of-trust reference" ] }, { "id": "aggregation-provenance", "text": "When provenance from several sources is merged, what records which statement came from which source bundle?", "kind": "provenance", "answer_data": [ "per-statement source bundle reference", "merge activity reference", "merge policy identifier" ] } ], "data_elements": [ { "id": "bundle-ref", "name": "provenance bundle reference", "description": "Reference to a named set of provenance descriptions treated as an entity.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "statement-origin-ref", "name": "statement origin reference", "description": "Per-statement pointer to the bundle or system from which the statement was ingested.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-004" ] } ], "artifacts": [ { "id": "meta-provenance-bundle", "name": "Meta-provenance bundle", "description": "A bundle whose subjects are other provenance bundles, recording who produced, merged, transformed or republished provenance statements.", "media_or_form": [ "provenance bundle", "graph named-set export" ], "serial": false, "identity_strategy": "Governed IRI for the bundle; where ingested from an external system, the source system identifier is retained as an alternate identifier alongside the locally minted one.", "source_refs": [ "SRC-001", "SRC-004" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "origin-derivation-and-lineage", "name": "Origin, Derivation and Lineage", "description": "Where the subject came from: its origination, its sources and ingredients, the derivation relations that connect it to prior entities, and how far the resulting lineage can be traversed and trusted.", "rationale": "Every consulted standard centres on the same pair of facts — an entity was generated by an activity, and an entity was derived from other entities. PROV names the relations, ISO lineage names process steps and sources, C2PA names ingredients, SLSA names resolved dependencies, and dcterms names source and primary source. The bundle collects the graph and the honest statement of where it stops.", "source_refs": [ "SRC-001", "SRC-013", "SRC-005", "SRC-006", "SRC-008" ], "layers": [ { "id": "origination-and-source", "name": "Origination and Source", "description": "The first-instance creation or capture of the subject and the identified prior resources it came from.", "source_refs": [ "SRC-001", "SRC-008", "SRC-005", "SRC-013" ], "findings": [ { "id": "origination-event", "name": "Origination event", "description": "The act by which the subject first came into existence, including the instrument or device used, the responsible agent, the place and the generation time.", "source_refs": [ "SRC-001", "SRC-009", "SRC-005", "SRC-017" ], "questions": [ { "id": "origination-activity", "text": "Which activity generated the subject, and what type of origination was it (capture, authoring, synthesis, derivation, accession)?", "kind": "event", "answer_data": [ "origination activity identifier", "origination type code", "activity start and end times" ] }, { "id": "origination-instrument", "text": "What instrument, device or software produced the subject, and at what version?", "kind": "provenance", "answer_data": [ "instrument identifier", "device make, model and serial number", "software name and version", "configuration or parameter set" ] }, { "id": "first-hand-or-reconstructed", "text": "Was the origination observed and recorded at the time, or reconstructed after the fact?", "kind": "evidence", "answer_data": [ "record basis code (contemporaneous, reconstructed, inferred, asserted-without-evidence)", "evidence references", "reconstruction method" ] }, { "id": "origination-completeness", "text": "If origination is unknown, is that recorded explicitly rather than left absent?", "kind": "quality", "answer_data": [ "unknown-origin flag", "reason for unknown", "earliest known custody point" ] } ], "data_elements": [ { "id": "generation-time", "name": "generation time", "description": "Instant at which the subject was generated by the origination activity, in RFC 3339 with explicit offset or Z.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-001" ] }, { "id": "instrument-ref", "name": "instrument reference", "description": "Reference to the device, equipment or software application used as the instrument of origination.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-005" ] }, { "id": "origination-type", "name": "origination type", "description": "Coded kind of origination act.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-017" ] } ], "artifacts": [ { "id": "origination-record", "name": "Origination record", "description": "The recorded statement of first creation or capture, linking activity, agent, instrument, place and generation time to the subject.", "media_or_form": [ "event record", "creation action description", "capture assertion" ], "serial": true, "identity_strategy": "Event identifier assigned by the recording system where authoritative; otherwise a minted UUID/ULID. Ordering within the series uses generation time plus recorded time, never date alone.", "source_refs": [ "SRC-001", "SRC-017" ] } ], "inline_only_rationale": null }, { "id": "primary-source-and-ingredients", "name": "Primary sources and ingredients", "description": "The identified prior resources that contributed to the subject, distinguishing a primary source from intermediate sources and recording each contributor with its own provenance status.", "source_refs": [ "SRC-002", "SRC-008", "SRC-005", "SRC-013", "SRC-006" ], "questions": [ { "id": "which-sources", "text": "Which prior entities were used as sources or ingredients, and in what role did each contribute?", "kind": "relationship", "answer_data": [ "source entity references", "contribution role code (primary source, ingredient, dependency, quoted-from, parent)", "per-source digest or citation" ] }, { "id": "primary-source-flag", "text": "Which source, if any, is the primary source — the originating rather than intermediate account?", "kind": "classification", "answer_data": [ "primary source reference", "basis for the primary-source judgement", "intermediate source chain" ] }, { "id": "source-provenance-status", "text": "For each source, is its own provenance known, absent, or explicitly unknown?", "kind": "quality", "answer_data": [ "per-source provenance status code", "referenced source assertion identifier", "validation outcome for the source assertion" ] }, { "id": "resolved-dependencies", "text": "Which dependencies were resolved at the time of production, and were they pinned by digest?", "kind": "constraint", "answer_data": [ "dependency descriptor list", "pinned digest per dependency", "resolution timestamp" ] } ], "data_elements": [ { "id": "source-ref", "name": "source reference", "description": "Reference to a related resource from which the subject is derived.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-002" ] }, { "id": "ingredient-descriptor", "name": "ingredient descriptor", "description": "Descriptor of a contributing asset including its identifier, digest, relationship role and any provenance assertion travelling with it.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-006" ] }, { "id": "has-primary-source", "name": "has primary source", "description": "Relation marking a source as the originating account rather than a secondary rendering.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "source-register", "name": "Source and ingredient register", "description": "The enumerated set of sources and ingredients contributing to the subject, each with role, identifier, digest and provenance status.", "media_or_form": [ "ingredient assertion set", "source list in lineage metadata", "resolved dependency list" ], "serial": false, "identity_strategy": "Register identity derives from the provenance assertion that carries it; each member is identified by the source entity's authoritative identifier where available, else by digest, else by a minted local identifier.", "source_refs": [ "SRC-005", "SRC-013", "SRC-006" ] } ], "inline_only_rationale": null } ] }, { "id": "derivation-graph", "name": "Derivation Graph and Traversal", "description": "The typed relations that link entities across generations and the practical limits of traversing them.", "source_refs": [ "SRC-001", "SRC-010", "SRC-008", "SRC-014" ], "findings": [ { "id": "derivation-and-influence-relations", "name": "Derivation and influence relations", "description": "The typed entity-to-entity relations — derivation, revision, quotation, primary source, instantiation, removal, membership, transformation — and the qualification that records how and by which activity each relation came about.", "source_refs": [ "SRC-001", "SRC-002", "SRC-010", "SRC-008", "SRC-014" ], "questions": [ { "id": "relation-type", "text": "Which typed relation holds between the subject and each related entity, and is a weaker generic influence relation being used because the specific type is unknown?", "kind": "relationship", "answer_data": [ "relation type code", "related entity reference", "reason for using a generic relation" ] }, { "id": "relation-qualification", "text": "Through which activity, role and time did the relation come about?", "kind": "process", "answer_data": [ "qualifying activity reference", "role of the used entity", "usage time", "generation time of the result" ] }, { "id": "transformation-semantics", "text": "For transformations that consume inputs and produce new outputs, is the input-to-output correspondence one-to-one, many-to-one or unresolvable?", "kind": "composition", "answer_data": [ "input list", "output list", "correspondence type code", "transformation event identifier" ] }, { "id": "directionality", "text": "Is the relation asserted forwards from the subject, backwards from a descendant, or both, and which direction is authoritative?", "kind": "authority", "answer_data": [ "assertion direction", "asserting party per direction", "conflict resolution rule" ] } ], "data_elements": [ { "id": "derivation-relation", "name": "derivation relation", "description": "Typed link from the subject to a prior entity, optionally qualified by activity, usage and generation.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "entity-role-code", "name": "entity role code", "description": "Coded role of a related entity in the activity, such as derivation, revision, quotation, source, instantiates or removal.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "member-of", "name": "member of collection", "description": "Membership link between the subject and a collection or aggregate entity.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-014" ] } ], "artifacts": [ { "id": "lineage-graph-export", "name": "Lineage graph export", "description": "A traversable export of the derivation graph for a subject, with typed edges, qualifying activities and per-edge assertion sources.", "media_or_form": [ "graph serialisation in any notation", "edge list with qualification records", "tabular lineage export" ], "serial": false, "identity_strategy": "Export identified by subject identifier plus traversal parameters plus the RFC 3339 instant of extraction; exports are immutable snapshots and are never updated in place.", "source_refs": [ "SRC-001", "SRC-013" ] } ], "inline_only_rationale": null }, { "id": "lineage-completeness-and-traversal", "name": "Lineage completeness and traversal limits", "description": "How far back and forward the lineage is claimed to be complete, where it is truncated, and how unknown provenance is represented rather than implied by absence.", "source_refs": [ "SRC-005", "SRC-006", "SRC-018", "SRC-013" ], "questions": [ { "id": "claimed-completeness", "text": "Over what span is the lineage claimed complete, and is completeness asserted or merely not contradicted?", "kind": "quality", "answer_data": [ "completeness claim code", "span covered (generations or time window)", "basis for the completeness claim" ] }, { "id": "truncation-points", "text": "At which nodes does the recorded lineage stop, and why — unknown provenance, redaction, out-of-scope, or an external boundary?", "kind": "exception", "answer_data": [ "truncation node reference", "truncation reason code", "pointer to an external provenance service if any" ] }, { "id": "traversal-limits", "text": "What depth, breadth and cost limits apply when an agent traverses the graph, and what is returned when a limit is hit?", "kind": "process", "answer_data": [ "maximum depth", "maximum node count", "partial-result indicator", "continuation token semantics" ] }, { "id": "cycle-handling", "text": "How are cycles or self-referential derivations detected and reported?", "kind": "validation", "answer_data": [ "cycle detection outcome", "offending edge references", "validation status code" ] } ], "data_elements": [ { "id": "completeness-claim", "name": "lineage completeness claim", "description": "Coded statement of how complete the recorded lineage is over a stated span.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-018" ] }, { "id": "unknown-provenance-marker", "name": "unknown provenance marker", "description": "Explicit marker that a node's provenance is unknown, distinguishing it from a node whose provenance simply was not queried.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "traversal-limit-set", "name": "traversal limit set", "description": "Declared depth, breadth and cost limits governing lineage traversal responses.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "completeness-statement", "name": "Lineage completeness statement", "description": "A dated statement of what the lineage covers, where it is truncated and for what reason, issued alongside a lineage export.", "media_or_form": [ "statement record", "free-text lineage statement with structured qualifiers" ], "serial": false, "identity_strategy": "Bound to the lineage export it accompanies; identified by the export identifier plus a statement discriminator.", "source_refs": [ "SRC-013", "SRC-018" ] } ], "inline_only_rationale": null }, { "id": "generation-usage-and-communication-constraints", "name": "Generation, usage and communication", "description": "Generation is the completion of production of a new entity by an activity. Usage is the beginning of utilizing an entity. Communication is exchange of some unspecified entity between two activities.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ], "questions": [ { "id": "generation-usage-and-communication-constraints-q01", "text": "Which activity generated this entity, at what time, and in what role?", "kind": "event", "answer_data": [ "generation_id", "activity_id", "at_time", "role" ] }, { "id": "generation-usage-and-communication-constraints-q02", "text": "Which entities did this activity use, at what times, and did usage consume them?", "kind": "event", "answer_data": [ "usage_id", "entity_id", "at_time", "role", "consumed_flag" ] }, { "id": "generation-usage-and-communication-constraints-q03", "text": "Was this activity informed by another activity, implying an unspecified exchanged entity?", "kind": "relationship", "answer_data": [ "communication_id", "informant_activity_id", "informed_activity_id" ] }, { "id": "generation-usage-and-communication-constraints-q04", "text": "Is there at most one generation of this entity in this instance, as required for valid PROV?", "kind": "validation", "answer_data": [ "generation_count", "constraint_status" ] } ], "data_elements": [ { "id": "generation-usage-and-communication-constraints-data01", "name": "Generation identifier", "description": "Optional identifier of a generation event.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "generation-usage-and-communication-constraints-data02", "name": "Usage identifier", "description": "Optional identifier of a usage event.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "generation-usage-and-communication-constraints-data03", "name": "Generation time", "description": "RFC 3339 instant of generation.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "generation-usage-and-communication-constraints-data04", "name": "Usage time", "description": "RFC 3339 instant usage began.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "generation-usage-and-communication-constraints-data05", "name": "Role", "description": "Function of an entity or agent with respect to an activity in a usage, generation or association.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "Generation, usage and communication are qualified relations; they are inline graph data unless bundled into a named provenance artifact." } ] } ] }, { "id": "agency-activity-and-custody", "name": "Agency, Activity and Custody", "description": "Who and what acted, under whose authority, with which plan, and in whose hands the subject has been over time.", "rationale": "Responsibility is the part of provenance that carries legal and evidential weight. PROV separates attribution, association and delegation; PREMIS links every event to agents with roles; C2PA distinguishes the claim generator from the signer; RiC-CM makes creator, mandate and activity first-class; dcterms:provenance is defined specifically in terms of custody and ownership changes.", "source_refs": [ "SRC-001", "SRC-017", "SRC-005", "SRC-016", "SRC-008" ], "layers": [ { "id": "activities-and-plans", "name": "Activities, Process Steps and Plans", "description": "The acts that operated on the subject and the plans, algorithms, mandates and authorisations that governed them.", "source_refs": [ "SRC-001", "SRC-013", "SRC-006", "SRC-016" ], "findings": [ { "id": "activity-and-process-step", "name": "Activity and process step", "description": "An act occurring over a period that used and generated entities, described with enough parameter detail to explain or reproduce its effect on the subject.", "source_refs": [ "SRC-001", "SRC-013", "SRC-006", "SRC-005" ], "questions": [ { "id": "activity-identity-type", "text": "What identifies this activity and what type of act was it?", "kind": "identity", "answer_data": [ "activity identifier", "activity type code", "business step or action label", "description and rationale" ] }, { "id": "activity-parameters", "text": "Which parameters were externally supplied and which were internal to the executing platform?", "kind": "process", "answer_data": [ "external parameter set", "internal parameter set", "parameter digests where large", "platform or build type identifier" ] }, { "id": "activity-inputs-outputs", "text": "Which entities did the activity use, and which did it generate or invalidate?", "kind": "composition", "answer_data": [ "used entity references with usage times", "generated entity references with generation times", "invalidated entity references", "byproducts" ] }, { "id": "activity-reproducibility", "text": "Is the activity claimed to be reproducible, and what would be needed to repeat it?", "kind": "evidence", "answer_data": [ "reproducibility claim", "algorithm and version", "processing environment description", "reference documentation" ] } ], "data_elements": [ { "id": "activity-ref", "name": "activity reference", "description": "Reference to the activity or process step that acted on the subject.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-013" ] }, { "id": "activity-parameter-set", "name": "activity parameters", "description": "Structured record of the externally supplied and internally determined parameters of the activity.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "step-date-time", "name": "process step date and time", "description": "Date and time, or period, at which the process step was performed, in RFC 3339 with explicit offset or Z.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013", "SRC-010" ] } ], "artifacts": [ { "id": "process-step-record", "name": "Process step record", "description": "A recorded step in the treatment of the subject, carrying description, rationale, processor, time, sources, outputs and any processing report.", "media_or_form": [ "process step entry", "action assertion", "build definition record" ], "serial": true, "identity_strategy": "Step identifier from the executing system where authoritative, else a minted ULID; steps are ordered by step time with a monotonic sequence number as tiebreaker.", "source_refs": [ "SRC-013", "SRC-005", "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "plan-mandate-and-authorisation", "name": "Plan, mandate and authorisation", "description": "The plan, policy, mandate or legal authority under which an activity was carried out, distinguishing what was intended from what occurred.", "source_refs": [ "SRC-001", "SRC-010", "SRC-016", "SRC-011" ], "questions": [ { "id": "governing-plan", "text": "Which plan, protocol, workflow or algorithm was the activity intended to follow?", "kind": "authority", "answer_data": [ "plan identifier and version", "plan document reference", "deviation notes" ] }, { "id": "legal-mandate", "text": "Under which mandate, policy or legal basis was the activity authorised?", "kind": "authority", "answer_data": [ "mandate or policy identifier", "legal instrument citation", "authorisation decision reference", "purpose of use" ] }, { "id": "plan-versus-execution", "text": "Did execution deviate from the plan, and is the deviation recorded?", "kind": "exception", "answer_data": [ "deviation flag", "deviation description", "approver of the deviation" ] } ], "data_elements": [ { "id": "plan-ref", "name": "plan reference", "description": "Reference to the plan or protocol an agent intended to follow in the activity.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "policy-ref", "name": "policy or mandate reference", "description": "Reference to the policy, mandate or legal instrument authorising the activity.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010", "SRC-016" ] }, { "id": "authorisation-purpose", "name": "authorisation purpose", "description": "Coded purpose of use for which the activity was authorised.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [ { "id": "authorisation-record", "name": "Authorisation record", "description": "Record linking an activity to the plan and the mandate or legal basis that authorised it, including any recorded deviation.", "media_or_form": [ "authorisation entry", "policy reference block" ], "serial": false, "identity_strategy": "Identified by the authorising system's decision identifier where one exists; otherwise by activity identifier plus mandate identifier.", "source_refs": [ "SRC-010", "SRC-016" ] } ], "inline_only_rationale": null }, { "id": "start-end-and-invalidation-events", "name": "Start, end and invalidation", "description": "Activities are delimited by start and end events; entities cease to be available after invalidation. These instantaneous events carry optional times and triggering entities or activities.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ], "questions": [ { "id": "start-end-and-invalidation-events-q01", "text": "Which entity or activity started this activity, and at what time?", "kind": "lifecycle", "answer_data": [ "start_id", "starter_entity_id", "starter_activity_id", "at_time" ] }, { "id": "start-end-and-invalidation-events-q02", "text": "Which entity or activity ended this activity, and at what time?", "kind": "lifecycle", "answer_data": [ "end_id", "ender_entity_id", "ender_activity_id", "at_time" ] }, { "id": "start-end-and-invalidation-events-q03", "text": "Which activity invalidated this entity, at what time, and is the entity no longer available for use?", "kind": "state", "answer_data": [ "invalidation_id", "activity_id", "at_time", "reason" ] } ], "data_elements": [ { "id": "start-end-and-invalidation-events-data01", "name": "Invalidation time", "description": "RFC 3339 instant after which the entity no longer exists for use.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "start-end-and-invalidation-events-data02", "name": "Invalidating activity", "description": "Activity that invalidated the entity.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "start-end-and-invalidation-events-data03", "name": "Activity start event time", "description": "RFC 3339 instant of the start event when distinct from activity startedAtTime.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [], "inline_only_rationale": "Start, end and invalidation are instantaneous events represented as qualified relations, not independent documents." } ] }, { "id": "agents-and-attribution", "name": "Agents, Attribution and Delegation", "description": "The parties and mechanisms bearing responsibility, their qualified roles, and the chain by which responsibility is delegated.", "source_refs": [ "SRC-001", "SRC-017", "SRC-010", "SRC-005", "SRC-016" ], "findings": [ { "id": "agent-identity-type-and-role", "name": "Agent identity, type and role", "description": "Identification and typing of each responsible party — person, organisation, position, software agent or mechanism — together with the qualified role it played.", "source_refs": [ "SRC-001", "SRC-017", "SRC-010", "SRC-016" ], "questions": [ { "id": "agent-identity", "text": "Which identifier and authority identify each responsible agent?", "kind": "identity", "answer_data": [ "agent identifier", "identifier authority or scheme", "agent display name", "identifier tier used" ] }, { "id": "agent-type", "text": "What kind of agent is it — person, group, organisation, position, software agent or device?", "kind": "classification", "answer_data": [ "agent type code", "software agent version", "device identifier" ] }, { "id": "agent-role", "text": "In what role did the agent participate in the activity or in relation to the entity?", "kind": "relationship", "answer_data": [ "role code", "qualified association reference", "attribution versus association distinction" ] }, { "id": "agent-substitutability", "text": "Where a natural person is named, is a position or organisational role recorded as well so that the record survives staff change?", "kind": "privacy", "answer_data": [ "position or role identifier", "organisation identifier", "personal-data minimisation decision" ] } ], "data_elements": [ { "id": "agent-ref", "name": "agent reference", "description": "Reference to a responsible agent as governed by the sibling agent model.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-010" ] }, { "id": "agent-type-code", "name": "agent type", "description": "Coded kind of agent bearing responsibility.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-017", "SRC-001" ] }, { "id": "agent-role-code", "name": "agent role", "description": "Coded role played by the agent in the activity or with respect to the entity.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010", "SRC-002" ] } ], "artifacts": [ { "id": "attribution-record", "name": "Attribution record", "description": "Record binding an entity or activity to one or more agents with their types and qualified roles.", "media_or_form": [ "attribution entry", "qualified association record", "linking agent identifier block" ], "serial": false, "identity_strategy": "Identified by the activity or entity identifier plus agent identifier plus role; agent identifiers are resolved against the governing agent registry rather than minted here.", "source_refs": [ "SRC-001", "SRC-017" ] } ], "inline_only_rationale": null }, { "id": "delegation-and-responsibility-chain", "name": "Delegation and responsibility chain", "description": "How responsibility passes upward from an acting agent to the party on whose behalf it acted, including the separation of the tool that generated a claim from the party that signed it.", "source_refs": [ "SRC-001", "SRC-010", "SRC-005", "SRC-006" ], "questions": [ { "id": "on-behalf-of", "text": "On whose behalf did each acting agent operate, and how far up does the chain go?", "kind": "ownership", "answer_data": [ "acting agent reference", "responsible party reference", "delegation chain ordering", "scope of the delegation" ] }, { "id": "generator-versus-signer", "text": "Which component generated the provenance claim, and which party signed it — are they the same?", "kind": "authority", "answer_data": [ "claim generator identifier and version", "signer identity", "separation flag", "credential subject" ] }, { "id": "liability-locus", "text": "Which named party accepts responsibility for the accuracy of the assertion?", "kind": "ownership", "answer_data": [ "accountable party identifier", "accountability statement", "contact or dispute channel" ] } ], "data_elements": [ { "id": "acted-on-behalf-of", "name": "acted on behalf of", "description": "Delegation link from an acting agent to the agent bearing higher responsibility.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-010" ] }, { "id": "claim-generator", "name": "claim generator", "description": "Identifier and version of the software component that produced the provenance claim.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-006" ] } ], "artifacts": [], "inline_only_rationale": "Delegation is a relation between agent references already carried on the attribution record and the signature block; materialising a separate delegation artifact would duplicate the signer identity and create a second source of truth about accountability that could diverge from the signed envelope." }, { "id": "chain-of-custody-and-transfer", "name": "Chain of custody and transfer", "description": "The ordered succession of parties that held or controlled the subject, and the accession, transfer and disposition events that moved it between them.", "source_refs": [ "SRC-008", "SRC-019", "SRC-016", "SRC-014", "SRC-017" ], "questions": [ { "id": "custody-sequence", "text": "Which parties have held or controlled the subject, in what order, and over which intervals?", "kind": "temporal", "answer_data": [ "holder references in sequence", "custody interval start and end", "custody type (physical, legal, logical)", "gaps in the sequence" ] }, { "id": "transfer-events", "text": "What transfer, accession or acquisition event moved custody, and under what instrument?", "kind": "event", "answer_data": [ "transfer event identifier", "transferring and receiving party", "instrument or agreement reference", "transfer completion time" ] }, { "id": "ownership-versus-custody", "text": "Did legal ownership change at the same time as physical or logical custody?", "kind": "ownership", "answer_data": [ "ownership change flag", "owner references before and after", "effective date of ownership change" ] }, { "id": "custody-evidence", "text": "What evidence supports each custody claim, and does any interval rest on inference alone?", "kind": "evidence", "answer_data": [ "evidence document references", "evidence strength code", "inferred-interval flag" ] } ], "data_elements": [ { "id": "custody-interval", "name": "custody interval", "description": "An interval during which a named party held or controlled the subject, with typed custody and interval bounds.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-016" ] }, { "id": "transfer-event-ref", "name": "transfer event reference", "description": "Reference to the event that moved custody or ownership between parties.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-019", "SRC-014" ] }, { "id": "provenance-statement-text", "name": "provenance statement", "description": "Human-readable statement of changes in ownership and custody significant for authenticity, integrity and interpretation.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [ { "id": "custody-register", "name": "Chain-of-custody register", "description": "The ordered, append-only register of custody intervals and the transfer events between them, with supporting evidence references.", "media_or_form": [ "custody register", "accession and transfer records", "source and destination lists on traceability events" ], "serial": true, "identity_strategy": "Register keyed to the subject identifier; each entry identified by the transferring system's transfer identifier where authoritative, else a minted ULID. Entries are ordered by effective transfer time with recorded time as tiebreaker.", "source_refs": [ "SRC-019", "SRC-008", "SRC-014" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "temporal-and-spatial-context", "name": "Temporal and Spatial Context", "description": "When each provenance fact occurred versus when it was recorded, the ordering rules that make a provenance instance internally consistent, the trust placed in clocks, and where activities took place.", "rationale": "Time is the dimension where provenance most often silently fails. FHIR separates occurred from recorded, EPCIS separates eventTime and eventTimeZoneOffset from recordTime, SLSA mandates UTC-normalised timestamps, PROV-CONSTRAINTS makes generation-before-use a validity condition, and C2PA relies on RFC 3161 tokens rather than self-declared clocks.", "source_refs": [ "SRC-010", "SRC-014", "SRC-003", "SRC-005", "SRC-006" ], "layers": [ { "id": "time-semantics", "name": "Time Semantics and Ordering", "description": "Distinct time axes, ordering constraints and externally trusted time.", "source_refs": [ "SRC-010", "SRC-014", "SRC-003", "SRC-005" ], "findings": [ { "id": "event-time-versus-record-time", "name": "Event time versus record time", "description": "Separate recording of when a provenance-relevant event occurred and when it was observed, ingested or recorded, each with an explicit offset, so that late, backdated and replayed records remain interpretable.", "source_refs": [ "SRC-010", "SRC-014", "SRC-006", "SRC-002" ], "questions": [ { "id": "which-time-axes", "text": "Which time axes are recorded for this fact — occurrence, observation, ingestion, publication, validity — and which are mandatory?", "kind": "temporal", "answer_data": [ "occurrence time", "recorded or ingestion time", "publication time", "validity interval", "mandatory-axis profile" ] }, { "id": "offset-and-zone", "text": "Is each timestamp expressed with an explicit UTC offset or Z, and is the local zone offset at the place of the event preserved separately?", "kind": "temporal", "answer_data": [ "RFC 3339 timestamp string", "explicit offset or Z", "separate local time-zone offset field", "normalisation policy" ] }, { "id": "latency-and-backdating", "text": "What is the permitted gap between occurrence and recording, and how is a backdated or late record flagged?", "kind": "constraint", "answer_data": [ "maximum acceptable latency", "late-record flag", "backdating justification", "approver of the backdated entry" ] }, { "id": "precision-and-granularity", "text": "What precision is claimed for each timestamp, and is a coarse value being stored in a fine-grained field?", "kind": "measurement", "answer_data": [ "claimed precision (second, minute, day)", "precision qualifier field", "uncertainty interval" ] } ], "data_elements": [ { "id": "occurred-at", "name": "occurred at", "description": "Instant or period at which the described activity or event actually occurred, in RFC 3339 with explicit offset or Z.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010", "SRC-014" ] }, { "id": "recorded-at", "name": "recorded at", "description": "Instant at which the fact was recorded by the recording system, in RFC 3339 with explicit offset or Z; never used as a substitute for occurrence time.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-010", "SRC-014" ] }, { "id": "local-zone-offset", "name": "local time-zone offset", "description": "Time-zone offset in effect at the time and place of the event, retained even when the timestamp is normalised to UTC.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "validity-interval", "name": "validity interval", "description": "Interval during which the asserted fact is held to be true, distinct from when it was recorded.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010", "SRC-002" ] } ], "artifacts": [ { "id": "temporal-annotation-set", "name": "Temporal annotation set", "description": "The set of time values attached to a provenance statement, one per declared axis, with precision and offset qualifiers.", "media_or_form": [ "timestamp block on any provenance record" ], "serial": false, "identity_strategy": "Carried by the statement it annotates; no independent identifier, but each axis is separately named so that axis confusion is detectable on validation.", "source_refs": [ "SRC-010", "SRC-014" ] } ], "inline_only_rationale": null }, { "id": "ordering-and-validity-constraints", "name": "Ordering and validity constraints", "description": "The consistency conditions that make a provenance instance safe to reason over, including generation-before-use ordering, single generation per entity, invalidation and non-reflexive specialisation.", "source_refs": [ "SRC-003", "SRC-001" ], "questions": [ { "id": "ordering-checks", "text": "Which ordering constraints are enforced, and which are merely reported as warnings?", "kind": "validation", "answer_data": [ "enforced constraint list", "warning-only constraint list", "validator identifier and version" ] }, { "id": "invalidation", "text": "Has the entity been invalidated, destroyed or expired, and at what time?", "kind": "lifecycle", "answer_data": [ "invalidation activity reference", "invalidation time", "reason code" ] }, { "id": "merge-uniqueness", "text": "When two statements share an identifier, are they merged, and what happens if their attributes conflict?", "kind": "validation", "answer_data": [ "merge outcome", "conflicting attribute list", "conflict resolution decision" ] }, { "id": "instance-validity", "text": "Is the provenance instance normalised and declared valid, and against which constraint set?", "kind": "quality", "answer_data": [ "validity verdict", "constraint set identifier and version", "normalisation applied", "violated constraint references" ] } ], "data_elements": [ { "id": "validity-verdict", "name": "instance validity verdict", "description": "Outcome of checking a provenance instance against the declared constraint set.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "invalidated-at", "name": "invalidated at", "description": "Instant at which the entity was invalidated, destroyed or expired, in RFC 3339.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-001" ] } ], "artifacts": [ { "id": "constraint-check-report", "name": "Constraint check report", "description": "Report of an automated validity check over a provenance instance, listing satisfied, violated and unchecked constraints.", "media_or_form": [ "validation report", "machine-readable constraint outcome list" ], "serial": true, "identity_strategy": "Identified by the checked instance identifier plus the RFC 3339 instant of the check plus validator version; reports are immutable.", "source_refs": [ "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "trusted-timestamping", "name": "Trusted timestamping and clock trust", "description": "Use of an external time authority to prove that a provenance assertion existed at a point in time, and the treatment of self-declared clocks as weaker evidence.", "source_refs": [ "SRC-005", "SRC-006" ], "questions": [ { "id": "timestamp-authority", "text": "Is a trusted time-stamp token present, and which time authority issued it?", "kind": "evidence", "answer_data": [ "time-stamp token", "time authority identifier", "token issuance time", "covered data digest" ] }, { "id": "clock-source", "text": "For timestamps without an external token, what clock produced them and what is its known accuracy?", "kind": "provenance", "answer_data": [ "clock source description", "synchronisation method", "known drift or accuracy bound" ] }, { "id": "post-expiry-validity", "text": "How is the assertion evaluated after the signing credential expires, and does the time-stamp preserve its evidential value?", "kind": "lifecycle", "answer_data": [ "expiry handling rule", "time-stamp reliance flag", "re-timestamping schedule" ] } ], "data_elements": [ { "id": "timestamp-token", "name": "trusted time-stamp token", "description": "Token issued by an external time authority binding a digest to an instant.", "value_kind": "binary", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "time-authority-ref", "name": "time authority reference", "description": "Identifier of the authority that issued the time-stamp token.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "timestamp-evidence", "name": "Timestamp evidence object", "description": "The stored time-stamp token together with the digest it covers and the identity of the issuing time authority.", "media_or_form": [ "time-stamp token", "countersignature header" ], "serial": false, "identity_strategy": "Identified by the covered digest plus the issuing authority identifier plus the token serial assigned by that authority.", "source_refs": [ "SRC-005" ] } ], "inline_only_rationale": null } ] }, { "id": "place-and-jurisdiction", "name": "Place and Jurisdiction", "description": "Where activities occurred and which legal order governs the resulting provenance facts.", "source_refs": [ "SRC-002", "SRC-014", "SRC-010", "SRC-012" ], "findings": [ { "id": "activity-location-and-jurisdiction", "name": "Activity location and jurisdiction", "description": "The physical or logical place at which an activity occurred or an object was observed, and the jurisdiction whose rules attach to that fact.", "source_refs": [ "SRC-002", "SRC-014", "SRC-010", "SRC-011" ], "questions": [ { "id": "where-occurred", "text": "At what place did the activity occur or the observation take place?", "kind": "spatial", "answer_data": [ "place identifier", "coordinates or geometry", "read point versus business location distinction", "place name and granularity" ] }, { "id": "logical-location", "text": "Where a physical place is meaningless, what logical location applies — system, region, tenancy or endpoint?", "kind": "spatial", "answer_data": [ "logical location identifier", "hosting region", "system or endpoint identifier" ] }, { "id": "governing-jurisdiction", "text": "Which jurisdiction governs the activity and the resulting provenance record, and does it differ from where the record is stored?", "kind": "authority", "answer_data": [ "jurisdiction code", "storage jurisdiction", "applicable instrument references", "cross-border transfer basis" ] } ], "data_elements": [ { "id": "at-location", "name": "at location", "description": "Physical or logical location associated with an activity, entity or agent.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-014" ] }, { "id": "location-geometry", "name": "location geometry", "description": "Coordinate geometry of the place where the activity occurred, where spatially meaningful.", "value_kind": "geometry", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013", "SRC-014" ] }, { "id": "jurisdiction-code", "name": "governing jurisdiction", "description": "Coded jurisdiction whose rules govern the activity and the provenance record.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-012" ] } ], "artifacts": [], "inline_only_rationale": "Location and jurisdiction are qualifiers on activity, custody and observation records and are resolved against the sibling place and legal-jurisdiction models; creating a standalone artifact here would duplicate a gazetteer this model has no authority to maintain." } ] } ] }, { "id": "integrity-evidence-and-trust", "name": "Integrity Evidence, Attestation and Trust", "description": "The evidence that makes provenance believable: fixity values, content bindings, signed attestations, trust anchors and credential status, and the resulting verification outcome and confidence.", "rationale": "Unsigned provenance is a claim, not evidence. PREMIS grounds fixity in message digests, in-toto matches subjects purely by digest, C2PA distinguishes well-formed from valid from trusted and defines hard versus soft bindings, and SPDX attaches integrity methods to every element. Confidence and conflict handling must be modelled explicitly because verification frequently returns something other than pass or fail.", "source_refs": [ "SRC-017", "SRC-007", "SRC-005", "SRC-015", "SRC-003" ], "layers": [ { "id": "fixity-and-binding", "name": "Fixity and Content Binding", "description": "Digest-based integrity evidence and the methods that bind a provenance record to the bytes or the perceptual content of its subject.", "source_refs": [ "SRC-017", "SRC-015", "SRC-005", "SRC-007" ], "findings": [ { "id": "fixity-and-integrity-methods", "name": "Fixity and integrity methods", "description": "Recorded digests and other integrity methods over the subject, their algorithms, who computed them and when they were last verified.", "source_refs": [ "SRC-017", "SRC-015", "SRC-007" ], "questions": [ { "id": "which-digests", "text": "Which digest values over which algorithms are recorded for the subject, and over exactly what byte extent?", "kind": "evidence", "answer_data": [ "digest set (algorithm to value)", "covered extent description", "canonical form applied before hashing" ] }, { "id": "digest-originator", "text": "Who or what computed each digest, and is it independently reproducible?", "kind": "provenance", "answer_data": [ "digest originator identifier", "computation activity reference", "reproduction instructions" ] }, { "id": "fixity-check-history", "text": "When was fixity last verified, with what outcome, and on what schedule is it re-checked?", "kind": "process", "answer_data": [ "last check time", "check outcome", "check schedule or interval", "failure escalation path" ] }, { "id": "algorithm-agility", "text": "What happens when a digest algorithm is deprecated — are historic digests retained alongside new ones?", "kind": "lifecycle", "answer_data": [ "deprecated algorithm list", "migration policy", "retained historic digests", "re-hash activity reference" ] } ], "data_elements": [ { "id": "digest-set", "name": "digest set", "description": "Map of digest algorithm to digest value over the subject or a defined extent of it.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-017" ] }, { "id": "integrity-method", "name": "integrity method", "description": "Declared method by which the element is verified, of which a hash is one kind.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "last-fixity-check-at", "name": "last fixity check at", "description": "Instant of the most recent fixity verification, in RFC 3339 with explicit offset or Z.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] } ], "artifacts": [ { "id": "fixity-check-report", "name": "Fixity check report", "description": "Dated record of a fixity verification run over one or more subjects, with algorithm, expected and observed values and the outcome per subject.", "media_or_form": [ "check report", "event record with outcome information" ], "serial": true, "identity_strategy": "Identified by the checking system's run identifier where authoritative, else a minted ULID; ordered by check time. Each report is immutable and a failed check produces a new report rather than editing the prior one.", "source_refs": [ "SRC-017", "SRC-015" ] } ], "inline_only_rationale": null }, { "id": "subject-binding-hard-and-soft", "name": "Hard and soft binding to the subject", "description": "The mechanisms that tie a provenance record to its subject — cryptographic hard bindings over byte or box ranges, and soft bindings such as watermarks and perceptual fingerprints that survive re-encoding but do not prove integrity.", "source_refs": [ "SRC-005", "SRC-011", "SRC-007" ], "questions": [ { "id": "binding-method", "text": "Which binding methods are in force, and does the record rely on a hard binding, a soft binding, or both?", "kind": "classification", "answer_data": [ "binding method codes", "hard binding coverage description", "soft binding identifier and detector reference" ] }, { "id": "binding-strength", "text": "What does each binding actually prove — byte integrity, perceptual identity, or mere association?", "kind": "evidence", "answer_data": [ "proof strength per method", "known false-positive and false-negative behaviour", "tolerance thresholds" ] }, { "id": "embedded-or-detached", "text": "Is the provenance carried inside the subject, alongside it, or only in an external store, and what happens if it is stripped?", "kind": "interoperability", "answer_data": [ "carriage mode", "recovery path if stripped", "external store locator", "soft-binding fallback" ] }, { "id": "machine-readability", "text": "Is the binding machine-readable and detectable by a third party without prior arrangement?", "kind": "requirement", "answer_data": [ "machine-readable marking flag", "detection method reference", "interoperability profile" ] } ], "data_elements": [ { "id": "hard-binding", "name": "hard binding", "description": "Cryptographic binding covering defined ranges of the subject, providing tamper evidence.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "soft-binding", "name": "soft binding", "description": "Non-cryptographic identifier such as a watermark payload or perceptual fingerprint enabling matching across renditions.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-011" ] } ], "artifacts": [ { "id": "binding-assertion", "name": "Binding assertion", "description": "The statement recording which binding methods tie the provenance record to the subject, with their parameters and coverage.", "media_or_form": [ "hash binding assertion", "soft binding assertion", "detached sidecar record" ], "serial": false, "identity_strategy": "Identified within the provenance assertion by an assertion label and version; referenced from the claim by an internal URI so redaction and reference remain distinguishable.", "source_refs": [ "SRC-005" ] } ], "inline_only_rationale": null } ] }, { "id": "attestation-and-trust", "name": "Attestation, Signature and Trust Status", "description": "The signed envelope carrying provenance and the trust machinery that decides whether its signer is acceptable.", "source_refs": [ "SRC-005", "SRC-007", "SRC-006", "SRC-010" ], "findings": [ { "id": "signed-attestation-envelope", "name": "Signed attestation envelope", "description": "The separation between the payload of provenance statements, the predicate type that types it, and the signature that binds it to a signer identity.", "source_refs": [ "SRC-007", "SRC-005", "SRC-010", "SRC-006" ], "questions": [ { "id": "envelope-structure", "text": "What is the envelope structure — payload, payload type, signature — and which parts are covered by the signature?", "kind": "security", "answer_data": [ "payload type identifier", "signed byte coverage", "signature algorithm", "signature value" ] }, { "id": "signer-identity", "text": "Which identity signed the assertion, evidenced by which credential?", "kind": "identity", "answer_data": [ "signer identity", "credential or certificate reference", "credential subject attributes", "key identifier" ] }, { "id": "created-versus-gathered", "text": "Which statements does the signer originate and take responsibility for, and which were merely gathered from other components?", "kind": "authority", "answer_data": [ "created statement references", "gathered statement references", "provenance of each gathered statement" ] }, { "id": "detached-signature", "text": "Can the signature be verified without the original transport, and what canonical form must be reconstructed?", "kind": "validation", "answer_data": [ "canonicalisation rule", "serialisation independence flag", "verification input reconstruction steps" ] } ], "data_elements": [ { "id": "predicate-type", "name": "payload or predicate type", "description": "Type URI identifying the meaning of the provenance payload so that verifiers know how to interpret it.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-006" ] }, { "id": "signature-block", "name": "signature block", "description": "Signature value with algorithm, key identifier and covered-content reference.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-010" ] }, { "id": "created-assertion-refs", "name": "originated statement references", "description": "References to the statements the signer originates, as distinct from statements gathered from other components.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "attestation-envelope", "name": "Signed attestation envelope", "description": "The transportable signed unit binding a typed provenance payload to a signer identity and, where present, a trusted time-stamp.", "media_or_form": [ "signed envelope", "claim with claim signature", "signed manifest" ], "serial": false, "identity_strategy": "Identified by the enclosed assertion identifier; the envelope additionally carries the signer credential identifier so that the same payload signed by two parties yields two distinguishable envelopes.", "source_refs": [ "SRC-007", "SRC-005" ] } ], "inline_only_rationale": null }, { "id": "trust-anchors-and-revocation", "name": "Trust anchors, credential status and revocation", "description": "How a verifier decides that a signer is acceptable, and how expiry, revocation and trust-list changes alter a previously accepted verdict over time.", "source_refs": [ "SRC-005", "SRC-006" ], "questions": [ { "id": "trust-anchor-set", "text": "Against which trust anchors or trust lists is the signer evaluated, and who curates that list?", "kind": "authority", "answer_data": [ "trust list identifier and version", "curating organisation", "anchor certificates", "local override policy" ] }, { "id": "credential-status", "text": "What was the credential status at signing time and at verification time — valid, expired, revoked or unknown?", "kind": "state", "answer_data": [ "status at signing", "status at verification", "status source and check time", "revocation reason" ] }, { "id": "verdict-stability", "text": "Can a previously trusted assertion become untrusted, and is the earlier verdict retained rather than overwritten?", "kind": "lifecycle", "answer_data": [ "verdict history entries", "reason for verdict change", "re-evaluation trigger", "retention of superseded verdicts" ] }, { "id": "unknown-signer", "text": "How is an assertion from an unrecognised but cryptographically sound signer treated?", "kind": "exception", "answer_data": [ "handling policy for unknown signers", "downgrade rules", "quarantine or review queue reference" ] } ], "data_elements": [ { "id": "trust-list-ref", "name": "trust list reference", "description": "Identifier and version of the trust list against which the signer was evaluated.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "credential-status-code", "name": "credential status", "description": "Coded status of the signing credential at a stated evaluation instant.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "trust-evaluation-record", "name": "Trust evaluation record", "description": "Record of a single trust evaluation: the trust list used, credential status observed, evaluation instant and resulting trust verdict.", "media_or_form": [ "evaluation record", "verification log entry" ], "serial": true, "identity_strategy": "Identified by envelope identifier plus evaluation instant plus evaluating party; records are append-only so that verdict changes are visible as a series rather than a mutation.", "source_refs": [ "SRC-005" ] } ], "inline_only_rationale": null }, { "id": "claim-generator-signer-and-builder-trust", "name": "Claim generator, signer and builder", "description": "C2PA distinguishes claim generator, signer and actor. SLSA builder.id is the transitive closure of the trusted build platform. Signer identity is the basis of the C2PA trust model and must be paired with accepted builder identities for SLSA.", "source_refs": [ "SRC-005", "SRC-021", "SRC-026" ], "questions": [ { "id": "claim-generator-signer-and-builder-trust-q01", "text": "Which hardware or software generated the claim, on which operating system, and against which specification version?", "kind": "authority", "answer_data": [ "generator_id", "generator_name", "operating_system", "spec_version" ] }, { "id": "claim-generator-signer-and-builder-trust-q02", "text": "Who is the credential holder that signed the claim, and which certificate, EKU and trust list apply?", "kind": "authority", "answer_data": [ "signer_subject", "certificate_id", "eku", "trust_list_id" ] }, { "id": "claim-generator-signer-and-builder-trust-q03", "text": "What builder.id represents the trusted platform, and which fields were tenant-generated rather than control-plane-generated?", "kind": "security", "answer_data": [ "builder_id", "claimed_slsa_level", "tenant_generated_fields" ] } ], "data_elements": [ { "id": "claim-generator-signer-and-builder-trust-data01", "name": "Claim generator", "description": "Non-human actor that generated the claim and signature.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "claim-generator-signer-and-builder-trust-data02", "name": "Signer", "description": "Credential holder of the private key used to sign.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "claim-generator-signer-and-builder-trust-data03", "name": "Builder identity", "description": "URI indicating the transitive closure of the trusted build platform.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-021" ] }, { "id": "claim-generator-signer-and-builder-trust-data04", "name": "Specification version", "description": "Version of C2PA, SLSA or other spec used to generate the record.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "claim-generator-signer-and-builder-trust-artifact01", "name": "Signing credential", "description": "X.509 certificate or equivalent credential used to sign a claim, plus optional time-stamp token.", "media_or_form": [ "X.509 certificate", "RFC 3161 time-stamp", "COSE signature" ], "serial": true, "identity_strategy": "Identify certificates by issuer and serial number or SKI; identify builders by builder.id URI. Do not treat signature time as an identifier.", "source_refs": [ "SRC-005", "SRC-021" ] } ], "inline_only_rationale": null } ] }, { "id": "verification-and-confidence", "name": "Verification Outcome and Confidence", "description": "The reportable result of checking provenance and the honest expression of uncertainty, gaps and disagreement.", "source_refs": [ "SRC-005", "SRC-003", "SRC-014", "SRC-018" ], "findings": [ { "id": "verification-outcome-and-status", "name": "Verification outcome and status codes", "description": "The graded outcome of verification — structurally well-formed, cryptographically valid, trusted — expressed with per-check status codes rather than a single boolean.", "source_refs": [ "SRC-005", "SRC-003", "SRC-014" ], "questions": [ { "id": "outcome-grade", "text": "What grade did verification reach, and which specific checks passed, failed or were skipped?", "kind": "validation", "answer_data": [ "outcome grade", "per-check status codes", "skipped check reasons", "validator identity and version" ] }, { "id": "partial-failure", "text": "When some checks fail, is the remaining provenance still usable and under what caveat?", "kind": "exception", "answer_data": [ "usability decision", "caveat text", "degraded-use policy reference" ] }, { "id": "error-declaration-q", "text": "How does a producer retract or correct a previously published provenance statement it now knows to be wrong?", "kind": "process", "answer_data": [ "error declaration record", "declaration time", "corrected statement references", "reason" ] }, { "id": "reverification-cadence", "text": "How often is verification repeated, and what triggers an out-of-cycle re-verification?", "kind": "process", "answer_data": [ "scheduled cadence", "trigger events", "last verification time", "next due time" ] } ], "data_elements": [ { "id": "verification-grade", "name": "verification grade", "description": "Coded grade reached by verification, distinguishing structural well-formedness, cryptographic validity and trust.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "check-status-codes", "name": "check status codes", "description": "Per-check status codes recording the outcome of individual verification steps.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-003" ] }, { "id": "error-declaration", "name": "error declaration", "description": "Producer-issued declaration that a previously published provenance statement was erroneous, with reason and time.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014" ] } ], "artifacts": [ { "id": "verification-report", "name": "Verification report", "description": "Immutable dated report of a verification run over a provenance assertion, listing grade, per-check statuses and validator identity.", "media_or_form": [ "verification report", "status code list" ], "serial": true, "identity_strategy": "Identified by assertion identifier plus verification instant plus verifying party; reports are never updated, superseding reports are appended.", "source_refs": [ "SRC-005", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "confidence-gaps-and-conflicts", "name": "Confidence, gaps and conflicting claims", "description": "Explicit representation of how strongly each provenance statement is supported, where evidence is missing, and how two irreconcilable accounts of the same subject are held side by side.", "source_refs": [ "SRC-018", "SRC-013", "SRC-005", "SRC-016" ], "questions": [ { "id": "assertion-basis", "text": "Is each statement directly recorded, inferred from other statements, or asserted without supporting evidence?", "kind": "evidence", "answer_data": [ "basis code per statement", "inference rule reference", "supporting evidence references" ] }, { "id": "confidence-expression", "text": "How is confidence expressed, and is the scale defined well enough to be compared across producers?", "kind": "measurement", "answer_data": [ "confidence value", "scale definition and version", "assessing party", "assessment time" ] }, { "id": "conflicting-accounts", "text": "When two producers assert incompatible provenance for the same subject, are both retained and how is precedence decided?", "kind": "decision", "answer_data": [ "conflicting assertion references", "precedence rule applied", "authority ranking", "unresolved-conflict flag" ] }, { "id": "absence-semantics", "text": "Does absence of a provenance statement mean the fact is unknown, not applicable, or withheld?", "kind": "definition", "answer_data": [ "absence semantics code", "withholding reason", "pointer to a redaction record if withheld" ] } ], "data_elements": [ { "id": "basis-code", "name": "statement basis", "description": "Coded basis on which a provenance statement rests: recorded, inferred, asserted or reconstructed.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-018", "SRC-013" ] }, { "id": "confidence-value", "name": "confidence value", "description": "Value on a named and versioned scale expressing confidence in a provenance statement.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018" ] }, { "id": "conflict-set", "name": "conflict set", "description": "Grouping of mutually incompatible provenance statements about the same subject, with the applied precedence rule.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016", "SRC-005" ] } ], "artifacts": [ { "id": "conflict-register", "name": "Provenance conflict register", "description": "Register of known conflicting provenance accounts for a subject, retaining all sides with their sources, precedence decision and resolution status.", "media_or_form": [ "conflict register", "dispute record" ], "serial": true, "identity_strategy": "Identified by subject identifier plus conflict sequence number; entries are append-only and resolution is recorded as a new entry rather than deletion of the losing account.", "source_refs": [ "SRC-016", "SRC-005" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "governance-disclosure-and-exchange", "name": "Governance, Disclosure and Exchange", "description": "The obligations attached to provenance in law and policy, how provenance is discovered and accessed, how it is redacted or minimised, how long it is kept, and how it maps to neighbouring vocabularies.", "rationale": "Provenance is increasingly a compliance object, not only a metadata nicety: the AI Act requires machine-readable marking of synthetic content and retention of automatically generated logs, the GDPR requires disclosure of the source of personal data and downstream communication of erasure, and NARA requires disposition to be executed and evidenced. Discovery, redaction and crosswalking make those obligations operable without binding the model to a transport.", "source_refs": [ "SRC-011", "SRC-012", "SRC-019", "SRC-004", "SRC-005" ], "layers": [ { "id": "regulatory-disclosure", "name": "Regulatory Disclosure Duties", "description": "Provenance facts that specific legal instruments require to be recorded, marked or disclosed.", "source_refs": [ "SRC-011", "SRC-012" ], "findings": [ { "id": "synthetic-content-and-training-disclosure", "name": "Synthetic content marking and training-data lineage", "description": "Provenance obligations for AI-generated or manipulated output, including machine-readable marking, detectability, deepfake disclosure and summary-level disclosure of training content.", "source_refs": [ "SRC-011", "SRC-005" ], "questions": [ { "id": "ai-generation-status", "text": "Was the subject wholly or partly generated or manipulated by an AI system, and which parts?", "kind": "classification", "answer_data": [ "generation status code", "affected regions or components", "generating system identifier and version", "human involvement description" ] }, { "id": "marking-mechanism", "text": "By what mechanism is the AI-generated status marked so that it is machine-readable and detectable downstream?", "kind": "requirement", "answer_data": [ "marking mechanism (metadata assertion, watermark, fingerprint)", "interoperability profile", "robustness statement", "detection instructions" ] }, { "id": "training-lineage", "text": "What summary of training content is available for the generating model, and at what level of detail?", "kind": "provenance", "answer_data": [ "training data summary reference", "model identifier and version", "data source categories", "publication location" ] }, { "id": "disclosure-to-humans", "text": "Where a person must be told that content is artificially generated or manipulated, when and how is that disclosure made?", "kind": "process", "answer_data": [ "disclosure text", "disclosure timing", "presentation channel", "exemption claimed if any" ] } ], "data_elements": [ { "id": "synthetic-status", "name": "synthetic content status", "description": "Coded statement of whether and to what extent the subject was artificially generated or manipulated.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "generating-model-ref", "name": "generating model reference", "description": "Identifier and version of the AI system or model that generated or modified the subject.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "training-summary-ref", "name": "training content summary reference", "description": "Pointer to the published summary of content used to train the generating model.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] } ], "artifacts": [ { "id": "disclosure-notice", "name": "Synthetic content disclosure notice", "description": "The machine-readable and human-facing disclosure that content is artificially generated or manipulated, together with the mechanism by which it is detectable.", "media_or_form": [ "machine-readable marking", "embedded assertion", "human-facing notice" ], "serial": false, "identity_strategy": "Identified by subject identifier plus the generating activity identifier; where a marking is embedded, the embedded assertion label is retained as an alternate identifier.", "source_refs": [ "SRC-011", "SRC-005" ] } ], "inline_only_rationale": null }, { "id": "personal-data-source-disclosure", "name": "Personal data source and recipient disclosure", "description": "Provenance duties that arise when the subject contains personal data: telling a data subject where the data came from, recording processing activities, and communicating rectification or erasure to every recipient.", "source_refs": [ "SRC-012", "SRC-019" ], "questions": [ { "id": "personal-data-source-q", "text": "From which source did the personal data originate, and can that be stated to the data subject on request?", "kind": "provenance", "answer_data": [ "source description", "publicly accessible source flag", "availability of source information", "collection activity reference" ] }, { "id": "recipient-register", "text": "To which recipients has the data been disclosed, so that rectification or erasure can be communicated to each?", "kind": "relationship", "answer_data": [ "recipient identifiers", "disclosure event references", "disclosure time", "communication status per recipient" ] }, { "id": "processing-record", "text": "Which record of processing activities does this provenance feed, and which controller or processor maintains it?", "kind": "ownership", "answer_data": [ "processing record reference", "controller identity", "processor identity", "purpose of processing" ] }, { "id": "provenance-as-personal-data", "text": "Does the provenance record itself contain personal data about contributing agents, and is that necessary and minimised?", "kind": "privacy", "answer_data": [ "personal data elements in the provenance record", "necessity justification", "minimisation measure applied", "lawful basis" ] } ], "data_elements": [ { "id": "personal-data-source", "name": "personal data source", "description": "Statement of the source from which personal data in the subject originated.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "recipient-ref", "name": "recipient reference", "description": "Reference to a party to whom the subject or its personal data has been disclosed.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "downstream-notification-status", "name": "downstream notification status", "description": "Per-recipient status of communicating a rectification or erasure.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "disclosure-register", "name": "Disclosure and recipient register", "description": "Append-only register of disclosures of the subject to identified recipients, used to discharge downstream rectification and erasure communication duties.", "media_or_form": [ "recipient register", "disclosure event log" ], "serial": true, "identity_strategy": "Keyed to the subject identifier; each entry identified by the disclosing system's disclosure identifier where authoritative, else a minted ULID, ordered by disclosure time.", "source_refs": [ "SRC-012" ] } ], "inline_only_rationale": null } ] }, { "id": "access-redaction-and-privacy", "name": "Discovery, Access, Redaction and Minimisation", "description": "How consumers find and obtain provenance, and how producers withhold parts of it without destroying verifiability.", "source_refs": [ "SRC-004", "SRC-005", "SRC-012" ], "findings": [ { "id": "provenance-discovery-and-access", "name": "Provenance discovery and access", "description": "Interface-neutral means by which a consumer holding only the subject can locate the provenance record about it, and the query surface that returns lineage.", "source_refs": [ "SRC-004", "SRC-005" ], "questions": [ { "id": "discovery-mechanism", "text": "Given only the subject, by what mechanism does a consumer locate provenance about it?", "kind": "interoperability", "answer_data": [ "discovery mechanism code (embedded, link relation, resolver service, soft-binding lookup)", "provenance record locator", "anchor identifying which version the record describes" ] }, { "id": "query-surface", "text": "What query surface is offered — record retrieval, ancestor traversal, descendant traversal — and with what parameters?", "kind": "access", "answer_data": [ "query operations offered", "parameter set", "result shape", "pagination or continuation semantics" ] }, { "id": "pingback-and-downstream", "text": "Is there a channel by which downstream users notify the producer of derived works, and is that channel trusted?", "kind": "process", "answer_data": [ "notification endpoint", "accepted payload", "spam and abuse controls", "trust treatment of received notifications" ] }, { "id": "availability-guarantees", "text": "What availability and durability are guaranteed for provenance retrieval, and what does a consumer do when the record is unreachable?", "kind": "quality", "answer_data": [ "availability commitment", "cached copy policy", "offline verification fallback", "failure handling guidance" ] } ], "data_elements": [ { "id": "provenance-locator", "name": "provenance record locator", "description": "Locator by which the provenance record about the subject can be retrieved.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "provenance-anchor", "name": "provenance anchor", "description": "Qualifier stating which version or constrained rendering of a changing resource the provenance record describes.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "pingback-endpoint", "name": "notification endpoint", "description": "Endpoint at which downstream consumers may report derived works back to the producer.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "provenance-service-descriptor", "name": "Provenance service descriptor", "description": "Machine-readable description of how provenance for a class of subjects is discovered and queried, independent of any particular protocol binding.", "media_or_form": [ "service descriptor", "link relation set", "capability document" ], "serial": false, "identity_strategy": "Governed IRI within the adopting Dimension namespace, versioned; the descriptor records which concrete bindings implement it rather than being defined by any one of them.", "source_refs": [ "SRC-004" ] } ], "inline_only_rationale": null }, { "id": "redaction-and-selective-disclosure", "name": "Redaction, minimisation and selective disclosure", "description": "Removing or withholding parts of a provenance record for privacy, confidentiality or legal reasons while keeping the remainder verifiable and keeping the fact of removal visible.", "source_refs": [ "SRC-005", "SRC-012" ], "questions": [ { "id": "redaction-target", "text": "Which provenance elements have been redacted, and is the fact of redaction recorded even when the content is gone?", "kind": "privacy", "answer_data": [ "redacted element references", "redaction placeholder retained", "redaction reason code", "redacting party" ] }, { "id": "verifiability-after-redaction", "text": "Does the record still verify after redaction, and which checks necessarily fail?", "kind": "validation", "answer_data": [ "post-redaction verification grade", "checks invalidated by redaction", "re-signing requirement" ] }, { "id": "who-may-redact", "text": "Who is authorised to redact, and can a downstream party redact statements made by an upstream producer?", "kind": "authority", "answer_data": [ "authorised redactor roles", "upstream redaction permission", "approval record reference" ] }, { "id": "tiered-disclosure", "text": "Are different views of the provenance released to different audiences, and how are those views kept consistent?", "kind": "access", "answer_data": [ "view definitions per audience", "element visibility matrix", "consistency guarantee", "view generation activity reference" ] } ], "data_elements": [ { "id": "redaction-record", "name": "redaction record", "description": "Record of which provenance elements were removed or withheld, by whom, when and why.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-012" ] }, { "id": "visibility-class", "name": "visibility class", "description": "Coded audience class for which a provenance element is disclosed.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "redaction-log", "name": "Redaction log", "description": "Append-only log of redaction actions over provenance records, retaining the reference to what was removed without retaining the removed content.", "media_or_form": [ "redaction log", "placeholder assertion set" ], "serial": true, "identity_strategy": "Identified by the affected assertion identifier plus redaction sequence number; the removed content is not re-identified, only its former reference is retained.", "source_refs": [ "SRC-005", "SRC-012" ] } ], "inline_only_rationale": null } ] }, { "id": "retention-and-interoperability", "name": "Retention, Disposition and Vocabulary Alignment", "description": "How long provenance is kept and how it maps to the neighbouring standards it must exchange with.", "source_refs": [ "SRC-011", "SRC-012", "SRC-019", "SRC-001", "SRC-017" ], "findings": [ { "id": "provenance-retention-and-disposition", "name": "Provenance retention and disposition", "description": "Retention of the provenance record considered separately from the subject, including minimum statutory retention, disposition execution and the evidence that disposition occurred.", "source_refs": [ "SRC-011", "SRC-012", "SRC-019" ], "questions": [ { "id": "retention-period-q", "text": "For how long must this provenance record be retained, under which authority, and does that differ from the subject's own retention?", "kind": "retention", "answer_data": [ "retention period", "authority or schedule reference", "subject retention period", "divergence justification" ] }, { "id": "survives-subject-deletion", "text": "Does provenance survive deletion of the subject, and in what reduced form?", "kind": "lifecycle", "answer_data": [ "survival policy", "reduced record content", "tombstone representation", "link to deletion event" ] }, { "id": "disposition-evidence", "text": "When provenance is destroyed, what evidence of the destruction is itself retained?", "kind": "evidence", "answer_data": [ "disposition event record", "authorising schedule", "executing agent", "destruction time and method" ] }, { "id": "legal-hold-q", "text": "How does a legal hold or investigation suspend disposition, and who may lift it?", "kind": "exception", "answer_data": [ "hold identifier", "hold scope", "imposing authority", "release conditions and approver" ] } ], "data_elements": [ { "id": "retention-period-field", "name": "retention period", "description": "Period for which the provenance record must be retained, with the authority that sets it.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-019" ] }, { "id": "disposition-event-ref", "name": "disposition event reference", "description": "Reference to the event by which the provenance record or the subject was disposed of.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-019", "SRC-017" ] }, { "id": "legal-hold-flag", "name": "legal hold", "description": "Flag and identifier indicating that disposition is suspended by a hold.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019" ] } ], "artifacts": [ { "id": "disposition-record", "name": "Disposition record", "description": "Evidence record of a retention decision or destruction action affecting provenance, retained after the disposed content is gone.", "media_or_form": [ "disposition record", "tombstone entry" ], "serial": true, "identity_strategy": "Identified by the disposing system's disposition identifier where authoritative, else a minted ULID; tombstones retain the disposed record's identifier so that later references resolve to an explicit deletion rather than a silent absence.", "source_refs": [ "SRC-019", "SRC-017" ] } ], "inline_only_rationale": null }, { "id": "vocabulary-alignment-and-crosswalk", "name": "Vocabulary alignment and crosswalk", "description": "Recorded mappings between this model's elements and external provenance vocabularies, expressed as alignments with known lossy points rather than conformance claims.", "source_refs": [ "SRC-001", "SRC-017", "SRC-005", "SRC-014", "SRC-013", "SRC-010", "SRC-015" ], "questions": [ { "id": "which-alignments", "text": "To which external vocabularies is a mapping maintained, at which versions?", "kind": "interoperability", "answer_data": [ "target vocabulary identifiers and versions", "mapping direction", "maintainer", "last review date" ] }, { "id": "mapping-fidelity", "text": "For each mapped element, is the mapping exact, broader, narrower or approximate, and what is lost on round trip?", "kind": "quality", "answer_data": [ "mapping relation per element", "round-trip loss description", "unmapped element list" ] }, { "id": "conformance-claim", "text": "Is conformance to any external standard claimed, and what evidence supports the claim?", "kind": "validation", "answer_data": [ "conformance claim status", "test or validation evidence", "claim scope", "disclaimer text where no claim is made" ] }, { "id": "version-drift", "text": "How is drift handled when a mapped external vocabulary publishes a new version?", "kind": "lifecycle", "answer_data": [ "drift detection procedure", "review cadence", "deprecation handling", "migration record" ] } ], "data_elements": [ { "id": "alignment-mapping", "name": "alignment mapping", "description": "Mapping entry from a model element to an external vocabulary term with a stated mapping relation.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-017", "SRC-010" ] }, { "id": "external-identifier", "name": "external identifier", "description": "Identifier of the subject or a provenance element in an external system or scheme, retained alongside the local identifier.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] } ], "artifacts": [ { "id": "crosswalk-table", "name": "Provenance crosswalk table", "description": "Maintained table mapping this model's elements to PROV, PREMIS, C2PA, EPCIS, ISO lineage, FHIR Provenance, SPDX and in-toto/SLSA terms, with mapping relation and known losses.", "media_or_form": [ "mapping table", "machine-readable alignment set" ], "serial": false, "identity_strategy": "Governed IRI with a semantic version; each row is keyed by local element identifier plus target vocabulary identifier plus target vocabulary version so that mappings to different versions coexist.", "source_refs": [ "SRC-001", "SRC-017", "SRC-005", "SRC-014", "SRC-013", "SRC-010", "SRC-015" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "anchor-subject", "name": "Anchor provenance to a subject", "description": "Bind a provenance assertion to one or more identified subjects at a declared granularity, with descriptors and a match rule that lets a verifier decide whether an artifact in hand is the subject.", "inputs": [ "subject identifier and issuing authority", "subject descriptor including digest set where computable", "granularity level", "match rule selection" ], "outputs": [ "subject anchor record", "anchor validation result" ], "preconditions": [ "Subject identifier resolves under a declared authority or a UUID/ULID is minted with the minting authority recorded", "Granularity level is declared before any statement is attached" ], "effects": [ "Subsequent provenance statements in the assertion acquire a defined scope", "Ambiguous or unresolvable anchors are rejected rather than stored" ], "source_refs": [ "SRC-007", "SRC-005", "SRC-017" ] }, { "id": "record-provenance-event", "name": "Record a provenance event", "description": "Create an append-only record of an origination, transformation, transfer, disposition or verification act, with separate occurrence and recorded times, responsible agents and used and generated entities.", "inputs": [ "event type", "occurrence time and local zone offset", "agent references and roles", "used and generated entity references", "activity parameters" ], "outputs": [ "event record identifier", "recorded provenance statement" ], "preconditions": [ "Subject anchor exists", "Recording clock source is declared", "Agent references resolve in the governing agent registry or are recorded as unresolved" ], "effects": [ "Event is appended to the subject's provenance series", "Recorded time is set by the recording system and cannot be supplied by the caller" ], "source_refs": [ "SRC-001", "SRC-010", "SRC-014", "SRC-013" ] }, { "id": "assert-derivation", "name": "Assert a derivation relation", "description": "Record a typed relation between the subject and a prior entity, optionally qualified by the activity, role and times through which the relation arose.", "inputs": [ "source entity reference", "relation type", "qualifying activity reference", "usage and generation times" ], "outputs": [ "derivation statement", "updated lineage graph edge" ], "preconditions": [ "Both entities are identified", "Relation type is drawn from the governed relation vocabulary or a generic influence relation is used with a stated reason" ], "effects": [ "Lineage traversal from the subject reaches the source entity", "Ordering constraints between the related events become checkable" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-010" ] }, { "id": "seal-assertion", "name": "Seal a provenance assertion", "description": "Produce a signed envelope over a typed provenance payload, distinguishing statements the signer originates from statements gathered from other components, and attach a trusted time-stamp where available.", "inputs": [ "provenance payload", "payload or predicate type", "signer credential reference", "time authority reference" ], "outputs": [ "signed attestation envelope", "time-stamp evidence object" ], "preconditions": [ "Canonical form of the payload is defined and reproducible", "Signer credential is valid at signing time", "Originated and gathered statements are separately marked" ], "effects": [ "Payload becomes tamper-evident and attributable to a signer", "Later mutation requires a superseding assertion rather than an edit" ], "source_refs": [ "SRC-005", "SRC-007", "SRC-006" ] }, { "id": "verify-assertion", "name": "Verify a provenance assertion", "description": "Check an assertion for structural well-formedness, cryptographic validity and trust against a declared trust list, returning a graded outcome with per-check status codes.", "inputs": [ "signed attestation envelope", "trust list identifier and version", "credential status source", "verification instant" ], "outputs": [ "verification report", "verification grade", "per-check status codes" ], "preconditions": [ "Canonicalisation rule is available to reconstruct the signed bytes", "Trust list and its curating authority are declared" ], "effects": [ "A dated, immutable verification report is appended", "A previously trusted assertion may be regraded without erasing the earlier verdict" ], "source_refs": [ "SRC-005", "SRC-003" ] }, { "id": "verify-fixity", "name": "Verify subject fixity", "description": "Recompute digests over the anchored extent of the subject and compare them with recorded values, recording the outcome as evidence regardless of result.", "inputs": [ "subject reference", "recorded digest set", "canonical form rule", "check instant" ], "outputs": [ "fixity check report", "fixity outcome per subject" ], "preconditions": [ "At least one digest with a named algorithm is recorded", "The covered extent is unambiguously defined" ], "effects": [ "Integrity evidence is refreshed with a dated outcome", "A mismatch raises an integrity exception and does not overwrite the recorded digest" ], "source_refs": [ "SRC-017", "SRC-015", "SRC-007" ] }, { "id": "validate-instance", "name": "Validate provenance instance consistency", "description": "Normalise a provenance instance and check it against ordering, uniqueness and impossibility constraints, reporting violations rather than silently repairing them.", "inputs": [ "provenance instance", "constraint set identifier and version" ], "outputs": [ "constraint check report", "validity verdict", "violated constraint references" ], "preconditions": [ "All statements carry identifiers where the constraint set requires them", "Time values are RFC 3339 with explicit offset or Z so that ordering is decidable" ], "effects": [ "Invalid instances are flagged and quarantined rather than merged into the canonical graph", "Merged statements sharing an identifier are recorded with their conflicting attributes" ], "source_refs": [ "SRC-003", "SRC-001" ] }, { "id": "traverse-lineage", "name": "Traverse lineage", "description": "Return ancestors or descendants of a subject to a bounded depth, marking truncation points, unknown-provenance nodes and per-edge assertion sources.", "inputs": [ "subject identifier", "direction", "depth and breadth limits", "relation type filter" ], "outputs": [ "lineage graph export", "completeness statement", "continuation token where truncated" ], "preconditions": [ "Traversal limits are declared before execution", "Cycle detection is enabled" ], "effects": [ "Consumers receive an explicitly bounded result rather than a silently partial one", "Truncation reasons are distinguishable from genuine absence of ancestry" ], "source_refs": [ "SRC-001", "SRC-004", "SRC-013" ] }, { "id": "resolve-provenance-record", "name": "Resolve provenance for a subject", "description": "Given only a subject, locate provenance about it through embedded records, link relations, a resolver service or soft-binding lookup, and report which mechanism succeeded.", "inputs": [ "subject or its digest or soft-binding identifier", "known resolver endpoints", "anchor qualifier" ], "outputs": [ "provenance record locator", "retrieved assertion", "resolution mechanism used" ], "preconditions": [ "At least one discovery mechanism is configured", "Anchor semantics are stated for changing resources" ], "effects": [ "Consumers can obtain provenance without prior arrangement with the producer", "Failure to resolve is reported as unknown provenance rather than as absence of provenance" ], "source_refs": [ "SRC-004", "SRC-005" ] }, { "id": "redact-provenance", "name": "Redact a provenance element", "description": "Remove or withhold a provenance element for privacy, confidentiality or legal reasons while retaining a visible placeholder and a reason, and re-evaluate what still verifies.", "inputs": [ "target element reference", "redaction reason", "authorised redactor identity", "approval reference" ], "outputs": [ "redaction log entry", "updated assertion with placeholder", "post-redaction verification grade" ], "preconditions": [ "Redactor holds the authority for the element's originating party", "Reason code is drawn from the governed reason vocabulary" ], "effects": [ "Removed content is unrecoverable from the record while the fact of removal remains visible", "Checks that depended on the removed element are reported as failed rather than skipped" ], "source_refs": [ "SRC-005", "SRC-012" ] }, { "id": "record-custody-transfer", "name": "Record a custody or ownership transfer", "description": "Append a transfer event moving custody or ownership of the subject between identified parties, with the instrument relied on and the effective time.", "inputs": [ "transferring and receiving party references", "custody type", "instrument or agreement reference", "effective transfer time" ], "outputs": [ "custody register entry", "updated custody interval sequence" ], "preconditions": [ "Prior custody interval is closed or explicitly marked as a gap", "Effective time does not precede the subject's origination without a recorded justification" ], "effects": [ "Chain of custody remains an ordered, gap-explicit series", "Ownership change is distinguishable from custody change" ], "source_refs": [ "SRC-008", "SRC-019", "SRC-014" ] }, { "id": "emit-disclosure", "name": "Emit a regulatory disclosure", "description": "Produce the machine-readable marking and human-facing notice required when the subject is artificially generated or manipulated, or when the source of personal data must be disclosed.", "inputs": [ "synthetic status or personal-data source facts", "applicable instrument reference", "audience and channel", "marking mechanism selection" ], "outputs": [ "disclosure notice", "marking assertion", "disclosure register entry" ], "preconditions": [ "Applicable jurisdiction and instrument are determined", "A marking mechanism detectable by third parties is available" ], "effects": [ "Downstream consumers can detect the disclosed status without prior arrangement", "Failure to mark is recorded as a compliance exception rather than passing silently" ], "source_refs": [ "SRC-011", "SRC-012", "SRC-005" ] }, { "id": "reconcile-conflicts", "name": "Reconcile conflicting provenance claims", "description": "Group incompatible accounts of the same subject, apply the declared precedence rule, and retain all sides with the decision and its basis.", "inputs": [ "conflicting assertion references", "precedence rule identifier", "authority ranking", "reconciling party" ], "outputs": [ "conflict register entry", "precedence decision", "unresolved-conflict flag where no rule applies" ], "preconditions": [ "Each conflicting assertion has been independently verified", "Precedence rule and authority ranking are published" ], "effects": [ "Losing accounts are retained rather than deleted", "Downstream consumers can see that a subject's provenance is disputed" ], "source_refs": [ "SRC-016", "SRC-005", "SRC-003" ] }, { "id": "apply-retention-disposition", "name": "Apply retention and disposition to provenance", "description": "Evaluate the retention period applicable to a provenance record, execute disposition when due and not suspended, and retain evidence that disposition occurred.", "inputs": [ "provenance record reference", "retention schedule or statutory period", "legal hold status", "disposition authority" ], "outputs": [ "disposition record", "tombstone entry", "updated retention state" ], "preconditions": [ "Retention authority is identified", "No legal hold is in force", "Subject-side dependencies on the record have been evaluated" ], "effects": [ "Provenance is destroyed only under a recorded authority", "A tombstone preserves the record identifier so later references resolve to an explicit deletion" ], "source_refs": [ "SRC-019", "SRC-011", "SRC-012" ] } ], "composition": [ { "target": "Agent and Party model (person, organisation, position, software agent)", "relation": "REFERENCE", "purpose": "Provenance names responsible agents and their types and roles but must not maintain its own agent registry; agent identity, deduplication and organisational hierarchy are resolved externally.", "required": true, "source_refs": [ "SRC-001", "SRC-017", "SRC-016", "SRC-010" ] }, { "target": "Event and Activity model", "relation": "COMPOSE", "purpose": "Origination, transformation, transfer, disposition and verification acts are events; the provenance mix-in composes the shared event structure and adds provenance-specific roles for used, generated and invalidated entities.", "required": true, "source_refs": [ "SRC-001", "SRC-013", "SRC-014" ] }, { "target": "Identifier and Identity Scheme model", "relation": "REFERENCE", "purpose": "Supplies the identifier tiers and resolution behaviour that the identity priority rule depends on, including external identifier retention alongside locally minted identifiers.", "required": true, "source_refs": [ "SRC-015", "SRC-007" ] }, { "target": "Temporal model (instants, intervals, calendars, offsets)", "relation": "ALIGN", "purpose": "Provenance depends on a shared time representation with explicit offsets and separable occurrence and record axes; the temporal model owns calendar and interval semantics, provenance owns which axis means what.", "required": true, "source_refs": [ "SRC-010", "SRC-014", "SRC-002" ] }, { "target": "Place and Jurisdiction model", "relation": "REFERENCE", "purpose": "Activity location, read point, business location and governing jurisdiction are resolved against an external gazetteer and legal-order registry rather than defined here.", "required": false, "source_refs": [ "SRC-002", "SRC-014", "SRC-011" ] }, { "target": "Rights and Licensing model", "relation": "REFERENCE", "purpose": "Provenance records custody and ownership changes and points at rights statements and licences; the terms, permissions and obligations themselves are owned by the rights model.", "required": false, "source_refs": [ "SRC-008", "SRC-017" ] }, { "target": "Trust, Keys and Credentials model", "relation": "REFERENCE", "purpose": "Signer credentials, trust lists, revocation status and time authorities are external objects whose lifecycle provenance consumes but does not govern.", "required": true, "source_refs": [ "SRC-005", "SRC-006" ] }, { "target": "Records Retention and Disposition model", "relation": "REFERENCE", "purpose": "Retention schedules, disposition authorities and legal holds are defined externally; provenance cites the schedule and records the disposition event and its evidence.", "required": true, "source_refs": [ "SRC-019", "SRC-011" ] }, { "target": "Access and Authorization model", "relation": "REFERENCE", "purpose": "Visibility classes and audience views on provenance are enforced by the access model; provenance records the decision as evidence and does not implement policy.", "required": true, "source_refs": [ "SRC-004", "SRC-012" ] }, { "target": "Data Quality and Assessment model", "relation": "EXTEND", "purpose": "Quality assessment consumes provenance as evidence and, being itself an activity, generates provenance; the two models extend each other without either owning the other's vocabulary.", "required": false, "source_refs": [ "SRC-018", "SRC-013" ] }, { "target": "Content Asset and Dataset models (host subjects)", "relation": "MIX-IN", "purpose": "This model is applied to host entity models as a dimension; the host supplies the subject, its identifier stability and its version boundaries, and accepts the provenance application profile.", "required": true, "source_refs": [ "SRC-015", "SRC-009", "SRC-018" ] }, { "target": "W3C PROV family (PROV-DM, PROV-O, PROV-CONSTRAINTS, PROV-AQ)", "relation": "ALIGN", "purpose": "Primary external alignment for entity/activity/agent structure, qualified influence, validity constraints and discovery; alignment is recorded in the crosswalk and no conformance is claimed without validation evidence.", "required": false, "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-004" ] }, { "target": "PREMIS Data Dictionary and archival description (RiC-CM)", "relation": "ALIGN", "purpose": "Alignment for preservation events, object granularity, fixity and for the creator/custody sense of provenance; the homonym between archival provenance and derivation lineage is recorded as a mapping caution.", "required": false, "source_refs": [ "SRC-017", "SRC-016" ] }, { "target": "Content authenticity and software supply-chain attestation (C2PA, in-toto/SLSA, SPDX)", "relation": "ALIGN", "purpose": "Alignment for signed transport, subject binding by digest, build provenance predicates and element-level creation information; these are evidence carriers, not replacements for the semantic model.", "required": false, "source_refs": [ "SRC-005", "SRC-006", "SRC-007", "SRC-015" ] }, { "target": "Traceability event exchange (GS1 EPCIS) and geospatial lineage (ISO 19115 MRL)", "relation": "ALIGN", "purpose": "Domain projections that supply authoritative origination, transfer and process-step facts; their business-step, disposition and geospatial vocabularies remain with those siblings.", "required": false, "source_refs": [ "SRC-014", "SRC-013" ] }, { "target": "Clinical provenance and audit (HL7 FHIR Provenance and AuditEvent)", "relation": "ALIGN", "purpose": "Alignment for the occurred-versus-recorded distinction, entity roles and the generation-versus-usage boundary that separates provenance from audit logging.", "required": false, "source_refs": [ "SRC-010" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "The adopting Dimension must designate a named owner accountable for the provenance application profile, the governed relation and reason vocabularies, and the crosswalk table, with a published contact and dispute channel.", "The owner must publish the identifier minting authority, the trust list or trust anchors relied on, the constraint set version used for validity checking, and the retention authority applicable to provenance records, before any assertion is issued in production.", "The owner must maintain a review cadence for external vocabulary version drift and for trust-list changes, and must record every profile change as a versioned, superseding profile rather than an in-place edit.", "The owner must declare which host models the mix-in is applied to and which provenance elements become mandatory for each, so that consumers can distinguish a genuinely absent fact from an element the profile never required." ], "namespace_guidance": "Local element identifiers are lower-kebab-case and stable for the life of the model; they are minted under a Dimension-controlled namespace and never reused after retirement. External vocabulary terms are referenced by their governed IRIs at a pinned version and are never redefined locally. Where a local element aligns with an external term, both identifiers are retained side by side in the crosswalk with an explicit mapping relation, so that a reference can always be traced to the authority that governs it.", "registry_links": [ "Registry entry vr.wm-xct-012 (WM-XCT-012, Provenance), nav path NAV.XCT.PROV, entry kind mixin, status candidate.", "Governed relation-type vocabulary and reason-code vocabulary maintained by the adopting Dimension and versioned alongside the application profile.", "Crosswalk table binding local elements to PROV, PREMIS, C2PA, EPCIS, ISO 19115 lineage, FHIR Provenance, SPDX and in-toto/SLSA terms at pinned versions." ] }, "canon_and_patch": { "canonicalization_rules": [ "A canonical form must be defined and reproducible before any assertion is signed; the canonicalisation rule identifier and version are recorded in the envelope so that a verifier can reconstruct the signed bytes without the original transport.", "Time values are canonicalised to RFC 3339 with seconds and an explicit offset or Z; when a value is normalised to UTC, the local zone offset in effect at the place of the event is retained as a separate element rather than discarded.", "Identifiers are canonicalised by scheme, not by string case folding alone; an external identifier is retained verbatim as received alongside any normalised local form.", "Absent elements are canonicalised as absent, never as empty strings or zero values, so that unknown, not-applicable and withheld remain distinguishable through their explicit markers." ], "patch_rules": [ "Provenance assertions are append-only: a correction is expressed as a superseding assertion referencing the prior one, never as an in-place edit of signed content.", "A patch that would change the meaning of a signed statement invalidates the signature and must be re-sealed; the superseded envelope is retained with its original verification history.", "Redaction is the only sanctioned removal operation and must leave a visible placeholder, a reason code and the identity of the redacting party.", "Merges of statements sharing an identifier record conflicting attributes rather than silently preferring one; unresolved merges are quarantined and reported." ], "compatibility_rules": [ "Adding an optional element or a new relation type is a minor change; making an element mandatory, narrowing a cardinality, changing an element's meaning or retiring a relation type is a breaking change requiring a new profile major version.", "Consumers must ignore unknown elements rather than reject the assertion, so that producers on a newer profile remain interoperable with older consumers.", "Mappings to an external vocabulary are pinned to a target version; a new target version creates a new mapping row rather than replacing the existing one.", "No conformance to an external standard is asserted in an exchanged record unless a validation evidence reference accompanies the claim." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier issued by the system of record for the subject or the event, retained with its issuing authority.", "Governed global identifier or IRI from a recognised scheme where no master-system identifier exists.", "UUID (time-ordered, such as UUIDv7) or ULID minted by the adopting Dimension, recorded together with the minting authority and minting time.", "Content digest may serve as a matching key for immutable artifacts but is a binding, not an identity, and never replaces an assigned identifier for mutable or versioned subjects.", "A date, a filename, a path, a display label or a sequence position is never used as an identifier." ], "timestamp_rule": "All time values are recorded in RFC 3339 format with seconds precision and an explicit UTC offset or Z. Occurrence time and record/observation time are stored in separate named elements and are never conflated; where an event occurred in a local zone, the zone offset in effect at that time and place is retained separately from any UTC-normalised value. Claimed precision is recorded whenever it is coarser than the field allows.", "serial_naming_rule": "Serial artifacts (event records, custody register entries, fixity and verification reports, redaction and disposition logs) are named by the artifact class plus the subject or assertion identifier plus a monotonic sequence number, with the RFC 3339 recorded instant carried as data rather than embedded in the name. Ordering within a series is by occurrence time with recorded time as tiebreaker and the sequence number as final tiebreaker; sequence numbers are never reused after a gap and gaps are recorded explicitly.", "integrity_rule": "Every artifact that leaves the producing system carries at least one digest over a defined extent with a named algorithm, and where the artifact is authoritative it carries a signature bound to a signer identity plus, where available, a trusted time-stamp. Digests are retained after algorithm deprecation alongside replacements. A fixity or signature failure produces a new dated report and an integrity exception; it never overwrites the recorded expected value, and it never silently downgrades a previously recorded verification verdict." }, "policies": [ "Provenance is append-only and evidence-preserving: no operation may make a previously recorded fact, verdict or conflict disappear without leaving a superseding record that states what changed, when, by whom and why.", "Absence is never evidence: an unknown, not-applicable or withheld provenance fact must be marked explicitly, and a consumer must not infer that unmarked absence means the fact does not exist.", "No conformance claim without evidence: external standards are recorded as alignments in the crosswalk, and any statement of conformance must reference validation evidence and its scope.", "Signed content is immutable: corrections are issued as superseding assertions, and any change to signed bytes requires re-sealing with the superseded envelope and its verification history retained.", "Provenance records are governed as records in their own right, with their own retention authority, legal-hold handling and disposition evidence, which may differ from the subject's.", "Personal data appearing in provenance is minimised to what is necessary for accountability, with position or role identifiers preferred over named individuals where that preserves the accountability chain.", "Do not infer that a valid, well-formed or signed provenance record means the subject is authentic, lawful, unbiased or good.", "Honor creator control and privacy: omit or redact personal provenance fields when the creator withheld them, and do not reconstruct withheld identity from side channels.", "When multiple providers supply contradictory records, keep all records, attribute each to its provider, and apply an explicit selection policy rather than overwriting.", "Deletion of a subject does not imply deletion of its provenance when OAIS or legal-hold policy requires keeping history of destruction; record invalidation as an event." ], "crud": { "read": [ "Retrieve a provenance assertion by its identifier, or resolve provenance for a subject through embedded records, link relations, a resolver service or soft-binding lookup.", "Traverse ancestors or descendants of a subject to a declared depth, receiving explicit truncation markers, unknown-provenance markers and per-edge assertion sources.", "Retrieve verification, fixity, trust-evaluation, custody, redaction and disposition series for a subject, filtered by time window and by outcome.", "Retrieve the applicable application profile and crosswalk so that a consumer can tell which elements were required and how they map to external vocabularies." ], "create": [ "Anchor a provenance assertion to identified subjects and append origination, transformation, transfer, disposition and verification events.", "Assert typed derivation relations between entities, qualified by activity, role and times.", "Seal an assertion into a signed envelope with a typed payload and attach a trusted time-stamp.", "Register a conflict set when incompatible accounts of the same subject are received." ], "update": [ "Issue a superseding assertion that corrects, extends or retracts an earlier one, with an explicit supersedes reference and a reason.", "Append a new verification, trust-evaluation or fixity outcome without altering earlier outcomes.", "Append an error declaration retracting a published statement the producer now knows to be wrong.", "Record a precedence decision over a conflict set while retaining all sides of the conflict." ], "delete": [ "Redact a specified provenance element under an authorised reason, leaving a placeholder, the reason code and the redacting party visible.", "Execute disposition of a provenance record under a cited retention authority when no legal hold is in force, writing a disposition record and a tombstone that retains the record identifier.", "Refuse deletion requests that would remove the evidence of a prior deletion, a verification failure or an unresolved conflict.", "Propagate an erasure obligation to registered recipients where the law requires communication of erasure, recording the per-recipient notification status." ] }, "roles": [ { "name": "Provenance model owner", "responsibilities": [ "Maintain the application profile, governed vocabularies and crosswalk, and version them on change.", "Publish the identifier minting authority, constraint set version, trust anchors and retention authority in force.", "Adjudicate boundary disputes with sibling models and record the outcome as a boundary note." ] }, { "name": "Asserting producer", "responsibilities": [ "Anchor assertions correctly and record occurrence and record times separately with explicit offsets.", "Separate statements it originates from statements it merely gathered, and seal assertions with a valid credential.", "Issue superseding assertions and error declarations promptly when a published statement is found to be wrong." ] }, { "name": "Verifier", "responsibilities": [ "Check structural well-formedness, cryptographic validity, trust status and instance constraints, and publish graded outcomes with per-check status codes.", "Re-evaluate assertions when trust lists, credential status or constraint sets change, retaining earlier verdicts.", "Report unknown signers and partial failures explicitly instead of collapsing them into a pass or fail." ] }, { "name": "Custodian", "responsibilities": [ "Maintain the chain-of-custody register as an ordered, gap-explicit series and record transfers with their instruments and effective times.", "Run fixity checks on the declared cadence and escalate mismatches as integrity exceptions.", "Preserve provenance across storage migrations and re-anchor subjects when formats change." ] }, { "name": "Privacy and disclosure officer", "responsibilities": [ "Approve redactions and audience views, and ensure personal data in provenance is necessary and minimised.", "Ensure synthetic-content marking, deepfake disclosure and personal-data source disclosure duties are discharged and evidenced.", "Maintain the disclosure and recipient register so that rectification and erasure can be communicated downstream." ] }, { "name": "Records and retention authority", "responsibilities": [ "Assign the retention period and disposition authority for provenance records independently of the subject.", "Impose and lift legal holds and record who did so and on what basis.", "Ensure disposition produces a retained disposition record and a tombstone rather than a silent absence." ] } ], "access": { "default_rule": "Provenance is readable by any party authorised to hold the subject, at the least revealing view that still supports verification: subject anchor, binding method, verification grade, origination type, responsible organisation and time axes are exposed by default, while named natural persons, internal parameters, precise locations, credential internals and commercially sensitive process detail are withheld unless a broader view is granted. Write access is restricted to the asserting producer for its own statements; no party may silently alter or delete another party's statements.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Regulators, auditors and courts may be granted a full view including withheld elements, under a recorded authorisation with its legal basis and time bounds.", "A data subject exercising a source-disclosure right receives the source information about their own personal data even where that element is otherwise withheld.", "Emergency integrity investigation may grant time-boxed elevated read across custody, fixity and verification series, with the elevation itself recorded as a provenance event.", "Downstream consumers receive a redacted view in which removed elements appear as placeholders with reason codes, never as silent absences.", "Where an upstream producer's statement is redacted downstream, the upstream producer retains the right to see that a redaction occurred and on what basis.", "Public C2PA or SLSA attestations intended for consumers MAY be world-readable.", "Legal process and preservation audit MAY override default deny on archived records.", "Pingback POST is write-limited to appending provenance-URIs, not editing the original record." ], "audit_requirements": [ "Every read of a full or elevated view is recorded with the requesting identity, the authorisation relied on, the scope granted and the RFC 3339 instant, and that record is retained under the provenance retention authority.", "Every write, supersession, redaction and disposition is recorded with actor, reason, authorisation reference and both occurrence and recorded times.", "Verification and trust-evaluation runs are recorded as immutable dated reports, including runs that fail or are inconclusive.", "Access records are themselves provenance records and are subject to the same append-only, tombstone-on-deletion rules as the assertions they describe.", "Log create, verify, redact, custody-transfer, pingback and delete with actor, record_id, event_time and ingested_at.", "Retain validation reports for as long as the attestation they describe.", "Do not log withheld personal fields that were never stored." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Owner and contact", "Profile version and constraint set version", "Identifier minting authority", "Trust anchors or trust list in force", "Retention authority for provenance records", "Known alignments and non-conformance disclaimer" ], "read_order": [ "AGENTS.md — establishes name, type, and the specification, storage, interface and process URLs before any operation is attempted, including when the store is MongoDB or the interface is MCP.", "Specification URL — the format-neutral semantics: scope, boundaries, bundles, layers, findings and required elements.", "Storage type URL — how those semantics are projected onto the concrete store, including canonical form, append-only enforcement and tombstone behaviour.", "Interface URL — the operations exposed, their parameters, traversal limits and error and status codes.", "Processes URL — the operating procedures for sealing, verification cadence, redaction approval, conflict reconciliation and disposition.", "Application profile and crosswalk — which elements are mandatory for the host model in this Dimension and how they map to external vocabularies at pinned versions." ] } }, "coverage": { "claim": "Dual-provider research synthesis for a format-independent Provenance mixin. The accepted structure covers subject anchoring, provenance record identity, origin and derivation, agents and activities, custody, temporal and spatial context, fixity, attestation, verification, disclosure, access, retention and vocabulary alignment. It is a public research draft, not a claim that every sector-specific provenance profile is complete.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Subject anchoring, provenance assertion identity and agent identity are separated, with a five-tier identity priority that puts master-system identifiers first, then governed IRIs, then minted UUID/ULID, and explicitly bars dates, filenames and labels. Digest is treated as a binding rather than an identity, following in-toto's digest-only subject matching and SPDX's required spdxId (SRC-007, SRC-015)." }, { "dimension": "lifecycle", "status": "covered", "notes": "Origination, transformation, invalidation, custody transfer, supersession, redaction and disposition are all modelled as events with their own records; C2PA update manifests and PREMIS events support supersession over mutation, and NARA disposition supports the tombstone rule (SRC-005, SRC-017, SRC-019)." }, { "dimension": "relationships", "status": "covered", "notes": "Typed derivation, revision, quotation, primary source, ingredient, membership and transformation relations are drawn from PROV, FHIR entity roles, dcterms and EPCIS transformation events, with qualification through activity, role and time and an explicit fallback to generic influence when the specific type is unknown (SRC-001, SRC-010, SRC-008, SRC-014)." }, { "dimension": "temporal", "status": "covered", "notes": "Occurrence and record time are separate mandatory-capable axes; RFC 3339 with explicit offset or Z is required; local zone offset survives UTC normalisation per EPCIS; ordering and validity follow PROV-CONSTRAINTS; trusted time-stamping is separated from self-declared clocks (SRC-010, SRC-014, SRC-003, SRC-005)." }, { "dimension": "provenance", "status": "covered", "notes": "Provenance-of-provenance is modelled through bundles as entities, per-statement source references on merge, statement basis codes distinguishing recorded from inferred, and asserting-agent identity separate from the agents named inside an assertion (SRC-001, SRC-004)." }, { "dimension": "ownership", "status": "covered", "notes": "Ownership is separated from custody following the dcterms:provenance definition; the custody register records holders, intervals, gaps and transfer instruments, and delegation records where responsibility rests above the acting agent (SRC-008, SRC-001, SRC-019, SRC-016)." }, { "dimension": "validation", "status": "covered", "notes": "Three graded verification levels with per-check status codes, PROV-CONSTRAINTS instance validity, fixity re-checks, error declarations and re-verification triggers on trust-list or credential-status change; validators are identified and versioned in every report (SRC-005, SRC-003, SRC-014)." }, { "dimension": "access", "status": "covered", "notes": "Default least-revealing view with named exceptions for regulators, data subjects and integrity investigations; four scopes at bundle, layer, finding and artifact level; discovery is interface-neutral via embedded records, link relations, resolver services or soft-binding lookup (SRC-004, SRC-005, SRC-012)." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Provenance retention is governed independently of the subject, with statutory minimums (AI Act log retention), storage limitation for personal data, legal holds, disposition evidence and tombstones that retain the identifier so deletion is explicit rather than silent (SRC-011, SRC-012, SRC-019)." }, { "dimension": "interoperability", "status": "covered", "notes": "A maintained crosswalk pins mappings to PROV, PREMIS, C2PA, EPCIS, ISO 19115 lineage, FHIR, SPDX and in-toto/SLSA at target versions, with mapping relation and round-trip loss recorded, and an explicit rule against unevidenced conformance claims (SRC-001, SRC-017, SRC-005, SRC-013, SRC-014, SRC-010, SRC-015, SRC-007)." }, { "dimension": "security", "status": "covered", "notes": "Signed envelopes with canonicalisation, signer identity separate from claim generator, trust anchors, credential status and revocation, and verdict-history retention so that a trust downgrade never erases the earlier verdict (SRC-005, SRC-007, SRC-006)." }, { "dimension": "privacy", "status": "covered", "notes": "Provenance is treated as potentially containing personal data; minimisation prefers positions to named individuals, redaction leaves visible placeholders, and GDPR source-disclosure, recipient-notification and records-of-processing duties are modelled as findings rather than assumed away (SRC-012, SRC-005)." }, { "dimension": "evidence and integrity", "status": "covered", "notes": "Fixity digests with originator and check history, algorithm agility, hard versus soft bindings with an explicit statement of what each proves, and the rule that a mismatch never overwrites the recorded expected value (SRC-017, SRC-015, SRC-005)." }, { "dimension": "spatial", "status": "covered", "notes": "Activity location, logical location where physical place is meaningless, and governing versus storage jurisdiction are modelled, but deliberately delegated to sibling place and jurisdiction models rather than defining a gazetteer (SRC-002, SRC-014, SRC-011)." }, { "dimension": "measurement", "status": "covered", "notes": "Timestamp precision and uncertainty, confidence values on a named and versioned scale, and soft-binding tolerance thresholds are captured; the model deliberately does not define a universal confidence scale, treating cross-producer comparability as an open question (SRC-018, SRC-005)." }, { "dimension": "exception handling", "status": "covered", "notes": "Unknown provenance, truncation, partial verification failure, unknown signers, error declarations, unresolved conflicts, custody gaps and legal holds each have explicit representations, so degraded states are reportable rather than silent (SRC-005, SRC-014, SRC-016, SRC-019)." }, { "dimension": "authority", "status": "covered", "notes": "Plans, mandates, policies and purpose of use are separated from the activity itself; precedence rules and authority rankings govern conflict reconciliation; profile ownership and vocabulary governance are assigned in the service layers (SRC-010, SRC-016, SRC-011)." }, { "dimension": "classification", "status": "gap", "notes": "The model requires governed vocabularies for relation types, origination types, reason codes and agent roles but does not supply them. The candidate sources use incompatible code lists (PREMIS event types, EPCIS business steps, C2PA action labels, FHIR entity roles), and choosing among them without a stated adoption decision would present unsupported structure as canonical." } ], "known_omissions": [ "Ledger- or blockchain-anchored provenance registries and their consensus, immutability and cross-organisation notarisation properties are not modelled; anchoring is treated as a projection, but a sibling model is likely needed and no source was consulted for it.", "Cultural-heritage ownership provenance in the art-historical sense (exhibition history, sale records, restitution claims, CIDOC CRM alignment) was not researched and is not covered beyond generic custody intervals.", "Machine-learning-specific lineage artefacts such as model cards, datasheets for datasets, feature lineage and evaluation provenance are only partially reached through the training-summary and generating-model elements.", "Sensor and observation provenance beyond EPCIS sensor elements — for example W3C SSN/SOSA observation procedures and sensor calibration lineage — was not researched.", "Nanopublication and scholarly citation provenance, including retraction propagation across the citation graph, is not covered.", "The PREMIS Data Dictionary v3.0 full text could not be retrieved directly: the host returned HTTP 403 to the research agent. Version, date and the five-entity model were confirmed from Library of Congress index pages, but no element-level quotation from the document underpins any node here.", "The OAIS Reference Model (CCSDS 650.0-M-2 / ISO 14721) could not be retrieved live (HTTP 403), so its treatment of Provenance Information as a component of Preservation Description Information is deliberately not cited or relied on, despite being directly on point.", "NIST AI 100-4 on reducing risks from synthetic content could not be parsed from its published PDF, so watermark robustness and detection limitations are represented only through C2PA's soft-binding treatment and the AI Act's detectability requirement.", "No cost, performance or scale characteristics of lineage traversal at large graph sizes are modelled beyond declared limits; practical query economics are left to the interface projection.", "Provenance for streaming, continuously updated and derived-on-read resources is only partially addressed through the anchor qualifier; sub-second and per-record streaming lineage was not researched.", "Forensic laboratory chain-of-custody procedures (for example ASTM E1492 or SWGDE) lack a primary source adopted in this pass and remain a sibling gap.", "ISO 23494 biotechnology provenance and related lab-sample standards were not grounded in a retrieved primary text.", "ML training-data lineage, model-card provenance and dataset-licence enforcement have no single primary standard equivalent to PROV or C2PA; C2PA AI disclosure is only an alignment.", "Quantum-safe signature migration for long-term archives is unspecified by the cited primary sources.", "1970 UNESCO cultural-property export rules and national patrimony statutes are legal overlays, not technical provenance types.", "Live multi-hop reconstruction of implicit PROV blank nodes from sparse Dublin Core records is an implementation strategy, not a required Dimension behaviour.", "Region-specific eIDAS or national trust-list programmes beyond the C2PA Trust List are not enumerated." ], "conflicts": [ "The word 'provenance' is a homonym across the cited authorities. In DCMI it is a statement about changes of ownership and custody; in archival practice (RiC-CM) it centres on the creator and the accumulating body; in PROV and ISO lineage it is the derivation and process graph. This model keeps all three but separates them into custody, origination agent and derivation graph, and flags the mapping caution in the crosswalk.", "PROV permits an entity with no generation activity and identifies entities by IRI, whereas in-toto and SLSA identify subjects purely by digest and require one. A record that is valid under PROV can be unusable in an attestation pipeline and vice versa; the model therefore separates identity from binding rather than treating a digest as an identifier.", "Time normalisation conflicts: SLSA mandates UTC 'Z' timestamps, EPCIS requires a separate eventTimeZoneOffset alongside a UTC eventTime, and PROV/xsd:dateTime permits inline offsets. Normalising everything to UTC loses the local-time meaning EPCIS deliberately preserves, so this model requires both a normalised value and a retained local offset.", "Provenance versus audit scope conflicts: FHIR places usage and read events in AuditEvent while PREMIS treats many usage and management acts as preservation Events. A record that a system considers provenance in one regime is an audit record in the other, and merging them inflates provenance graphs with access traffic.", "ISO 19115 lineage permits a free-text lineage statement alongside structured process steps; the two can contradict each other and no source specifies which prevails. The model records the statement as text and requires structured steps to be treated as authoritative where both exist, which is an adopting-Dimension decision rather than a sourced rule.", "C2PA's training and data-mining assertion was removed from the core specification in version 2.0, while the AI Act requires machine-readable marking of AI-generated content and a training-content summary. No single cited assertion type discharges the legal obligation, so the model treats marking mechanism and training summary as separate elements and does not claim that any one manifest satisfies the regulation.", "dcterms:provenance is a human-readable ProvenanceStatement while PROV, PREMIS and EPCIS require structured events. Round-tripping through Dublin Core loses the graph, so the crosswalk records this as a lossy mapping rather than an equivalence.", "C2PA and SLSA both move quickly (C2PA 2.4 supersedes 2.2; SLSA v1.1 is marked retired in favour of v1.2). Version pinning in the crosswalk is therefore mandatory, and any node resting on a single fast-moving specification should be re-checked at each review cycle.", "ISO 19115-1:2014 defines provenance, citing ISO 5127, as the organization or individual that created, accumulated, maintained and used records, and defines lineage as provenance plus sources and production processes. W3C PROV uses provenance for the latter graph. Alignment must keep both senses labelled.", "Dublin Core dct:provenance is a narrative custody and ownership statement; PROV is a graph. PROV-DC maps the property to prov:has_provenance, not to wasAttributedTo.", "CIDOC separates legal title from physical custody; Dublin Core and many supply-chain practices lump them. Collapsing them is a Dimension choice, not conformance.", "C2PA refuses value judgements of good or bad; SLSA Build levels are assurance grades of production integrity. Do not equate a trusted C2PA manifest with SLSA Build L3.", "PROV unique-generation forbids two generations of one entity in a valid instance; Dublin Core created plus issued on one resource is common and is valid PROV only if modelled as specializations.", "C2PA v2 removed identified humans from assertions for privacy; PREMIS and PROV still treat Person agents as first-class. Sharing profiles must not re-identify withheld actors.", "ISO 14721:2025 allows information packages where PDI is optional (ingest first, describe later); OAIS users of earlier editions expected Provenance Information as part of PDI.", "in-toto and SLSA treat the builder as a trust boundary that must not be tenant-controlled for authenticity; PROV allows any agent to assert provenance, with trust decided separately." ], "regional_assumptions": [ "The disclosure duties modelled here are EU-specific: Regulation (EU) 2024/1689 for synthetic-content marking, deepfake disclosure, high-risk logging and training-content summaries, and Regulation (EU) 2016/679 for source-of-personal-data disclosure, recipient notification and storage limitation. Equivalent or conflicting obligations in the United States, United Kingdom, China, India and elsewhere were not researched and must be added by the adopting Dimension.", "NARA's Universal ERM Requirements are United States federal-government requirements; their capture, transfer and disposition expectations are used here as an authoritative pattern, not as a globally applicable rule.", "GS1 EPCIS is voluntary in most markets but is relied on by sector-specific regimes (for example US food traceability); the model treats it as an alignment, not a mandate.", "The legal weight of digital signatures and trusted time-stamps varies by jurisdiction (for example eIDAS in the EU versus other electronic-signature regimes); the model records signature and time-stamp evidence without asserting its legal effect anywhere.", "Time representation assumes RFC 3339 and the proleptic Gregorian calendar; non-Gregorian calendar systems, historical calendar changes and uncertain or fuzzy historical dating (common in archival provenance) are not represented.", "Language and script of names, place names and free-text statements are not modelled; multilingual provenance statements and transliteration provenance are left to the adopting Dimension.", "RFC 3339 timestamps with explicit offsets are required even where local archives store civil dates only.", "C2PA Trust List and X.509-only signing reflect a primarily industry PKI practice; other regions may require eIDAS or national PKI profiles as additional acceptance policy.", "CIDOC title versus custody is expressed for museum practice and may not match common-law versus civil-law transfer of stolen goods; legal title outcome is out of scope.", "EPCIS adoption in pharmaceutical traceability (for example DSCSA in the United States) is a jurisdictional overlay on the same event model, not a separate provenance type.", "English is the normative language of the cited W3C Recommendations; translations are non-normative." ], "adversarial_checks": [ "Attempted to justify a separate 'trust score' bundle and rejected it: no cited source defines a comparable cross-producer trust metric. C2PA grades verification (well-formed, valid, trusted) but that is an outcome of defined checks, not a score, so confidence remains a per-statement, scale-declared element and comparability is recorded as an open question.", "Tested whether 'provenance' could simply be the audit log, using FHIR's own boundary text as the counterexample: AuditEvent covers usage and access while Provenance covers generation. Collapsing them would import every read event into the lineage graph, so the boundary is stated explicitly rather than assumed.", "Tested whether digest could serve as identity, using in-toto's digest-only subject matching as the apparent supporting case. Rejected for mutable and versioned subjects, because two byte-identical renderings of different works would collide and any re-encoding would destroy identity; digest is therefore modelled as a binding under the identity priority rule.", "Searched for a counterexample to the mandatory-record-time rule and found the opposite: EPCIS makes recordTime optional while FHIR makes recorded optional too. The model nevertheless requires a record time on the assertion because without it supersession ordering is undecidable — this is recorded as a model-specific strengthening beyond the sources, not as a sourced requirement.", "Considered making a signature mandatory on every assertion and rejected it: PREMIS, ISO lineage, dcterms and RO-Crate all describe unsigned provenance that is nonetheless authoritative within its custodial context. Signature is therefore modelled as evidence strength, and unsigned provenance is representable with a correspondingly lower verification grade.", "Probed whether soft bindings (watermarks, fingerprints) could be presented as integrity evidence. They cannot: C2PA scopes them to matching across renditions, not to tamper detection, so the model forces an explicit statement of what each binding actually proves and separates hard from soft bindings.", "Checked whether redaction can be modelled as deletion. It cannot without breaking verification, since C2PA retains a labelled placeholder and lists redacted references in the claim; the model therefore forbids silent removal and requires a visible placeholder plus an explicit statement of which checks the redaction invalidates.", "Stress-tested the mix-in framing against SPDX, where provenance-like properties sit on the base Element class, and against C2PA, where provenance is a separate signed manifest. Both patterns are supported through the declared attachment-pattern element rather than privileging either, because privileging one would bind the model to a storage projection.", "Looked for authority to publish a canonical relation-type and reason-code vocabulary and found only mutually incompatible domain lists across PREMIS, EPCIS, C2PA and FHIR. Rather than invent a union list, classification is marked as a gap in the checklist and the vocabularies are assigned to the adopting Dimension with a governance requirement.", "Would treating this mixin as an entity rather than a mixin duplicate Artifact, Event or Agent models? Mitigated by MIX-IN composition and explicit out-of-scope list.", "Would claiming ISO 19115 or C2PA conformance without constraint or trust-list evidence be a false conformance claim? Mitigated by ALIGN not EXTEND and by recording conflicts.", "Would a date-stamped filename be used as a provenance identifier? Forbidden by identity priority and timestamp rule.", "Would a valid signature be presented as proof that media is true? Forbidden by C2PA non-goals and policy text.", "Would withheld personal actor data be reconstructed from EXIF or logs? Forbidden by privacy policy and C2PA v2 removal of identified humans from assertions.", "Would tenant-generated SLSA fields be treated as control-plane authentic? Explicit tenant-generated field question and builder trust boundary.", "Would deletion of an object erase evidence of its destruction? Invalidation and retention policy require a recorded event when archive policy applies." ] }, "researchAdjudication": { "providerMode": "dual-provider", "activeProviders": [ "claude", "grok" ], "waivedProviders": [], "providerPolicy": {}, "boundaryDecision": { "entry_kind": "mixin", "status": "accepted", "rationale": "Both independent providers classify provenance as reusable context attached to a host subject or assertion record. The host object, identifier scheme, place, access policy, credential and storage representation remain separate models or referenced services." }, "decisions": [ { "concept": "Provenance is a reusable mixin, not the host object", "disposition": "accepted-from-both", "rationale": "Both providers preserve the identity and lifecycle of the host subject while attaching provenance assertions and relationships." }, { "concept": "W3C PROV entity-activity-agent graph", "disposition": "accepted-and-distributed", "rationale": "The semantics are accepted, but separate generic class-definition findings are not duplicated because the base structure already covers entity anchoring, activities, agents, attribution and derivation at their governed boundaries." }, { "concept": "Specialization, alternate and fixed-aspect identity", "disposition": "accepted-from-claude", "rationale": "The base Subject granularity and fixed aspects finding asks the same identity questions while keeping them tied to the provenance subject anchor." }, { "concept": "Generation, usage, communication, start, end and invalidation", "disposition": "accepted-from-grok", "rationale": "These event types and their validity constraints sharpen the base relation and activity coverage without changing the boundary." }, { "concept": "Ingredients and build inputs", "disposition": "accepted-from-claude", "rationale": "The base Primary sources and ingredients plus Activity and process step findings already cover resolved dependencies, digests, parameters, inputs, outputs and reproducibility." }, { "concept": "Claim generator, signer and builder trust", "disposition": "accepted-from-grok", "rationale": "The distinction is material for C2PA, in-toto and SLSA evidence and complements the generic signed-attestation envelope." }, { "concept": "Discovery, query and pingback", "disposition": "accepted-from-claude", "rationale": "The base Provenance discovery and access finding already covers subject-based discovery, traversal, pingback, downstream notification and availability." }, { "concept": "Structural validity means truth or trust", "disposition": "rejected", "rationale": "Both passes distinguish syntax and PROV constraints from integrity verification, signer trust, confidence and the truth of the represented claim." }, { "concept": "Legal title, physical custody, attribution and responsibility are interchangeable", "disposition": "rejected", "rationale": "They are separate relations with different authorities, evidence and lifecycle events." } ], "publicationHolds": [ "Verify live availability, version pins and exact claim support for every source accepted into the synthesis.", "Create and test sector profiles for archival records, geospatial data, clinical records, software supply chains and media authenticity before promoting a universal completeness claim." ], "deferredResearch": [ "Clause-level alignment to paywalled ISO 19115-1 and ISO 8000 provenance and data-quality requirements.", "Jurisdiction-specific evidentiary admissibility, chain-of-custody and records-retention profiles.", "Fine-grained privacy-preserving provenance, zero-knowledge disclosure and confidential-computing attestations.", "Operational federation, provenance query and pingback abuse controls across mutually untrusted providers.", "Domain-specific provenance profiles for science workflows, healthcare, cultural heritage, geospatial data and AI training corpora." ] }, "statistics": { "sources": 28, "bundles": 6, "layers": 14, "findings": 33, "questions": 123, "artifacts": 28, "functions": 14 } }