What ready data actually looks like

This is part two of two. Part one argued that data readiness, not the model, is the ceiling on what a data agent can do, and that the famous AI failure rates are mostly a data problem wearing an AI hat. The obvious question it left open is the one this post answers: what does ready data actually look like? Not as a slogan, as a set of disciplines you can point at and check.

Readiness is not one thing. It is a stack of seven disciplines, and they sit in a dependency chain: you cannot define a metric before you have resolved the entity it counts, and you cannot resolve an entity before the table has a shape. Each one is decades old, unglamorous, and quietly load-bearing. Skip any of them and the agent you build later inherits the gap. One caution up front, carried straight from part one: this is not a mandate to boil the ocean. Readiness is use-case-relative, so you make the data ready for the questions that matter and expand from there, not the whole warehouse to perfection before the first answer. Here they are, bottom to top.

Dimensional modeling: the shape

Before meaning, shape. Dimensional modeling is the discipline of splitting data into facts, the events you measure, and dimensions, the who, what, when, and where you slice them by. A fact table of orders; dimension tables for customer, product, and date; one clean star instead of a hairball of source tables. The second of Kimball's four steps is the one that matters most: declaring the grain, stating exactly what one row represents, once, out loud, so nobody has to guess whether a row is an order, a line item, or a shipment. Conformed dimensions, the same customer table used by every fact, are what let two teams' numbers agree by construction instead of by argument. Notice the limit, though: conforming is a structural promise, that every fact joins to one customer table, not that the table holds the right, governed customer. Dimensional modeling gives the entity a clean place to sit; master data, below, decides what it is.

This is not nostalgia for the data warehouse of 2005. A well-modeled star is legible: a human or an agent can navigate it because the questions map onto the structure, measures by attributes. A pile of wide, denormalized extracts or raw third-normal-form source schemas is technically queryable and practically hostile. The shape is what makes everything above it possible.

The shape does not appear on its own, and it does not stay clean by itself. It is produced by a layered pipeline, the same idea in two dialects: raw to staging to intermediate to marts if you speak dbt, bronze to silver to gold if you speak medallion. Staging types and renames the raw source, the intermediate layer encodes the joins and business logic, and the mart is the dimensional model you actually query. The layering is not for tidiness, it is for reproducibility: the star gets rebuilt on every run instead of hand-cleaned once and left to rot. A model with no pipeline behind it was ready once; with one, it stays ready.

Put simply: Split the world into facts you measure and dimensions you slice by, declare what one row means, and build the star through a layered pipeline so it rebuilds clean instead of rotting. Skip the grain and every number above it is quietly ambiguous.

Entity resolution: the identity

A table has a shape, but the same real-world thing shows up in it many times, spelled differently. "Acme Inc," "Acme Incorporated," and "acme.com" are one customer living in three systems. Entity resolution is the discipline of deciding that they are one, through deterministic keys where they exist and probabilistic matching where they do not, then choosing which surviving record wins. It is tedious and never perfectly done, yet it decides whether your numbers add up at all.

Get it wrong and every count of customers is inflated, every join leaks or double-counts, and every per-account metric is built on sand. For an agent the stakes are sharper still: if the answer to "who" is ambiguous, then every keyed, per-account answer it gives is ambiguous too, and it will state the ambiguity with total confidence. Identity is upstream of trust.

Put simply: The same entity appears many times under many names; resolving them into one is what makes counts and joins correct. Ambiguous identity is not a small error, it silently corrupts every number keyed to an account.

Master data: the golden record

Entity resolution decides that three records are one. Master data management decides what that one record officially says. It is the golden, governed record for the entities everyone shares, customer, product, account, employee, plus the reference data that everything hangs off, like country codes and product hierarchies. One owned, authoritative source for the things many teams touch.

The reason this is worth the governance overhead is simple: shared entities used by many teams need one definition, or every team computes a slightly different number and the quarterly review becomes a reconciliation meeting. Master data is the difference between "our numbers" and "my numbers." It is the least exciting discipline on this list and one of the highest leverage, because it removes a whole category of arguments before they start.

Put simply: For the entities every team shares, keep one authoritative, owned record instead of many local versions. Master data is boring governance, and it is what turns five teams' conflicting numbers into one number everyone trusts.

The semantic layer: the meaning

Now the data is shaped, its entities resolved, its shared records mastered. Only now can you safely say what it means. The semantic layer is where business definitions live as code: revenue is bookings net of refunds, an active user is one with a session in the trailing twenty-eight days, churn is measured this way and not that way, each defined once and governed. The ontology underneath it makes the entities, their attributes, and their relationships explicit, so meaning is written down rather than carried in a few people's heads.

This is the layer a data agent actually talks to, and it is the enforced contract a good data agent runs against: the agent queries governed metrics, not raw columns, so it cannot invent a definition or reach a table nobody blessed. It is also the point where readiness stops being an internal data-team concern and becomes a usable asset. Everything below it was preparation; this is where the meaning becomes something a machine can be held to.

Put simply: Define every metric and relationship once, in governed code, so meaning is explicit instead of tribal. This is the layer an agent queries, and the reason it can be held to your definitions instead of guessing at them.

Quality and evals: proving it stays true

Ready is not a state you reach and keep; data decays as the business moves. So readiness includes the machinery that proves it is still true. Data quality tests check the boring, essential things: is the data fresh, are the row counts sane, are the keys unique, are the nulls where they belong. Data contracts push the same discipline upstream, so a producer who changes a schema breaks a build instead of a dashboard. And evals close the loop at the top: golden questions with known answers, run against the semantic layer, so a definition change that quietly breaks last quarter's numbers fails like a unit test rather than shipping to an exec.

This is the same idea the guide to building a data agent puts under its agent, applied to the data itself: treat it like code, version it, test it, and gate changes on the tests. Without this layer, "our data is ready" is a feeling. With it, readiness is a status you can point at, because something red goes off the moment it stops being true.

Put simply: Data rots as the business changes, so ready data ships with tests: freshness and validity checks, contracts that fail on schema drift, and golden-answer evals over the metrics. Without them readiness is a vibe; with them it is a build status.

Lineage and governance: provenance and access

Two questions decide whether a number can be trusted and whether it is safe to expose: where did it come from, and who is allowed to see it. Lineage answers the first, tracing a metric back through every transformation to the raw source, so a figure that looks wrong can be followed to where it went wrong. Governance answers the second, with access controls down to the row and column and an audit trail of who saw what.

Both matter double for an agent. A grounded answer, the kind a trustworthy data agent insists on, is only as good as the lineage behind the number it cites; the trace is the receipt. And an agent pointed at a real warehouse holds private data by definition, so column-level access and a clean audit trail are not paperwork, they are the difference between a useful tool and a breach with good intentions. Provenance makes a number auditable instead of a rumor; governance makes the whole thing safe to turn on.

Put simply: Lineage traces every number back to its source so a wrong one can be run down; governance controls who can see what and logs it. One makes numbers auditable, the other makes an agent over real data safe to deploy.

The catalog: meaning you can find

All of the above is worthless if only three people know it exists. The data catalog is the interface to readiness: the definitions, the owners, the lineage, and the documentation, made discoverable, so a new analyst or a new agent can find a metric, read what it means, see where it came from, and trust it without booking time with the one person who remembers. It is the layer that turns private, tribal readiness into something the rest of the organization, and any agent, can actually use.

Undocumented readiness is not readiness, it is luck. A perfectly modeled, resolved, mastered, defined, tested, and governed warehouse that nobody can navigate is a locked library. The catalog is the reading room, and it is where all six disciplines below it finally become usable by someone who was not in the room when they were built.

Put simply: Make every definition, owner, and lineage trail discoverable, so anyone, human or agent, can find a metric and trust it without a meeting. Readiness nobody can find is not readiness; it is luck that has not run out yet.

The stack is the point

Read the seven together and the shape of the argument from part one comes back into focus. Every discipline here, dimensional modeling, entity resolution, master data, the semantic layer, quality and evals, lineage and governance, and the catalog, is a data problem, not an AI problem, and no model does any of them for you. They stack in order, each depending on the ones beneath it, and the height of the stack is the ceiling on every question an agent can answer, from revenue to what your customers actually said last week.

That is why the readiness work is not a prerequisite you clear and forget. It is the asset. Rent the model, and this is the thing you own, the part that compounds while the models get cheaper and better on someone else's budget. Do this work ahead of time, question by question, and the agent on top of it is almost the easy part. Skip it, and no model release will save you, because the ceiling was never the model.

Put simply: Readiness is these seven disciplines stacked in order, each a data problem no model solves for you, and the height of the stack is the ceiling on the agent. Build it ahead of time, scoped to the questions that matter, and the agent is the easy part; skip it and no model raises the ceiling.