Lineage describes where data comes from and where it goes: which sources, tables and columns feed each table, and which reports depend on it. It answers questions such as "what breaks if this column changes" and "where did this number come from". Lineage can be captured at table or column level.
For example, a revenue figure on a dashboard comes from a gold.monthly_sales table, which is built from silver.orders and silver.stores, which are built from bronze tables loaded from the shop database and a stores spreadsheet. Column lineage goes further: the dashboard's revenue comes from gold.monthly_sales.revenue, which sums silver.orders.amount after excluding returns. If the spreadsheet's region names change, lineage shows which gold tables and dashboards are affected.
Lineage can be declared, by reading the references in SQL models and pipeline code, or observed, by recording which tables each query actually read and wrote. Platform catalogs capture observed lineage; Unity Catalog, for example, records table and column lineage for queries run on Databricks. Declared lineage is available before code runs, which makes it useful in review, while observed lineage covers queries nobody wrote down.
Lineage is most useful when it answers a specific question quickly: what to rebuild after a fix, which reports to warn before a change, where a column with personal data ends up. A data contract and lineage together tell a producer both what they promised and who relies on it. See also orchestration and gold layer.
Lineage also helps with cost and clean-up: a table that nothing reads can be retired, and an expensive table read by a single report can be built less often. Kept up to date, it becomes the map that new team members use to find their way around the data. See also semantic model and SQL model.
In Emolysis, the /explain skill describes a pipeline's lineage and cost in plain language. See The emo CLI for the other skills, and semantic model for how business definitions connect to the tables behind them.