How to test a vendor's 'ontology' claim

A service owner does not buy an ontology. The owner buys a tool that classifies calls, routes tickets, prepares invoices, and tells a manager what needs review. So when a vendor says their product is ontology-backed, the claim worth testing is not the vocabulary. It is what one business term is allowed to do in the work. My rule: a business term should not control a workflow until the vendor can show, for one important term, its source records, operating questions, allowed actions, review owner, and missing-proof behavior. A definition that never changes what the system starts, decides, blocks, or escalates has no operating content.

First, the word itself. In software, the business map is often called an ontology: the named map the system uses to decide what kind of thing a call, customer, invoice, job, exception, or approval is. Ontology sounds technical. The risk is not technical. Bad maps tell good software to do the wrong work.

How a clean label becomes hidden policy

Here is an illustrative hypothetical, not an observed incident. At 7:14 a.m., a restaurant account texts that the walk-in cooler behind the line is warm again. The CRM turns the message into a clean label: “urgent service call.” On the dispatch board that label looks useful: a food-risk job, an existing account, a route gap before lunch. By 10:30 a.m. the owner is untangling three facts the label hid. The night dispatcher had already promised the customer that no truck would roll until the old invoice cleared. Billing still shows the account on hold. And a senior-tech note from last month says this location needs owner approval before another emergency visit, because the last two calls ended in disputed charges.

Nothing about “urgent service call” is false. That cooler may well be urgent. The label is still not enough to become a rule. Software can invent a tidy name before the business has proved what the name should control, and once the name enters the business map, the software treats it as reusable truth. Reports count it. Dispatch rules route on it. Billing checks get skipped because the call now looks like a normal emergency. A new office manager later inherits the label without inheriting the judgment behind it. That is the drift the test below is built to catch.

The owner’s side of the standard

Before any AI-generated label becomes a rule, the owner should be able to show three things, and each has a source discipline behind it.

Where the label appears in the real work. Nicolini, Gherardi, and Yanow’s Knowing in Organizations treats knowing as something carried by recurring activity, tools, notes, roles, and shared routines, not only by stored instructions or one expert’s head. In the cooler call, the situation lives in the call timestamp, the prior promise, the invoice state, the route slot, the asset history, and the disputed-charge note. A label that cannot point back to those traces has not learned the work. It has learned a phrase.

What proof confirms it. GreggU’s Complementing Intuition with Systematic Study makes the manager’s version of the point: instinct helps, but decisions improve when you look for relationships, causes, effects, and evidence. The owner’s question is not “do we like the label?” It is “when should an urgent request override a billing hold, and when should it wait for owner approval?” Recent urgent calls, unpaid balances, repeat disputes, and what happened when a tech rolled anyway are the proof that answers it.

Which similar situations need different treatment. Stanford GSB’s Precedents Thinking describes solving a hard decision by comparing it with useful examples from elsewhere and borrowing only what fits. Healthcare has authorization. Construction has change orders. Restaurants have manager comps. Banking has overrides. None of those should be copied whole into a small HVAC or plumbing company; their value is in the close cases. For an account in good standing, a warm walk-in may route as emergency food-risk work. With a billing hold, the same warm walk-in may become owner-review work. After two disputed visits, it may need a phone call from the owner first. Those are operating differences, not vocabulary choices: each version changes who can act, what record must be checked, and what the customer can be promised.

The five-question walk-through

The vendor’s side of the test is one demand: walk one important term on screen. I think “callback” is the best test case for a service business, because it touches schedules, invoices, warranty, and blame at once. A vendor can define callback as “repeat visit” or “customer complaint.” That may be enough for a glossary. It is not enough for a workflow map. Do not let the term control workflow until the vendor can answer five questions:

• Which records can use the term? Dispatch board, call note, work order, invoice, warranty policy, photo packet, or manager note.
• Which operating question does it answer? Schedule this visit, bill this visit, hold this invoice, mark warranty review, or ask the owner.
• What action is the term allowed to trigger?
• Who owns the hard case?
• What happens when proof is missing?

The five questions put one idea to work: a business term gets its role from use, examples, boundaries, training, and the activity around it. The wording comes from Hadto’s internal 2026-06-05 study lane on Wittgenstein’s Philosophical Investigations; the study is the source of the phrasing, not the reason an owner should care. The reason to care is operational. The label matters less than the work the label is allowed to do.

The last question deserves its own paragraph, because “unknown” is often the honest state. A customer saying “same issue again” can start a callback review. By itself, that sentence should not settle warranty status, labor billing, technician accountability, or a customer credit. A trustworthy tool can say which proof is missing and who has to decide. In the walk-through, the vendor should show which records can start a case, which records can decide it, and which only add context: a customer report may create a possible callback, a closeout note may narrow the symptom, a warranty policy may set the coverage question, and a manager or owner decision may be the only thing that turns the case into warranty rework, billable return, planned follow-up, or unresolved review. Those states are examples for the test, not a universal taxonomy. Then ask what happens downstream. Does the term schedule a technician, hold an invoice, create a manager queue item, update a customer record, or do nothing until review? Where can an operator reverse the decision, and what record explains the reversal?

Reading the answer

The demo sorts into two shapes. A dictionary answer is a clean list of terms with definitions and nothing about what any term may start, decide, block, or send to review. A workflow-map answer shows, for one term, the source records, the operating question, the allowed action, the review owner, the missing-proof state, and the reversal path.

Be honest about what the test proves. It is an asymmetric filter: it does not prove the vendor is strong, it catches a weak answer. A vendor that passes has earned exactly one thing, the next question: does the same discipline hold for the other terms that touch schedules, invoices, approvals, and customer commitments? That is still worth a lot. The test is cheap, it runs inside a normal sales demo, and it stops a dictionary from acquiring authority over your dispatch board, your invoices, and your promises. Pick the term that touches money or customer promises most directly, ask for the walk-through, and hold your own standard at the same time: no label becomes a rule until you have seen the work, the proof, and the close cases.

---

Source evidence used in this note: Nicolini, Gherardi, and Yanow, Knowing in Organizations, for practice-based knowing; GreggU, Complementing Intuition with Systematic Study, for evidence-based management; Stanford GSB, Precedents Thinking and the companion executive education article, for close-case comparison; Hadto’s internal study lane smb-ontology-platform/docs/plans/2026-06-05-wittgenstein-philosophical-investigations-value-extraction.md and its research manifest, for the meaning-as-use wording from Ludwig Wittgenstein’s Philosophical Investigations; and src/data/serviceOffers.ts for Hadto’s home-services operating language. The cooler call and callback walk-through are illustrative hypotheticals, not observed customer incidents. This note is business-design discussion, not legal or compliance advice.