Your ontology platform has to say where the live data lives

Better concepts do not automatically produce better operations. Once a system touches a real business, one practical question starts to dominate the modelling talk: where does the live data actually live, and how does the ontology reach it?

The public contract should answer that question with a simple posture. The ontology should define the business meaning. The live facts should stay in the operational systems that already own them. Mappings should connect the two, and the platform should say which workflows actually use that semantic layer.

This is the strongest public-facing lesson from Hadto’s latest Keet study pass as the work moves into ontology-to-data linkage. The issue is not a narrow technical footnote. Hadto is trying to turn operating knowledge into something another owner can run. A platform cannot do that if operators have to guess whether the ontology stores the truth, points to the truth, or merely documents intended structure.

The ontology is not automatically the whole system

It is easy to imagine an ontology platform as one big semantic container that holds classes, properties, rules, and instance data in one place. Some stacks really do work that way. Many do not. Live business data is usually spread across transactional systems, spreadsheets, forms, exports, APIs, logs, and workflow tools. The ontology may be the best place to define meaning while still being the wrong place to store every operational fact.

The public reader does not need a long architecture parade to understand the decision space. The important distinction is simpler: some systems put meaning and live facts in the same store, while others keep the facts in operational systems and use mappings, transformations, or query layers to reach them. Those choices are not implementation trivia. They change what operators should expect the system to do.

The business problem is confusion, not elegance

When a platform says it is ontology-driven but never declares its ontology-to-data posture, people fill in the blanks for themselves. One operator assumes the ontology contains the current truth. Another treats it as a modelling reference. A third expects semantic queries that abstract away the database. Someone else discovers that the workflow still depends on raw application tables and hand-written joins. The ontology may remain intellectually correct while the operating contract falls apart.

For Hadto, that becomes a transfer problem. The company wants systems that can be transferred. An owner-operator should not need internal lore to know whether a concept model is driving live retrieval, shaping a downstream transformation, or simply documenting intended structure.

What the platform has to disclose

Keet’s latest notes point toward a stricter standard. Every ontology surface should say what relationship it has to live business data. The boundary between reusable business meaning, current operating facts, application-specific implementation structures, and transformed workflow artifacts has to stay visible. Otherwise a team cannot tell whether it is looking at the business model, the live business state, or a convenience export.

The same clarity is required when the platform talks about conceptual queries. A domain expert should be able to ask a question in business terms without memorizing table names and join paths, but that promise exists only when the linkage is real. Hadto therefore needs to say whether mappings exist, whether query rewriting is supported, which workflows are ontology-mediated, what freshness guarantees apply, and where conceptual answers can differ from the raw database view.

A simple example makes the contract clearer. If a shop manager asks which open jobs are waiting on parts, the ontology can define what counts as a job, a part dependency, and a waiting state. The live answer can still come from the service system and inventory records that already run the business. What the platform has to publish is that those systems remain authoritative, that named mappings produce the conceptual answer, and that a broken mapping is an operating defect rather than a vague modelling concern.

Handoff depends on a visible data contract

Ownership is the test. A system is not transferable if only the people closest to the stack understand whether the ontology is runtime-critical, reporting-only, validation-only, or mainly design-time. A new owner stepping into the business should be able to see where authoritative instance data resides, whether the ontology mediates retrieval or only shapes exports, which semantics are guaranteed by mappings or transformations, and which parts of the operating system still depend directly on source schemas.

When those answers are hidden, technical insiders remain the real data contract.

Where this should lead

Hadto’s mission is to convert employees into business owners, and that requires software that explains itself well enough to survive handoff. The operating standard should be explicit: define the business meaning in the ontology, name the systems that own live facts, publish the mappings or transformations that connect them, and mark which workflows actually depend on that semantic layer.

That is the business-relevant version of ontology engineering. If the platform cannot tell a new owner where reality lives, which answer surface is authoritative, and where semantic mediation starts and stops, then the handoff is still running on private memory.

---

Source evidence used in this note: smb-ontology-platform/docs/plans/2026-03-31-keet-ontology-engineering-progress-tracker.md (2026-04-13 entry), smb-ontology-platform/docs/issues/ONT-030-add-ontology-to-data-linkage-architecture-and-obda-governance.md, and existing Hadto blog posts reviewed to avoid duplicating prior notes on semantic lifting, ontology stack contracts, and research-pipeline reporting.