Lineage

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, Google Cloud Data Lineage links, OpenLineage events, dbt and SQLMesh declarations, DataHub imports, Fivetran mappings, and BI metadata 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, and dashboard relationships. The projector keeps supporting evidence separate, so an investigation can explain why an edge exists.

Evidence authority follows this order:

  1. Runtime and warehouse-native observations.
  2. Observed query history and integration mappings.
  3. Transformation and integration declarations.
  4. Imported catalog relationships.

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:

StateMeaning
resolvedInput and output columns matched exactly.
partialSome mappings resolved and some did not.
starA wildcard prevented exact expansion.
unparseableSQL or provider evidence did not yield a mapping.
truncatedA safety bound omitted part of the mapping set.