Why a data catalog isn’t enough for AI to talk to your data

Five things AI needs to talk to your data platforms — and that a data catalog does not deliver.

Every enterprise rolling out AI analytics eventually hears the same suggestion: just connect the model to the data catalog. The catalog already lists your tables, owners and lineage. It already has a glossary. So why wouldn’t that be the context layer AI needs?

It is the right instinct. And it is not enough.

A catalog helps people find datasets. That is not what makes an AI answer accurate. To answer “How did revenue trend last quarter?” the AI needs one approved revenue number — a catalog will list every table that looks like revenue and will not say which one counts. The AI needs a definition the business will actually maintain — catalogs are built for technical stewards, so the people who know what the KPI means never write it down. The AI needs an understanding of how the business works — catalogs show how data flows from source systems into warehouse tables and dashboards, not which levers move the result. The AI needs the retrieval spelled out for a machine — a catalog describes a table and assumes an analyst already knows how to query it. And the AI needs that definition running on the data platform — a catalog can document a table, even monitor it; it does not create and maintain a semantic layer AI can query.

Those five things are what Duodata is built for.

Why can’t you just point AI at the catalog?

A catalog tells you which tables exist. AI answering a metrics question does not need an inventory. It needs one approved number.

“How did revenue trend last quarter?” is not a request for every asset that looks like revenue. The model has to know what counts as revenue, and which of those tables is the one to use. A catalog will happily show finance_monthly_reporting.revenue_final, sales_mart.gross_rev, and a Power BI margin measure as three available assets. All three “exist.” Only one of them is the approved monthly revenue number — and the catalog does not say which.

It also will not say whether revenue_final treats returns or trial customers. You still have an inventory. You do not have a metric.

The same gap repeats wherever the number shows up. Catalogs are built around datasets, so “revenue” gets a glossary entry on the table, another on the dashboard, another on the semantic model. Each can be locally correct and still disagree with the others. AI then has three plausible answers and no way to know which one the company uses.

Duodata models the metric directly. There is one definition of gross margin, reused across every dataset, report and platform where that metric appears. The implementations can differ — Snowflake here, a Power BI measure there, a dbt model somewhere else. The meaning does not.

That is the difference between documenting where numbers live and governing what the numbers mean.

Why can’t business users just maintain metrics in the catalog?

Even a metric-shaped glossary fails if the people who decide the meaning never touch it. AI then answers from a definition nobody in the business has approved.

Catalogs are built for technical users: technical stewards, engineers, people who already think in tables and schemas. Asking a Head of Controlling to “own the glossary entry for gross margin” usually means they never open the tool. The definition stays in a dashboard, a spreadsheet, or someone’s head. The catalog looks complete. The meaning AI needs was never written down by the people who know it.

Duodata is built for the business. Finance, operations and product teams define and maintain metrics in business language — without needing to understand fact tables, joins or warehouse schemas. They assign ownership, review changes and approve what “customer churn” or “production volume” actually means. Data teams then map that approved meaning to the right implementation.

If the people who take the business decision cannot easily write it down and sign it off, AI will keep guessing.

Why isn’t data lineage enough for “why did this number move?”

Catalogs are strong at showing how data moves through the estate: from a source system into a warehouse table into a dashboard. That lineage is useful for technical stewards. It is not an understanding of how the business works.

When someone asks “Why did gross margin improve?”, a map of Salesforce → Snowflake → Power BI is not an answer. The model needs to know which metrics move which others — directly and indirectly. Onboarding time influences activation. Activation influences churn. Churn influences net revenue retention. That chain is a value driver tree, not a lineage diagram.

Calculation lineage tells you how a metric is computed. Value driver trees tell you what the business believes will change the outcome. Both belong in the Metrics Ontology. Neither is what a catalog stores when it traces tables across systems.

Without that business model, AI can tell you where the data came from. It cannot tell you which lever to pull.

Why can’t the catalog just write the query?

Knowing what gross margin means is not the same as knowing how to get the number. AI will not infer that the way an analyst does.

A person can read a table description and still know, from experience, that monthly revenue should come from this view, at month and region, excluding cancelled contracts. The catalog never had to spell that out, because it was written for that person. AI does not have that experience. If you only give it a table blurb, it will assemble a plausible query — and a plausible query is how you get a confident wrong number.

Duodata spells the retrieval out for a machine: which columns, at what grain, with which joins and filters, for this metric. That is not catalog documentation of a table. It is the instruction an agent needs before it touches the database.

And when someone asks for a metric that is not in the ontology yet, Duodata does not improvise a definition. It starts a definition workflow: a draft for a human owner to review, correct and approve. That is how the Metrics Ontology stays current as new questions appear, instead of silently accumulating wrong answers.

Why isn’t a glossary enough if you already have a data platform?

A catalog documents. Some catalogs also monitor when a table or pipeline changes. Neither of those puts an approved metric onto Snowflake, Databricks, BigQuery or Microsoft Fabric as something AI can actually query.

A glossary entry, however complete, still leaves the model guessing at runtime. The definition lives in the catalog. The data lives on the platform. Nothing executable connects the two.

Duodata forward-engineers the Metrics Ontology into semantic layers on your data platforms. The approved definition becomes an object AI and BI tools can query — not a paragraph next to a table. When sources change, Duodata does not only flag the asset. It maintains the semantic layer it created, so the metric AI is using stays aligned with the platform instead of going stale in a glossary.

You keep the catalog for finding data. You use Duodata to turn approved metric meaning into something the platform can run.

Do you need to replace your catalog?

No.

Use the catalog for what it is good at: discovering datasets, tracing data from source systems into warehouse tables and dashboards, and helping technical stewards navigate the estate. Many catalog or glossary entries are useful starting material. They can bootstrap a draft Metrics Ontology. A human still has to review those drafts, add the missing business meaning, and sign them off.

What you should not do is treat the catalog as the semantic layer for AI. Catalogs were not built to pick which revenue number counts, to let the business own that definition, to capture how the business works, to spell out retrieval for a machine, or to create and maintain a semantic layer on the data platform.

Those five things are what AI needs to talk to your data platforms. They are what Duodata is built for.

How to get started

If you want AI that can ask “How did revenue trend last quarter?” and “Why did gross margin improve?” against the same approved meaning, start with the Metrics Ontology — not with another pass over the catalog.

Create your first metrics on https://app.duodata.ai or reach out at contact@duodata.ai.