Your Data Is Technically Correct.
That Doesn't Mean It's Right.

Source systems (EMRs, CRMs, billing tools, ad networks, POS platforms) generate data as a byproduct of running operations. They weren't built to answer business questions; they were built to manage workflows. Different sources have fundamentally different sync cadences: some push data in real time as events occur, others export in nightly batches. That cadence defines the freshness ceiling for any downstream analysis touching that source.

Governance at this layer means understanding exactly what each source produces, how reliably it produces it, and what "current" means for that system at any given point. The moment you need a metric the source doesn't natively produce (churn rate, LTV, rebooking rate) you're entering the territory of the pipeline and transformation layers, where most accuracy problems originate.

Data moves from source systems into the warehouse via ELT pipelines (tools like Fivetran or Airbyte extract from each source, load raw data into the warehouse, and leave transformation to happen there). Pipelines run on schedules: hourly, nightly, or event-triggered.

Good governance requires that pipelines be observable, covering not just whether they ran, but how long they took, how many records loaded, whether that matches expected record counts, and whether there were schema errors. This is sync health: the operational visibility layer that answers a prerequisite question before any analysis runs: is the data actually current and complete? Governance also requires that schema changes in source systems (renamed columns, changed data types, deprecated tables) are caught and reconciled at the ingestion layer before they propagate as silent errors downstream.

Raw ingested data is cleaned and made structurally usable: deduplication, field name standardization across sources, type enforcement, null handling. Then data modeling takes over: business logic that doesn't exist in any source system gets encoded here. Derived metrics like cohort retention, patient LTV, rebooking rates, and net revenue after returns are calculated and encoded as reusable models (commonly in dbt). Models define the join logic that connects data across sources and produce the numbers organizations actually use to make decisions.

Good governance treats models as living definitions, not static builds. When business logic changes (a new attribution methodology, a revised definition of "active," a change in the rebooking window) the model changes with it, and that change propagates downstream automatically. Model ownership must be explicit: someone is accountable for whether a model's logic reflects current business intent, not just whether it runs without errors.

Where data modeling produces the data, the semantic layer assigns it meaning: what counts as revenue, what the correct attribution window is, how churn is calculated, which records qualify as "active." These definitions are what every downstream query should reference. The semantic layer doesn't produce data; it produces meaning.

The most important governance principle applies here: a metric's definition should describe what it means in business terms, not how to calculate it. SQL is generated from that definition, not the other way around. Most data stacks operate in reverse: metric definitions live inside individual SQL queries, written by analysts who each made their own reasonable interpretation. The result is a probabilistic system where the same question produces different answers depending on who authored the query. Each codified definition becomes a canonical, owned, authoritative metric, and its provenance is traceable back through the definition to the source data underneath.

The semantic layer also handles the legitimate reality that many organizations have multiple valid definitions of the same term. Marketing's revenue and finance's revenue are often deliberately different. The answer isn't to collapse them; it's to codify each separately, named and governed: "revenue (gross, marketing attribution)" vs. "revenue (recognized, GAAP)." The choice of which definition to use becomes an explicit, auditable decision rather than an assumption embedded in a query.

The output of a data model can be persisted as its own table in the warehouse (materialized) or computed dynamically each time it's queried. Materialization is a performance decision: querying a cached result is significantly faster than rerunning model logic across large datasets on every request. The tradeoff is freshness: a materialized table is a snapshot, static until explicitly refreshed on its schedule.

Good governance requires that materialization cadence be an explicit, documented decision matched to the freshness requirements of actual downstream users, not a default set once during initial setup and never revisited. Finance needing data current as of this morning has different requirements than a weekly executive report. Materialization jobs should be part of sync health monitoring: if a refresh fails or runs significantly late, that needs to surface before users query against stale data.

Dashboards, reports, and ad hoc queries translate modeled data into what stakeholders actually see. Queries should reference governed datasets and governed metrics, not raw source tables. When a visualization is built on governed foundations (a governed dataset, a governed metric, a query generated from a canonical definition rather than authored from scratch) the result is a governed widget: one that produces a consistent answer because it draws from a consistent definition. Two governed widgets referencing the same metric produce the same number, without approximation. Freshness timestamps should be surfaced alongside every number so users know what "current" means for what they're looking at.

AI agents accept natural language questions and generate queries against the underlying data at higher volume and with significantly less oversight than a human analyst. They represent a new participant at the visualization layer, one that can query hundreds of times per day without anyone reviewing individual outputs. Their accuracy is entirely dependent on the quality of the infrastructure they sit on top of.

An AI querying against ungoverned data does what it has to: it infers definitions from available evidence (existing queries, column names, historical patterns). That inference is probabilistic. It's right most of the time, with no reliable mechanism for knowing when it isn't. An AI operating on a fully governed foundation operates differently: it executes against fixed, canonical definitions rather than inferring them. The same question produces the same answer not because the model happened to make the same inference twice, but because the definition is codified and the query is generated from it.

The degree of probabilism in an AI's outputs is a direct function of how much of the underlying stack is ungoverned. Each ungoverned layer (inference on definitions, business logic, table relationships) compounds the others. Governance that was adequate for five analysts writing queries manually may not hold when an AI is generating hundreds of queries per day against the same foundation.