W3C PROV Standard

PROV structures provenance around three fundamental types and their relationships:

• Entity: A physical, digital, conceptual, or other kind of thing with some fixed aspects. Entities may be real or imaginary.
• Activity: Something that occurs over a period of time and acts upon or with entities. It may include consuming, processing, transforming, modifying, relocating, using, or generating entities.
• Agent: Something that bears some form of responsibility for an activity taking place, for the existence of an entity, or for another agent's activity.

The relationships between these types—such as wasGeneratedBy, used, wasAttributedTo, and wasDerivedFrom—form a directed graph that captures the complete history of an asset.

PROV-O provides a formal OWL2 ontology that maps the PROV data model to RDF, enabling semantic web integration:

• Defines classes (prov:Entity, prov:Activity, prov:Agent) and properties (prov:wasGeneratedBy, prov:used, prov:wasAttributedTo)
• Enables RDF serialization of provenance records, making them queryable via SPARQL
• Supports inference and reasoning over provenance graphs to derive implicit relationships
• Provides a machine-readable vocabulary that allows different systems to exchange provenance data with unambiguous semantics
• Forms the foundation for linked data provenance, where provenance of one resource can link to provenance of another across the web

PROV-N is a textual notation designed for human readability while maintaining full alignment with the PROV data model:

• Uses a functional-style syntax that directly mirrors the abstract model's structure
• Example: entity(e1, [prov:type="document"]) and wasGeneratedBy(e1, a1, 2024-01-15T10:30:00Z)
• Serves as a pedagogical tool for learning the model and a debugging format for developers
• Provides a canonical representation that can be used in specifications, examples, and test cases
• All PROV-N expressions have a direct mapping to PROV-O RDF, ensuring no loss of fidelity when converting between formats

The standard defines multiple serialization formats to accommodate different technology stacks:

• PROV-XML: An XML schema for representing provenance, suitable for enterprise systems and SOAP-based architectures. Uses a namespace-qualified element structure that validates against a defined XSD.
• PROV-JSON: A JSON representation designed for web applications and RESTful APIs. Uses a simplified key-value structure with prefix:localName conventions for qualified names.
• Both serializations are lossless mappings of the abstract model, ensuring round-trip conversion is possible
• The availability of multiple formats enables interoperability across heterogeneous systems without forcing a single representation

PROV introduces the concept of bundles, which are named collections of provenance statements that can themselves be the subject of provenance:

• A bundle is a named set of provenance descriptions that can be attributed to an agent or associated with an activity
• Enables provenance of provenance: you can assert who created a particular provenance record, when, and under what authority
• Supports modular provenance management, where different parts of a pipeline contribute their own bundles that are then aggregated
• Critical for multi-party content pipelines where each stage (creation, review, transformation) may have its own provenance authority
• The prov:Bundle type and prov:mentionOf relationship allow cross-referencing between bundles

PROV-CONSTRAINTS defines a formal set of validity rules that provenance instances must satisfy:

• Uniqueness constraints: Ensure that identifiers are not reused for different types of objects within a provenance graph
• Ordering constraints: Define temporal relationships, such as an entity's generation must precede its usage
• Typing constraints: Enforce that relationships connect appropriate types (e.g., wasGeneratedBy links an Entity to an Activity)
• Impossibility constraints: Prevent logically inconsistent patterns, such as an entity being generated after it was used
• These constraints enable automated validation of provenance graphs, ensuring data integrity before ingestion into governance systems

A chronological, tamper-evident record documenting every entity that has created, modified, or accessed a specific piece of content from origin to current state. In PROV terms, this maps to a sequence of Activities performed by Agents on an Entity. Key properties include:

• Continuity: No gaps in the custody record
• Integrity: Each transfer is cryptographically signed
• Non-repudiation: Signers cannot deny their role Chain of custody is critical for legal admissibility and audit compliance.

A chronological set of records providing documentary evidence of every activity affecting a content asset, designed to be unalterable. Built on hash chaining and often anchored to a Merkle tree, each entry contains a cryptographic hash of the previous record. Any attempt to modify a past entry breaks the chain, making tampering immediately detectable. This serves as the technical foundation for WORM compliance and satisfies regulatory requirements for content governance under frameworks like the EU AI Act.

A comprehensive map of data's journey, tracking origins, transformations, and destinations over time. While PROV defines the model, data lineage is the operational implementation that answers:

• Where did this data come from? (wasDerivedFrom)
• What processes changed it? (wasGeneratedBy)
• Who was responsible? (wasAttributedTo) In automated content pipelines, lineage enables rapid root-cause analysis when quality issues arise and supports derivative asset tracking across thousands of generated pages.

The application of cryptographic techniques to create a mathematically verifiable chain of custody. Core mechanisms include:

• Digital signatures: Prove authorship via public-key cryptography
• Hash functions: Generate unique, fixed-size fingerprints of content
• Trusted timestamping: Prove existence at a specific point in time
• Anchoring to blockchain: Embed provenance hashes in immutable public ledgers This transforms PROV assertions from trust-based claims into independently verifiable mathematical proofs.