> ## Documentation Index
> Fetch the complete documentation index at: https://docs.alkera.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Data Lineage
> The graph of how your data is produced, and how Alkera uses it to measure blast radius.
Alkera keeps a lineage graph of your data apps ([connections](/foundations/plugins-and-connections)) across your entire project: which relations produce which, and which columns feed which. The [agent](/foundations/agent-and-tools) 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:
| Tier | Where it comes from |
| ---------------- | --------------------------------------------- |
| **Inferred** | Alkera's best guess from what it can see |
| **Declared** | A tool's own metadata, such as a dbt manifest |
| **Parsed** | Read out of the SQL that builds the relation |
| **Log observed** | Seen running in query history |
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](/foundations/plugins-and-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](/foundations/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.
## Related
How the agent uses lineage before it changes anything.
The tools that populate the graph.