The ontology stack needs explicit contracts

Chapter 4 of Keet’s book is especially useful for anyone building real systems instead of studying ontology languages in the abstract.

The main lesson is that OWL is not the whole story. It sits inside a broader stack with data formats, query tools, validation rules, and reasoning tools that each do different jobs.

For Hadto, those blurred boundaries become an operating problem fast. When the platform says something validated, an operator should be able to tell whether the record matched the required shape, the business rule passed, the query returned the expected result, or the system actually inferred a new fact.

Name the boundary between layers

As soon as a company mixes structured data, business rules, validation, and inference, people start collapsing them together. Everything becomes “the ontology layer” even when several mechanisms are doing different work.

The cost shows up in ordinary operating scenes. A team loads a supplier record, the dashboard shows no risk flag, and someone concludes the ontology proved the supplier is compliant. Later they learn the real problem was simpler: the validation layer only checked that the required fields existed, the query layer only returned explicit facts already in the graph, and no reasoning step ever ran. The company was acting on a guarantee the system never made.

Blurred layers create that risk. Teams overestimate what is guaranteed, blame the wrong component when something breaks, and quietly weaken the model to fit current tooling. The rule does not need a long standards tour. It is enough to say the formal boundary has to be named, published, and kept honest.

Operators need a readable contract

Hadto’s mission is to turn expertise into ownership, and that requires operational trust. An owner-operator should not have to reverse engineer the stack to know what happened.

The contract can stay plain:

• the data layer says what was recorded
• the validation layer says whether the record met the required shape or rule
• the query layer says what the system can retrieve
• the reasoning layer says what the system is allowed to infer beyond what was entered directly

If Hadto is going to launch and support ventures repeatedly, it needs reusable standards that define each layer’s responsibility, what reasoning is in scope, what is deliberately out of scope, and what happens when a use case needs more expressivity than the current platform supports. That is how a growing platform stays honest.

Chapter 4 lands on a simple rule: publish capability contracts for each layer, and do not let validation, query behavior, and ontology reasoning blur together in front of the operator.