Skip to main content
Alkera keeps a lineage graph of your data apps (connections) across your entire project: which relations produce which, and which columns feed which. The agent reads this graph to answer the question that matters before a change lands, which is what breaks if I touch this.

​
Grains

Lineage is recorded at two grains.
  • Table grain. A relation is produced from other relations.
  • Column grain. A column is produced from other columns, tagged with how it was derived, such as a rename, a cast, an aggregate, or a join key.
Column lineage comes from parsing the SQL that builds a model or view. Where that parse is not possible, Alkera falls back to the table grain rather than guessing.

​
Certainty

Every edge records how directly the flow was observed, from weakest to strongest: A connection can never stamp an edge stronger than its access justifies. A connection that cannot read query history never produces a log observed edge. When you look at an edge, you can see the tier it earned.

​
Where it comes from

Lineage is populated by your connections on a refresh, not by the agent as it edits. This keeps the graph independent of what the agent did last turn. Sources that cost nothing to read refresh on their own. A local DuckDB or SQLite file, or a dbt project, is read from files on disk, so Alkera re-reads it whenever it changes. A live warehouse is different. Even a structural query can spin up a billed warehouse, so Alkera never queries one on a schedule. Refreshing a warehouse’s lineage is something you trigger.
Some connections only refresh their lineage when you run their job. Their lineage goes stale until you do.Open Background Jobs and run the connection’s refresh job to update it.To tell which is which, find the connection’s refresh job in Background Jobs. A job scheduled on an interval refreshes automatically. A job that only runs when triggered is one you have to run yourself.
The default is deliberate as Alkera will not spend money in your warehouse to keep a graph fresh unless you ask it to.

​
Lineage and the knowledge base

Lineage graph nodes also live as schema cards in the knowledge base. Therefore, information learned while building your lineage such as table schemas is also captured in the knowledge base as catalog knowledge.

​
Blast radius

Before a change like dropping a column, renaming one, changing its type, or dropping a table, the agent propagates the change through the column graph and classifies the result:
  • Breaking. A downstream consumer depends on what you are removing.
  • Potentially breaking. A dependency exists but Alkera cannot prove it breaks.
  • Non-breaking. Nothing downstream in the paths it checked depends on it.
It reports the affected downstream assets alongside the verdict, which also tells you which tests are worth rerunning.

Agent & Tools

How the agent uses lineage before it changes anything.

Plugins & Connections

The tools that populate the graph.