Description logics tell us what to automate and what to bound

Chapter 3 of Keet’s book sharpens an operational instinct: every formal system gives you some kinds of power and imposes some kinds of limits.

Description logics matter because they sit in a practical middle ground. They are expressive enough to support useful inference, but constrained enough that cost, tooling, and behavior can still be reasoned about. This is not just a technical preference. It is a business constraint. A system that cannot explain what it inferred, how long the inference will take, or when the model stops short is hard to trust in daily operations and expensive to support once it spreads across a company.

That trade-off matters at Hadto. We are building repeatable business infrastructure, not bespoke research environments. The model has to support a live system that operators and apprentices can actually use without guessing where the software is certain and where a person still has to decide.

Practical questions they force

Description logics push teams to ask:

• what kinds of classifications do we expect the system to perform?
• which inferences are worth computing automatically?
• what does the reasoner need to explain to a human?
• what complexity are we introducing along the way?

Those are product questions, not just formal ones, because each one changes what an owner can delegate with confidence and what still needs review.

Name the edges of automation

Business software often overpromises intelligence. Teams imply that the system understands more than it really does.

Keet’s discussion of standard reasoning services is a useful antidote. A system should be specific about whether it can do consistency checking, classification, satisfiability testing, or instance retrieval.

For Hadto, that means being explicit about one practical boundary. We may automate checks that a recorded role, process step, or dependency conflicts with the ontology we already committed to. We should not pretend the system can infer a novel operating policy from messy notes, exception-heavy conversations, or half-structured handoffs and then silently put that conclusion into production. The first kind of automation helps an operator catch drift early. The second creates hidden policy risk, because the business starts acting on a conclusion no one properly reviewed.

Named capabilities are better than vague magic. They tell an owner what the system will do for them, what evidence it needs, and when a human still has to make the call.

Apprenticeship benefit

There is also a training benefit here. One of Hadto’s goals is to help software apprentices become strong builders inside real businesses. Description logics teach a useful engineering habit: do not hide trade-offs behind clever tooling. Name the supported inference. Show the failure mode. Be clear when the model is only good enough to surface a candidate for review.

That mindset transfers well beyond ontologies. It is how systems stay legible when they move from a lab exercise into payroll, scheduling, handoffs, and accountability.

Chapter 3 is less about memorizing definitions than about learning to build systems that make their limits clear before those limits become operating surprises. Hadto should automate the checks it can name, explain, and bound. It should leave judgment-heavy interpretation visible to the operator until the evidence and the model are strong enough to carry more.