Snowflake Just Made Business Ontology an AI Priority. Here’s What Comes Next.

Enterprise AI needs to understand business concepts. But understanding what a customer is doesn't automatically reveal how customer data connects across systems.

Snowflake's recent emphasis on Business Ontology is an important signal. The conversation around enterprise AI is moving beyond better prompts and more capable models toward a harder problem: how do we give AI a dependable representation of the business?

I think that's the right direction.

But it raises a question that deserves just as much attention:

Once AI knows what a customer, contract, or revenue means, can it actually find how those concepts connect to the data inside the company?

That is where an elegant business model meets the messy reality of enterprise systems.

A customer exists in more than one system

Imagine a company with a CRM, an ERP system, and a billing platform.

The CRM stores account_id. The ERP uses customer_no. Billing has party_ref.

All three systems refer to customers, but the identifiers don't necessarily match. Some records represent legal entities; others represent sales accounts or billing relationships. A parent company may have several subsidiaries. An account may have changed identifiers during a migration.

Now someone asks:

Which customers generated the most revenue after contract adjustments last quarter?

A business ontology may define Customer, Contract, and Revenue, including the conceptual relationships among them. That's valuable. It can also define which revenue metric the organization recognizes.

But a conceptual relationship is not, by itself, a verified physical join.

The system still needs to establish which records correspond to the same entity, which tables bridge the relevant systems, and whether joining them changes the grain of the calculation.

Otherwise the AI may produce perfectly valid SQL that answers a subtly different question.

Business relationships and database relationships aren't interchangeable

This distinction is easy to overlook because both are called “relationships.”

A business model might say:

A customer signs contracts. Contracts generate invoices. Invoices may be settled through payments.

A physical database may instead contain:

crm_accounts
    |
account_mapping
    |
erp_contract_header
    |
contract_invoice_bridge
    |
billing_invoice
    |
payment_allocation

Some of those links may have foreign keys. Others may exist only in application code, historical SQL, naming conventions, or matching data values.

And the most direct-looking join may not be the correct one. Joining invoices directly to payments can multiply invoice amounts when a single invoice has multiple allocations.

Knowing the business relationship tells you what ought to connect. Discovering and validating the physical relationship tells you how the data can safely connect.

The two reinforce each other. Neither replaces the other.

Why reading the schema isn't enough

Many enterprise databases were not designed to explain themselves to AI.

Foreign keys may be missing because applications enforce relationships outside the database. Identifiers may have different names. Data migrations can leave legacy codes. A bridge table may be essential even though the user's question never mentions it.

An LLM can make an educated guess from column names and descriptions. But an educated guess is not relationship evidence.

A more defensible approach is to examine multiple signals:

• Declared primary and foreign keys
• Column naming and data types
• Distinct-value overlap and inclusion ratios
• Candidate bridge tables and join paths
• Existing SQL and application usage, where available
• Business confirmation for relationships that materially affect results

These signals help generate candidate relationships, not automatic guarantees. A high overlap ratio can be coincidental. A frequently used join can still be outdated or wrong.

The point is to move from “the model thinks these tables connect” to “here is the evidence for this proposed connection, and here is what remains to be validated.”

The missing step is connecting meaning to evidence

For natural-language analytics, I see three separate questions:

1. What does the user mean?

Does “revenue” mean booked, invoiced, collected, or recognized revenue? Which definition is approved?

2. Where does the corresponding data live?

Which tables and fields implement that definition across the organization's systems?

3. How can those data objects be combined correctly?

Which relationships and intermediate tables are required? What is the join cardinality? Will aggregation duplicate records?

The first is primarily a business-semantics problem. The second requires semantic-to-physical mapping. The third is a relationship-discovery and validation problem.

It is tempting to put all three into a prompt and ask the model to decide. But that turns enterprise-specific facts into model assumptions.

A better design treats business definitions and relationship evidence as governed inputs to query planning, with clarification when the evidence does not support a single interpretation.

Where Semora and IntaLink fit into this discussion

This is the distinction we have been exploring in our own work.

Semora focuses on enterprise business semantics: terms, semantic mappings, metrics, dimensions, ambiguity handling, and natural-language querying.

IntaLink focuses on discovering table- and field-level relationships, including candidates suggested by keys, field semantics, and actual value characteristics. Those relationship findings can be supplied to a query system as context.

In our architecture, Semora manages its own data connections and access. It maps the relevant data-source ID to IntaLink and calls its APIs for relationship information; IntaLink does not take over Semora's database credentials or query execution.

These are complementary capabilities, not a claim that we have built a complete enterprise ontology or solved every cross-system entity-matching and join-grain problem.

The broader architectural idea is simple:

Business semantics establish meaning. Relationship intelligence supplies evidence about how the underlying data connects.

When those two are brought together, AI has a stronger foundation than schema text alone.

What should come next?

If Business Ontology becomes a mainstream part of enterprise AI architecture, I think the next challenge is making it operational against imperfect, changing data environments.

That requires more than a diagram of entities and concepts.

It requires ways to:

Discover missing links. Find candidate physical relationships even when databases don't declare them.

Distinguish evidence from assumptions. Show whether a link comes from a constraint, observed data pattern, historical query, or human approval.

Validate the path, not just the edge. A set of individually plausible joins can still produce an incorrect aggregation.

Keep meaning and relationships aligned. When a business definition or physical schema changes, teams need to know what mappings and queries may be affected.

Know when to ask. If several customer identities or revenue definitions remain plausible, AI should not quietly choose one merely to produce an answer.

These are engineering and governance requirements, not features that any single ontology announcement automatically solves.

A practical test for enterprise AI buyers

When evaluating an ontology-enabled analytics system, I would ask it to answer one question across three real enterprise systems:

Which customers are most profitable after contracts, invoicing, and delivery costs?

Then I would ask:

• Which definition of profitability did you use?
• How did you reconcile customer identities across systems?
• Which bridge tables and joins were necessary?
• What evidence supports those joins?
• How did you prevent duplicated amounts?
• What would you do if two plausible mappings remained?

A system that can explain those choices—and admit when a choice is unresolved—is much more interesting than one that merely produces SQL quickly.

The bigger opportunity

Snowflake's attention to Business Ontology is another sign that the enterprise AI conversation is maturing. Organizations are recognizing that models need structured business meaning, not just access to raw data.

The next step, in my view, is to connect that meaning to the relationships hidden in operational databases.

Because defining what a customer means is not the same as finding that customer across CRM, ERP, and billing.

And defining revenue is not the same as proving that the tables used to calculate it are correctly connected.

Business Ontology gives AI a language for the enterprise. Relationship intelligence helps ground that language in the enterprise's actual data.

The most useful systems will need both.