Data Provenance Standards
Common formats and identifiers that make the lineage of data portable, machine-readable, and durable across tools and time.
Why standards, not just logs
Any project can invent its own way to record where data came from. But ad hoc records do not survive tool changes, staff turnover, or external review. Provenance standards define a shared vocabulary and structure for lineage so that a record written by one system can be read by another, and by a reviewer years later, without a translator.
What standards provide
- A model of entities (data), activities (processes), and agents (who or what acted)
- Stable identifiers so an artifact can be referenced unambiguously
- Machine-readable formats so tools can query lineage automatically
- Interoperability across the many tools a project uses
Identifiers and durability
A provenance record is only as durable as the identifiers it uses. Persistent identifiers, such as content hashes for exact bytes and DOIs for published deposits, let a record point at something that will still be findable later. A link to a file path on someone's laptop is not provenance; a content hash and a deposit identifier are.
The entity-activity-agent triple
Most provenance models reduce to three linked things: entities (a dataset, a result), activities (a simulation run, a transformation) that use and produce entities, and agents (a person or a piece of software) responsible for activities. This simple structure is expressive enough to capture almost any lineage while staying queryable.
record = {
'entity': {'id':'sha256:...', 'kind':'result'},
'activity': {'id':'run-8842', 'code':'commit a1b2c3d4'},
'agent': {'id':'pipeline', 'kind':'software'},
'used': ['sha256:input...'], 'generated': ['sha256:output...']
}
Kronos use
Kronos publishes reproducible artifacts with persistent identifiers so that a design number traces to a deposit that can be fetched and re-run. Standard provenance is what lets an outside reviewer follow that trail without inside knowledge of the toolchain.