Your AI doesn't know what "revenue" means

Your AI doesn't know what "revenue" means and that's not the AI's fault. Ask five people in your business what revenue was last month. You'll get five numbers. Invoiced. Recognised. Cash collected. Ex-GST. With government funding. Whatever the accounting system says. Everyone is right. Nobody agrees.

Your AI doesn't know what "revenue" means

Now point an AI assistant at that data and ask the same question.

It picks one. Confidently. Without telling you which one.

That's the real problem with "chat with your data". Not the technology. The dictionary.

The failure nobody expects

Most owners assume natural-language-to-SQL fails because writing SQL is hard.

It isn't. Machines are very good at SQL now.

What they're bad at is knowing what your business means.

Your database has tables called resident_invoice, payroll_entry, roster_shift, government_payment.

Your questions sound like "how did Facility 3 do last quarter?"

There is nothing in the database that connects those two worlds. So the AI guesses. It joins two tables that look related, picks a revenue column that seems plausible, and gives you a number that is beautifully formatted and quietly wrong.

Wrong numbers with high confidence are worse than no numbers.

The missing layer

What's missing sits between your raw data and your reporting. It's called the semantic layer.

Plain version: it's a business dictionary the machine can read.

Instead of exposing tables, you expose concepts:

  • Revenue

  • Gross margin

  • Active customer

  • Labour cost

  • Occupancy

  • Revenue per resident

Each one defined once, agreed once, governed once. Every dashboard, every report, every AI agent then draws on the same definition.

"Operating margin = revenue − labour cost − other operating costs."

Not a formula living in someone's spreadsheet. A definition living in the platform.

This isn't theoretical anymore. Snowflake has shipped Semantic Views — business entities, relationships, dimensions and metrics defined as objects sitting directly on top of your data. Cortex Analyst then answers natural-language questions against those governed definitions rather than against a raw schema. Cortex Agents use the same layer when they need to reason across structured and unstructured data together.

The architecture is simple to picture:


Every question your business asks now travels through one governed layer instead of around it.

Here's what the vendors won't tell you

The platform gives you somewhere to put your definitions.

It does not give you the definitions.

That part is still yours:

  • What counts as an active customer?

  • When is a job actually complete?

  • Which system is authoritative when two disagree?

  • How do we calculate utilisation?

  • What does profitability mean at site level?

No vendor knows that. It lives in your head, and in the heads of four other people who've been there long enough.

And there's a layer above even that. Call it the domain layer the operating knowledge that never made it into a metric definition:

Agency labour counts as labour cost. Contractor clinical specialists are classified separately.

Government accommodation supplements at that facility are treated differently.

If a resident leaves mid-month, the funding is apportioned this way, not that way.

When occupancy drops under 87%, labour ratios move materially. Someone should be told.

That's not data. That's how the business actually runs.

Three layers, and only one is for sale

Data layer. Storage, compute, SQL, governance. Commoditised. Buy it.

Semantic layer. Entities, metrics, relationships, definitions. Increasingly built into the platform. Configure it.

Domain layer. Rules, exceptions, thresholds, judgement. Nobody sells this. It's your competitive edge, and it's currently stored in people.

Most businesses spend their whole budget on layer one, skip layer two entirely, and never write down layer three.

Then they wonder why the AI pilot didn't land.

Smart AI in a broken process is still a broken process. Smart AI on undefined data is just a faster way to be wrong.

What to do this week

You don't need a warehouse migration to start. You need a decision.

  1. Pick five metrics. The five numbers your leadership meeting actually argues about.

  2. Write one definition each. One paragraph. Plain English. Include the exceptions, the exceptions are the valuable part.

  3. Name one owner per metric. Someone whose job it is to say "no, that's not how we count it".

  4. Find the disagreements. Where two reports show different numbers for the same month, you've found an undefined metric, not a data bug.

  5. Then choose your platform. With definitions in hand, the warehouse decision gets much easier and much cheaper.

Do those five things and you've built something durable. The platform underneath can change. The definitions compound.

This is exactly why we built our knowledge base infrastructure for capturing the tacit knowledge sitting in people's heads and making it usable by AI. Every engagement we run puts one more reusable asset into it. Definitions, rules, exceptions, the things that never got written down.

Because when someone with twenty years of institutional knowledge retires, the semantic layer doesn't retire with them.

One next step. If your reports disagree with each other and you're not sure which one to trust, that's the problem to solve before you buy anything. Our AI Discovery Workshop is a fixed-price, fixed-scope look at exactly where that's happening in your business and what to do about it.

Book a call

No jargon. No hype. No sales pitch.