Record the source, device, build, dataset, model or authoring context at the earliest reliable point.
Digital provenance systems index
Know the source.
Verify the chain.
A researched directory of standards and systems that preserve origin, lineage, integrity and accountability across media, data, models and software.
30RESEARCHED SYSTEMS
05EVIDENCE LAYERS
Media, data, models and software
Official standards and project sources
Last researched 27 Jul 2026
Evidence before assumption
Trust needs a record.
Not a guess.
Provenance answers where an artifact came from, how it changed, who or what signed it, and which policy accepted it. It can establish integrity and accountability. It does not automatically establish factual truth, ownership, safety or human origin.
TRUST MODEL / 05 CONNECTED LAYERS
Preserve the evidence.
Separate the claims.
- 05Decision and policyWhat a verifier or relying party is prepared to accept and under which conditions
- 04History and transparencyWhen the artifact, event, dependency or claim entered the record
- 03Identity and signatureWhich person, organisation, workload, device or builder made the assertion
- 02Artifact bindingHow the evidence remains connected to exact bytes or a recoverable content signal
- 01Source and captureWhere the media, dataset, model, package or device state entered the system
Operational trust chain
Evidence becomes useful
through verification.
A dependable chain keeps capture, identity, integrity, history and policy distinct. Each stage contributes evidence, and each stage can also be incomplete, removed or misconfigured.
Connect claims to exact bytes, stable identifiers, content hashes or durable media signals.
Associate evidence with a controlled key, identity, certificate or attested workload.
Preserve transformations, dependencies, timestamps, receipts and material changes.
Check signatures, digests, trust roots, freshness, transparency and policy requirements.
Accept, reject, constrain or escalate based on evidence quality and business context.
Provenance systems directory
Compare the evidence
each system can support.
Systems are grouped by the evidence layer they primarily own. Order within each layer balances maturity, adoption, operational usefulness and source clarity. Signed provenance, watermarking, metadata lineage and attestation are not interchangeable.
No matching systems
Try another evidence layer, maturity, deployment path, access model or search term.
Same-layer comparison
Compare like with
like.
Choose up to three systems from one evidence layer for a direct comparison. Before selection, the guide below separates five common provenance architectures.
0 of 3 selected
Evidence boundaries
Combine the signals.
Keep their meaning.
A signature, watermark, lineage event and credential answer different questions. Strong systems preserve those distinctions and apply policy only after the relevant checks succeed.
- 01 / SIGNED PROVENANCE
- Validates integrity and a signer relationship. It does not certify that the underlying claim is true.
- 02 / WATERMARK
- Helps recover or identify participating content after transformations. Absence of a signal is inconclusive.
- 03 / LINEAGE
- Records operational history and dependencies. Its completeness depends on instrumentation and source quality.
- 04 / ATTESTATION
- Packages claims about a build, workload, device or organisation for evaluation against policy.
Research method
Useful evidence needs
honest boundaries.
Each profile identifies the primary evidence layer, deployment model, access model, trust anchor and official source. Capability signatures distinguish native evidence from integrations and external policy.
Classify the claim
Origin, identity, integrity, edit history, lineage and truth are separate properties.
Inspect the binding
Understand whether evidence follows exact bytes, a digest, embedded metadata or a resilient signal.
Verify the identity
Check who controls the key, certificate, workload or device and how trust is established.
Trace the history
Look for timestamps, materials, transformations, receipts, revocation and missing intervals.
Define the policy
Verification becomes a decision only when an organisation states what evidence it requires.
Date every claim
Specifications, versions, maturity and product availability are checked against current official sources.
Primary references: C2PA 2.4 ↗ · SLSA 1.2 ↗ · Sigstore ↗ · OpenLineage ↗ · W3C Verifiable Credentials 2.0 ↗
Before implementation
Six questions before
trusting the record.
Which claim matters?
Define whether you need source, identity, integrity, history, rights, safety or factual review.
Where is evidence created?
Capture close to the source, device, builder or workflow before uncontrolled transformations occur.
What survives distribution?
Test stripping, transcoding, resizing, screenshots, registry moves and offline exchange.
Who controls trust?
Document key custody, trust roots, identity proofing, delegation, revocation and recovery.
How are gaps handled?
Make missing credentials, broken links, expired evidence and conflicting claims visible.
What action follows?
Connect verified evidence to acceptance, warning, quarantine, approval or human review.
Engineering the trust layer
From evidence design
to working controls.
ADOR.IS designs content-authenticity workflows, signed software pipelines, model and data lineage, workload identity, verification interfaces and the policy systems that connect evidence to real decisions.
[email protected] ↗