Lands vs Lives

Two different questions about the same data: where it lands (the one physical base table the bytes are actually written to) versus where it lives (the layer that gives them business meaning). In a view-only medallion these can be different objects, and confusing them sends you to the wrong place.

Explanation

In a view-only medallion, the upper tiers are views, not materializations — so there is exactly one physical base table in the chain. The source (Working Heuristics — Data, Matching, Product, Org, Tooling) names the distinction sharply:

• Where data lands = that single physical base table. This is where bytes are stored, where load failures and freshness problems originate, where governance and retention actually bite.
• Where data lives = the view layer that does the modeling. This is where the data acquires its business shape and meaning, and what consumers read.

Why it matters

The distinction is a debugging and ownership compass. A correctness or freshness problem traces back to where data lands; a meaning or shaping problem lives in the modeling layer. Conflate them and you waste time editing a view when the bug is in the base table, or auditing a base table when the logic error is in a view. It also tells you where to point a Data Contract (at the boundary the physical table exposes) and what the real System of Record is (the thing data lands in, not necessarily the view everyone queries).

Connections

• Medallion Architecture — the lands-vs-lives gap only opens up in a view-only (non-materialized) medallion; this is its headline reading.
• Pipeline Legibility — knowing where data lands vs lives is one half of reading a pipeline honestly; naming it for the flow direction is the other.
• System of Record — the SOT is anchored at where data lands, not at the convenient view where it lives.

Sources

• Working Heuristics — Data, Matching, Product, Org, Tooling — supplies the lands-vs-lives framing for view-only medallions.