AI should propose ontology candidates, not author the business model

Maya ran intake for a small specialty clinic. She knew the difference between a missed document, a wrong code, a payer exception, and a case that needed the doctor to call the patient before anyone touched billing.

The new AI tool did not know that. It read a stack of notes, explanations of benefits (EOBs), claim denials, and front-desk messages. Then it produced a clean category called Patient Follow-Up Failure.

The label sounded useful. It grouped twenty messy cases under one neat name. A dashboard could count it. A manager could assign it. A future workflow could route it.

Maya hesitated because the cases were not the same. One patient never received the form. A payer required a missing attachment. Another denial came from a plan rule that the clinic had not captured. The last case looked like follow-up failure only because the doctor had not signed a note. The AI had found a pattern, but it had also erased the distinctions the business needed to run.

That is the line Keet’s Chapter 7 helps us keep. Semi-automated ontology work can surface candidates. It should not decide what the business means.

Text mining, clustering, document parsing, reasoning services, and LLMs can all help a team see possible terms and relations. That is real value. A model can notice repeated phrases, propose a class name, cluster similar records, and suggest that one event often causes another.

The danger starts when a polished suggestion gets treated as accepted knowledge.

Patient Follow-Up Failure might be a real category. It might also collapse four different operating problems: missing paperwork, payer-specific requirements, clinical-signoff lag, and customer communication. If Hadto lets the tool write that label straight into the ontology, the next operator inherits a false business memory. Apprentices learn the wrong distinction. Reports count the wrong thing. Fixes aim at the wrong owner.

The AI did not make a harmless wording choice. It changed how the business sees work.

Review has to be visible

A candidate record should carry its own trail. It should show the source document or interview that triggered the suggestion, the exact term or relation proposed, the nearby evidence, the model or heuristic that produced it, the reviewer who checked it, and the final decision: accepted, revised, deferred, or rejected.

That review path is not bureaucracy. It is how domain expertise stays in charge while automation helps with scale.

Maya should be able to mark the proposed category as too broad, split it into sharper cases, and attach the evidence that explains why. Another operator should be able to inspect that decision later without asking Maya what the AI missed.

Hadto’s rule

Hadto is building systems that absorb domain expertise and make it transferable. That only works if the platform preserves the difference between source evidence, machine suggestion, reviewed modelling decision, and accepted reusable business knowledge.

AI belongs upstream as a candidate engine. It can bring possible classes, relation patterns, source snippets, and competency questions into a review queue. Hidden repetition becomes easier to see, and an operator can move faster.

The machine still cannot author the business model alone.

The standard is simple: a machine may propose the category, but a reviewed business process has to decide whether that category becomes part of the company’s shared memory.