Your ontology shouldn’t stop at the warehouse

The problem everyone agrees on

The framing is now familiar, and it is correct: every enterprise has the data, and almost none have the meaning. Your systems store millions of rows, but nothing captures what they represent — that a Customer holds Contracts, which contain Invoices, governed by rules only two people on your team remember. Without that layer, an AI agent is guessing at column names and inferring relationships from string similarity.

Databricks Labs’ OntoBricks is a well-built answer to that problem, and it is worth understanding on its merits. It reads Unity Catalog metadata, has an LLM propose an ontology, auto-generates the mappings, and materializes a triple store — with real W3C standards underneath (OWL, R2RML, SPARQL, SHACL) and a proper DRAFT → IN-REVIEW → PUBLISHED review lifecycle on top. If your business already lives in a Databricks lakehouse and you want a governed graph over it, that is a serious tool and we would not pretend otherwise.

The question this post is about is narrower: what is the scope of the ontology you end up with?

A graph of your warehouse is a graph of yesterday

A lakehouse-native ontology can only describe what has already landed in the lakehouse. That is not a criticism of the implementation — it is the definition of where it sits in the stack. But it has two consequences that show up the moment an agent goes to production.

First, coverage. The meaning in most businesses originates upstream of the warehouse. Order state lives in Shopify. Entitlements live in the CRM. The refund decision lives in the billing system, and the reason for it lives in a Zendesk ticket. Some fraction of that gets modeled into the lakehouse eventually, because someone prioritized the pipeline. The rest of it — often the part a support or ops agent most needs — never does.

Second, freshness. A materialized triple store is a point-in-time projection. It is correct as of the last synchronization run. Schema drift upstream surfaces as a warning that your mappings are about to break. For analytics, a sync-cadence graph is completely fine. For an agent answering a customer in real time about a refund that finance approved this morning, “correct as of last night’s sync” is a wrong answer delivered confidently.

Entities are nouns. Work is verbs.

There is a second boundary, and we think it is the more interesting one. An ontology in the classical sense models entities, relationships, hierarchies, and constraints. Order placed_by Customer. Refund refunds Payment. This is genuinely valuable, we author it too, and the next section is about how — see how concepts connect for the mechanics.

But an agent that knows a Shipment relates to an Order still does not know what your company does when a shipment arrives three units short. Does it reship automatically below a dollar threshold? Who approves the exception above it? Was an override granted for this customer tier last quarter, and did it stick? None of that is an entity or a relationship. It is procedural knowledge and access norms, and no entity-relationship diagram has a place to put it.

This is why Loxtep’s substrate has three parts rather than one: AI-ready data and a knowledge graph; semantics and ontology; and skills — procedures and norms. The third part is encoded through the process graph and decision traces. It is the difference between an agent that can describe your business and an agent that can act inside it.

You shouldn’t have to draw your ontology

Canvas-first tools make a reasonable bet: an LLM proposes a first draft from your table metadata, and from there you drag entities, draw relationships, and refine by hand. The visual surface is the authoring surface. It demos beautifully.

We went the other way, for one reason: a diagram you drew is a claim about your business, and a diagram mined from your running systems is evidence about it. Those are not the same artifact, and only one of them stays honest as the business changes.

So authoring in Loxtep is review-driven, through the loxtep_review MCP tool:

• Context mining proposes. Loxtep reverse-engineers candidate entities, relationships, and vocabulary from connected systems and runtime signals — procedure inference, vocabulary inference, catalog analysis, query history, and decision traces. Not from table names alone: from how your business actually behaves.
• You review and approve. Candidates arrive as proposals, not facts. A human accepts, edits, or rejects each one, and nothing enters the context layer unapproved.
• The lifecycle governs it. Every approved artifact moves through draft → in_review → approved → deployed → retired, with versioning, dependency tracking, and change propagation.
• Then you visualize it. The graph view shows you what you approved and how it connects — an inspection surface over a governed artifact, rather than a drawing tool you are responsible for keeping true.

The practical difference shows up on day 400, not day one. A hand-drawn ontology is accurate the week you drew it and drifts quietly from then on, because nothing forces the picture and the business back into agreement. A mined-and-approved one keeps getting new evidence from the systems it describes — so drift surfaces as a fresh proposal to review rather than as an agent confidently answering from a model of a company you no longer are.

It is also worth noticing where the authoring happens. loxtep_review is an MCP tool, which means the surface you use to curate your ontology is the same surface your agents use to read it. You can review proposals from the same assistant you are already working in, rather than context-switching into a separate modeling application to keep your semantics current.

Governance at authoring time vs. at runtime

Review workflows over ontology versions — draft, review, sign-off, audit trail — are table stakes, and the lakehouse tools do them well. Loxtep runs the same lifecycle over every context artifact, not just ontologies (we call it the Context Development Lifecycle: draft → in_review → approved → deployed → retired).

The gap is at the other end. Approving a published ontology governs what the graph says. It does not govern what the agent may do with it at three in the morning against a live customer record. That needs role-based access control enforced fail-closed at the point of retrieval, PII tagging that travels with the field, and a decision trace for every action. Authoring governance and runtime governance are different problems, and an agent platform needs both.

Where the lakehouse tools are genuinely better

We would rather be useful than win a feature table, so: there are real reasons to pick a lakehouse-native ontology tool over us.

• Standards depth. If you need real OWL 2 RL inference, SWRL rules, SHACL validation, or a SPARQL endpoint, that is their engine, not ours. We model relationships and serve entity context; we do not run a description-logic reasoner.
• Pre-built industry ontologies. One-click FIBO, CDISC, IOF, or HL7 FHIR imports are a large head start in a regulated domain, and we have no equivalent.
• Data residency. Deploying inside your own workspace, where triples never leave, is a genuinely strong property for some compliance postures.
• Cost. Source-available and running on infrastructure you already pay for is hard to beat on price — provided you already run the infrastructure, and accept that it ships AS-IS with no SLA.

If your ontology question is “what do the tables in my lakehouse mean, in a standards-compliant way,” that is the right shape of tool. Ours is a different question.

The question we’re answering

Ours is: what does my business mean, across every system it actually runs on, live enough for an agent to act on it? That pushes the ontology upstream of the warehouse, onto a streaming backbone so there is no re-materialization step between the data changing and the agent reading it, and extends it past entities into procedures and permissions. It also means not requiring you to stand up a lakehouse, a SQL warehouse, and a platform team before step one — which is the whole point of enterprise-grade reliability without the enterprise team.

A knowledge graph is not the goal. An agent that gives a correct answer about order #4821 — right now, to the right person, and able to do something about it — is the goal. The graph is one of the things that has to be true underneath.