Data products in the AI era: where does the logic actually live?

Every data request comes in three versions: what the user thinks they need, what they say they need, and what they actually need.

They think they need a dashboard, because that is what data has looked like for fifteen years. They say they need “weekly churn by segment,” because that phrasing can be estimated and put in a ticket. What they actually need is to know which accounts to call on Monday morning. Out of those three, the middle version in usually the only one that’s built, because the others were never written down.

For years the gap was manageable. A workshop, a requirements document and a few weeks of BI work produced a report that was close enough, and an analyst in the mix was there to fix the rest.

The arrival of AI changed the expectations. Users now want to ask a question when they have it. Today it’s churn by segment, tomorrow it’s why churn in one region jumped after a price change, and next week it’s something nobody in the room has thought of yet. Each time they expect an answer right away, from real data, and factually correct. Most data platforms were built to answer questions someone anticipated, and now we already entered the era where the requests can’t always be anticipated.

The analyst in between is gone too. That person knew that revenue in the board pack means net, that one report double counts returns, and that marketing, sales and RevOps each count leads differently, and understood those differences. Now the user asks an AI agent directly. The agent picks one of the three definitions of “lead,” joins the tables and answers with full confidence. It doesn’t have to mention that it had to make a choice.

Keeping that flexibility and still getting correct answers takes two things. The first is how you structure your data products. The second is getting business rules out of people’s heads into something agents can actually read.

One tier of data is the bottleneck

Many companies expose one type of consumption-ready data: marts with the business rules already applied, pre-aggregated and pre-filtered for the dashboard.

For dashboards, that works that works perfectly. For AI, it’s a ball and chain. An agent can only answer the questions the modeler anticipated when the mart was built. It can’t go back to the raw data to test a hypothesis or recompute a metric another way. It also can’t tell you that a business rule is the reason two numbers disagree, because the rule in question sits somewhere in 800 lines of SQL.

The underlying issue is that a mart mixes two different things. Fidelity is how close the data is to the source: every row and every edge case as recorded, with only structural changes such as types, deduplication and naming. Meaning is the interpretation on top: what revenue is, which customers count as active, the fiscal calendar, currency logic, what gets excluded. Meaning is a human decision about what the data should say.

A mart works like an edited photograph. It’s cropped, filtered and ready to publish, but you can’t undo the edit or check whether it distorted something, because the original is gone. The better setup keeps the raw negative, and the editing instructions as separate artifacts, and uses both of them to print the final picture.

Three tiers, each with its own contract

Sourcing data products sit at the bottom. They’re aligned to the source and cleaned only structurally, with no business interpretation, so the raw truth stays available for whatever someone needs later.

The business rules tier sits in the middle. We call it the semantic layer: metrics, dimensions, joins, filters and calendars, defined once, declaratively, in version control. It’s the source of truth for meaning.

Analytical data products sit on top. Business rules are fully applied, and the result is the official answer. These products are materializations of the rules tier. Nobody builds them by hand.

The point is that an agent gets access to more than one tier. Ask “What was Q1 revenue?” and it goes to the analytical tier for the governed number. Ask “Why do finance and sales report different numbers?” and it goes down to the sourcing tier, recomputes, compares the result with the rules, and tells you whether you have a data problem or a rule problem. Without the ability to dig below the highest tier, the second question has no answer.

A lot of current advice says agents should query the semantic layer and never touch raw tables. That’s too absolute. Yes, official or externally published answers should always go through the rules. But investigation needs the source, as long as the source is a sourcing data product with an owner and a contract, and not whatever raw table happens to sit in the warehouse.

This is also the part of data mesh that survived. The operating model mostly failed, while the idea of data products with owners and contracts held up, and there are now open standards for it. The Linux Foundation’s Bitol project released the Open Data Contract Standard (v3) and the Open Data Product Standard (v1.0), and Snowflake started the Open Semantic Interchange (OSI) in 2025 to make semantic definitions portable between tools. They map onto the tiers: ODCS contracts on sourcing products, an OSI-style semantic model for the rules, ODPS plus ODCS on analytical products. Adoption is early for all of them. Still, they are the first vendor-neutral answer to the question “What exactly are you promising me?”

The rules are the asset, the mart is a projection

In most companies today the mart is the asset. Teams build it, tune it and protect it. The rules live inside its SQL, get copied into the next mart and slowly drift apart. When two reports disagree, finding out why takes a week of SQL archaeology.

Flip that relationship. Make the business rules the primary artifact: governed, version controlled, written in YAML or a domain-specific language. The analytical data product becomes a materialization of those rules, and AI-assisted development does the materializing. When a rule changes, AI regenerates the tables, retests them against the contract and redeploys. The mart can no longer drift silently, because it is never the source of truth.

Two side effects matter. Materializations become disposable, so re-optimizing or moving to another platform means regenerating instead of spending months rewriting marts by hand. And AI reasons over explicit rules instead of reverse-engineering logic from SQL. Generating tested tables from explicit rules is bounded work, which is exactly what AI handles well.

Not every rule is a metric. Eligibility and classification logic (“which customers qualify,” “how do we classify this transaction”) works better in a rules engine or DMN decision tables, where a business owner can read and test it without needing to know SQL. Access policy belongs in the governance catalog and is enforced when the query compiles. Presentation stays in the BI tool. Keeping these apart is what stops the logic from getting buried again.

Where the rules tier lives

The market offers three options, and the trade-off is always portability against convenience.

BI-native semantic models, such as LookML or Power BI semantic models, hold years of modeling work, and only one tool can read them. Warehouse-native options, such as Snowflake semantic views with Cortex Analyst or Databricks metric views with Genie, launched in 2025, matured quickly and are bounded by their platform. Headless semantic layers, such as dbt with MetricFlow, Cube or AtScale, keep definitions as code in Git and serve them over SQL, APIs and, increasingly, MCP to any consumer that asks.

If the rules are your main asset, they shouldn’t be locked inside one vendor. That’s my judgment and common sense. Warehouse-native is a reasonable choice if you’re confident about the platform for the long term, as long as you put a price on the lock-in up front instead of discovering it in year three. The industry is moving toward portability anyway: Fivetran and dbt Labs closed their merger in June 2026, dbt open-sourced MetricFlow, and most major vendors have signed up to OSI. When you choose a vendor, check whether they are part of it.

How much business context improves accuracy

It helps, more than I expected and less than vendors claim.

Start with independent evidence. In the original BIRD benchmark paper, one sentence of business context moved GPT-4 from 34.9% to 54.9% accuracy. A peer-reviewed study at Bayer, published in JAMIA Open, went from 8.3% with only the schema to 78.3% with a business context document. Vendor numbers point the same way on much smaller test sets, including a dbt test with eleven questions: 72.7% overall, and 100% on the questions the semantic layer actually covered.

That last result shows where the real limit is. The ceiling is coverage: a rules tier answers what somebody defined and refuses the rest. dbt put it well. With text-to-SQL, a failure looks like a plausible but wrong answer. With a semantic layer, a failure looks like an error message. In front of a CFO, I know which one I prefer.

MotherDuck offers a fair counterpoint. They reached 95% with a clean schema alone and argue that good modeling effectively is the semantic layer. That is mostly right, but a clean schema gives you neither governance nor a single definition of “lead.” And on Spider 2.0, which looks much more like real enterprise questions, models that score above 90% on older benchmarks drop to around 21%.

What rules-first costs

Rules-first is not free, and I don’t want to present only one side of the argument. The mart-first approach is mature and widely understood. Performance is predictable because teams tune the tables directly, and nothing depends on how mature the semantic layer tooling is. Rules-first needs that tooling, AI code generation the team actually trusts, and an organizational change in which teams own rules instead of tables. The last bit is often the hardest part.

The tooling is also not fully there yet. Native materialization inside semantic layers (Databricks metric views, Cube roll-ups) sits somewhere between preview and general availability. It shouldn’t become the default for everything tomorrow.

It is also not either-or. Use rules-first where it pays off: shared metrics, anything agents will touch, anything you re-platform often. Keep mart-first for stable, performance-critical pipelines. Pilot on one bounded domain that matters, then decide.

Three time traps behind confident wrong answers

Wherever the rules live, three issues produce AI answers that are wrong and look completely fine.

Slowly changing dimensions. A customer moves from Chicago to Phoenix. The fact table joins to today’s dimension row instead of the row that was valid when the order happened, and the whole order history moves with the customer. The fix is surrogate keys, an as-of view next to the current view, and the SCD type written into the rules.

Snapshot versus flow. An agent sums daily inventory snapshots across a date range and returns a number many times too large, with nothing in the result that looks unusual. Whether a measure can be added up across time is a property of the measure, so it belongs in the rules.

Time anchoring. “Last quarter” gets calculated from today, on a dataset whose newest row is eighteen months old. The result is empty, with no error. The rules tier needs to know what “now” means for each dataset.

This is one more reason to keep the data source tier at hand. When a number looks off, the agent can drill down, recompute and show you what actually happened.

Getting the rules out of people

If the business rules are the primary artifact, getting them right is the data work itself. It is also where most projects go wrong. Requests usually describe a solution the requester already imagined, phrased so it fits a ticket. It is the XY problem, and in analytics it is everywhere. AI makes it even worse, because there’s no ticket anymore. The user asks, and the system answers exactly the question that was asked.

I have sat in many of these meetings, on the sales side and on the delivery side. The request sounds precise, everybody nods, the SOW gets signed, and three months later the client says “this is not what we meant.” They are right. We never asked.

Getting this wrong is expensive. NASA’s work on error cost escalation found that fixing a requirements error in operations can cost 29 to 1,500 times more than fixing it during requirements, and that about half of product defects and 80% of rework trace back to requirements. Boehm and Basili put the ratio at around 100 to 1 after delivery. The methodologies vary, so treat the exact figures with care. But nobody disputes the general direction.

The bigger issue is tacit knowledge. Ask a revenue operations lead how a deal gets counted and you get four confident sentences covering maybe 70% of the real rule. The rest shows up only when you put a case in front of them that breaks it.

How to get the rules out

Start from the decision. Instead of asking “What do you want to see?”, ask “What will you do differently depending on the answer?” If nobody can name an action that changes, the report should not exist, and you have just prevented a bunch of work that shouldn’t be done in the first place.

Ask for examples instead of definitions. Gojko Adzic’s Specification by Example works well for data, because anything deterministic can be described precisely with concrete cases. Do not ask what an active customer is. Ask for five customers who count and five who don’t, then ask why for each one. Write them as Given / When / Then. Those examples become the tests for the rules tier, and every time AI regenerates a materialization, these are the tests it has to pass.

Pay special attention to ones that shouldn’t count. This is my favorite question. Negative cases surface more real logic in five minutes than an hour of arguing about definitions. People recognize an edge case immediately, even when they could never state the rule.

Find the spreadsheet. The rules already exist, just not anywhere you can query them. They sit in filters of old BI reports, in stored procedures nobody has opened since 2019, in an Access database on a shared drive, and in the spreadsheet a finance analyst has maintained for nine years. That spreadsheet is your specification. LLMs help a lot here, because reading ten years of stored procedures to extract hidden rules is exactly the archaeology they’re good at.

Run a proper metric workshop, but only for the metrics that matter. Pick the two to five metrics that drive the board pack or compensation, or the ones that cause the same argument every quarter. Documenting everything else in workshops is theater. In the room you need a business metric owner accountable for the meaning, a data steward who builds and tests it, and reviewers from each function that uses the number. And nobody else who could derail the discussion. Resolve competing definitions in the room instead of pushing them to the next session. Write a decision record with an effective date and version every change, otherwise the first formula tweak creates a false trend break and someone spends a week explaining a line on a chart.

Make “unowned metric” something you can escalate. If nobody owns a metric, sooner or later it will have to be defined.

What changes when an agent is the consumer

Two things that never mattered for a dashboard now matter a lot. The first is vocabulary. Document it: synonyms, abbreviations, the internal names for the same thing, and the one word that means something different in every department. A person who knows the organization very well reads around these, an agent can’t.

The second is ambiguity. When a question can be read two ways, does the system ask back, refuse, or apply a documented default? That is a product decision. If nobody makes it on purpose, the system guesses on its own, which is the worst option.

Where to start

Pick the two to five metrics that matter most. Run the workshop, collect examples including the negative ones, name an owner and put the rules in Git.

Make sure a sourcing data product with a contract sits underneath, so the raw truth stays reachable. Build the rules tier around those definitions and generate the analytical products from it, on one bounded domain first. Run the examples as tests in CI, so a rule change that breaks a number fails before it merges.

Then give agents access to the tiers they need: the analytical tier for official answers, the sourcing tier for investigation, and the rules for what they have to respect. Enforce permissions at compile time, and write down the vocabulary and the ambiguity behavior.

Remember the three definitions of “lead”? In this setup they stop being a political fight. The agent recomputes leads from the source under each definition, puts the numbers side by side and shows which rule creates the gap. The owner decides, the rule changes in one place, and everything downstream regenerates.

Once the rules are explicit and the raw truth is still there, AI can audit the business logic itself and catch rule errors that a mart-only setup obscures. Start small, with the metrics people already argue about. If you want to learn more about data challenges in the AI era, explore our AI-superpowered data engineering.