> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dataerai.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Verifiable provenance & lineage
> Every asset gets a tamper-evident, publicly verifiable provenance token at creation, and training or inference runs can record a queryable lineage graph.
Beyond asset-to-asset [relationships](/organize/provenance), Dataerai stamps each
asset with a **cryptographic provenance token** when it's created, and lets
machine-learning workflows record a **lineage graph** of how data flowed through
training and inference.
## Provenance tokens
When you create an asset or collection, Dataerai resolves the **creator's stable
identity** and mints an [Ed25519](https://ed25519.cr.yp.to/)-signed token that
binds the asset to that creator at that moment. The token is exposed on the asset
as `provenance_token`.
Key properties:
* **Tamper-evident.** The token is signed; any change to its contents invalidates
the signature.
* **Stable creator anchor.** The creator fingerprint is derived from an immutable
person identifier, so it survives account changes without re-issuing tokens.
* **Publicly verifiable.** Anyone can verify a token without logging in.
The token is returned as the `provenance_token` field on an asset (or collection)
when you fetch it through the [REST API](/api-reference/introduction) or an
[SDK](/sdks/python). It's a behind-the-scenes integrity stamp rather than
something you manage in the web app — for a citable, human-facing identifier you
publish and share, use the asset's [DID](/identity/overview) instead.
## Verify a token
Two public endpoints let anyone confirm a token is authentic:
* `POST /api/provenance/verify/` — submit a token in the request body to decode it
and check its signature.
* `GET /api/provenance/keys/` — fetch the published Ed25519 public keys used to
verify.
These endpoints are intentionally unauthenticated so provenance can be checked by
third parties — and they're rate-limited. The verifier is **fail-closed**: a
misconfigured key never silently downgrades verification.
## ML training & inference lineage
Training and inference workflows can record how data moved — which inputs
produced which outputs — as a **lineage graph** of runs and edges.
* **Ingest.** A run submits its edges (input → output relationships) in batches.
* **Query.** A bounded traversal walks the graph up- or downstream from any node
to answer "what produced this?" or "what was this used for?".
The query traversal is **bounded by design** — depth-capped, node- and
edge-budgeted, and deterministic — so tracing lineage on a large graph stays fast
and predictable.
Lineage ingestion is for authenticated producers and is scoped to the run's
owner; the query API requires authentication.
## When to use which
| You want to… | Use |
| ------------------------------------------------------------ | ------------------------------------- |
| Show how two assets relate (sample → measurement → analysis) | [Relationships](/organize/provenance) |
| Prove who created an asset, verifiably | Provenance token (this page) |
| Cite a record with a verifiable, resolvable identifier | [DID](/identity/overview) |
| Trace how data flowed through an ML pipeline | Lineage graph (this page) |
The provenance token and the [DID](/identity/overview) are **two distinct signed
artifacts** on an asset: the token proves **who created it**, while the DID is a
**citable, resolvable name** you can publish and verify. They complement each
other.