Every data platform now promises to learn your business by reading the traces it leaves behind: the schemas, the queries, the dashboards. But a system of record captures a representation of reality, and a representation is not a definition. Why is the pitch so seductive? It offers the thing most teams want, which is a semantic layer without the meetings. As discovery, it genuinely works. The slip comes at the promotion, the moment you treat what the machine observed as what the business means.

Schemas are decisions, not definitions

A relational schema tells you how an application chose to persist something, not what that something means. Surrogate keys, junction tables, status codes, audit columns: those are implementation decisions, made under a deadline, often by a vendor who never met your business. Kimball drew the line decades ago, gathering business requirements from the business and treating source systems as a separate question of feasibility. Inference collapses the two, and most teams have helped it along, usually because the schema was sitting right there and the business stakeholder wasn’t. Collapse them and three things go missing.

Meaning fragments. Customer lives in sales, billing, support, and fulfillment, and no single system holds the whole concept. An engine reading four representations finds four concepts. Or worse, it fuses four deliberately different meanings into one.

The business definitions that matter most were never columns. What makes a customer active, which orders count toward revenue, who’s eligible for what: the business runs on definitions and rules no application ever stored. And you can’t extract what was never persisted.

Old workarounds calcify into knowledge. Infer an ontology from twenty years of applications and you institutionalize twenty years of compromises, including the ones your own team made. The most-used dashboard in the company can carry a revenue definition somebody invented locally years ago. Heavy usage only proves that the dashboard is popular. It doesn’t prove that the definition is right.

Agents raise the price of being wrong

This mattered less when the consumer of inferred semantics was a chart. A person reads a chart, and a person can smell a wrong number. An agent doesn’t read. It acts, at machine speed, and it acts with confidence, applying a revenue definition somebody invented locally years ago as if it were policy.

So the cost of an unexamined definition has changed. It used to be an argument in a meeting. Now it can be a refund issued, a forecast filed, or a customer contacted, all downstream of a concept nobody ever agreed on.

How DeltaVault lets evidence propose and the business decide

None of this argues against inference. It argues about direction. Observation is a superb way to discover candidates for your business ontology and a terrible way to legislate it. Your systems are witnesses, and good ones, but they don’t get to hold the pen.

That distinction shaped how we built DeltaVault. Here’s what you see.

In each case the evidence flows up, you accept or dismiss it one at a time, and the meaning is decided rather than detected.

So the question underneath the feature announcements isn’t which platform infers the best semantic layer. It’s who gets to define what your business means: the business itself, or an algorithm reading its exhaust. Your systems have plenty to say. Treat them as evidence, cross-examine them, and map what survives into a model someone accountable has signed off.

The open question is where the accept-or-dismiss gate holds and where it turns into rubber-stamping. If you’ve run human review over hundreds of source tables, what kept the decisions real?

Here’s where to start.

  1. Start with the concepts the business actually runs on.
  2. Point discovery at the ugliest source and let it argue with you, one scored suggestion at a time.