How lineage works
Follow evidence from delivery through identity resolution and graph projection.
Embrasure stores what each source reported before deciding what the graph can safely serve.
Collect evidence
Warehouse observations, OpenLineage events, cloud lineage feeds, dbt and SQLMesh declarations, DataHub imports, Fivetran mappings, streaming metadata, BI metadata, and static analysis enter a durable evidence ledger. Each delivery keeps its provider identity, environment, scope, processing state, and replay history.
Resolve identity
Workers normalize each subject, input, and output against catalog objects inside the provider binding. Evidence can arrive before its tables are cataloged. It stays durable until a later sync or identity improvement resolves it.
Project the graph
Resolved evidence becomes active table, column, job, run, application, topic, and dashboard relationships. The projector keeps supporting evidence separate, so an investigation can explain why an edge exists.
Evidence authority follows this order:
- Runtime and warehouse-native observations.
- Standard producer events and cloud lineage feeds.
- Transformation and integration declarations.
- Imported catalog relationships.
- Static repository inference.
Lower-authority evidence can fill a gap. It cannot silently replace stronger contradictory evidence.
Read live or historical state
Live traversal uses the active graph. Pass as_of for a point-in-time view. Request bounds can limit depth, nodes, edges, columns, or time. A truncated response states the bound instead of implying completeness.
Column coverage is explicit:
| State | Meaning |
|---|---|
resolved | Input and output columns matched exactly. |
partial | Some mappings resolved and some did not. |
star | A wildcard prevented exact expansion. |
unparseable | SQL or provider evidence did not yield a mapping. |
truncated | A safety bound omitted part of the mapping set. |