Smart Diagnostics: An Ontological Repair System

"It suddenly won't turn on anymore."

That’s the user’s complaint. After an hour of analyzing, measuring, and disassembling, the repair technician concludes:

"Motor defective."

Between those two sentences—the complaint and the conclusion—lies a world of expertise. It’s a complex web of hypotheses, tests, observations, and deductions, often built on years of experience.

The question is: how do you capture this knowledge so it can be reused and shared more effectively?

Ontological System

Knowledge is more than data, and the answer lies in an ontological system. It’s the blueprint of concepts, relationships, and rules that together form the semantic framework for your data.

The Blueprint
The W3C provides several standards that can help with this: OWL (Web Ontology Language) and SWRL (Semantic Web Rule Language).

The OWL format defines how concepts and relationships are structured, for example:

@prefix ex: <http://example.org/repair#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

ex:Chain a owl:Class ;
    rdfs:subClassOf [
        a owl:Restriction ;
        owl:onProperty ex:partOf ;
        owl:someValuesFrom ex:Bicycle
    ] .

ex:Bicycle a owl:Class .
ex:partOf a owl:ObjectProperty .

This says (in Turtle syntax): a chain is a part of a bicycle.

In SWRL, you define the rules:

Bicycle(?b) ^ hasPart(?b, ?c) ^ Chain(?c) ^ Rusty(?c)
→ NeedsRepair(?b)

In other words: If a bicycle has a rusty chain, then that bicycle needs repair.

These kinds of classifications, relationships, and rules can be modeled with Protégé and exported to formats like RDF/XML.

The Data

This blueprint defines the concepts, relationships, and rules—but not the data itself. For example, all repair records with their diagnostic steps.

Traditional relational databases aren’t built for this. Sure, they can store relationships, but not the meaning of those relationships.

A better fit is a knowledge graph that stores data as a triple store. A triple store captures data in this form:

Subject — Predicate — Object

Chain partOf Bicycle

The predicate describes something about the subject and can be linked to a definition in the ontology (OWL).

A knowledge graph can then use the previously defined blueprint of our data. You’re not only defining what is true, but also which rules apply. This creates a declarative system where logic naturally emerges, and a reasoner can infer new triples (inference).

You know that A is a Chain and Chain ⊑ partOf Bicycle
⇒ You can infer that A is part of a Bicycle.

With a query language such as SPARQL (built for triple store patterns), you can, for example:

PREFIX ex: <http://example.org/repair#>

SELECT ?bicycle
WHERE {
  ?bicycle a ex:NeedsRepair .
}

Here you see the power of the reasoner: nowhere in our data did we explicitly state that a particular bicycle needed repair—but because the reasoner inferred it from the rules, we now know it!

Example: Flashlight

Let’s look at this differently, using an object we all know: a simple, old-fashioned flashlight (with a light bulb). It’s a perfect example—few components, but rich, non-linear diagnostic logic.

Let’s dissect our flashlight ‘ontologically’.

Step 1: The Building Blocks (Concepts)

First, we define the ‘things’ in our world. In an ontology, these are called concepts or classes.

Product: Flashlight
Components:
- Batteries
- Bulb (incandescent)
- Switch
- Contacts (springs and metal strips)
- Housing

Step 2: The Complaints (Symptoms)

Next, we define the complaints a user might report—these are the symptoms.

Symptom A: “It doesn’t turn on at all.”
Symptom B: “It gives very weak light.”
Symptom C: “The light flickers.”

Step 3: The Actual Problem (Cause)

These are the actual, confirmed defects.

Cause 1: Batteries are dead (or almost dead).
Cause 2: Bulb is burnt out.
Cause 3: Contacts are dirty or corroded.
Cause 4: Switch is mechanically broken.

The Blueprint

So far, this looks like a set of simple lists—a standard database could store that. The true power of an ontology lies in defining the concepts, rules, and relationships between them.

To do this, we must first capture the expert’s thought process. We do that with a detailed logbook, which can be visualized as a ‘diagnostic path’: every hypothesis, test, observation, disassembly, replacement, and conclusion becomes a diagnostic step.

Zaklamp flowchart — Possible diagnostic steps from symptom to cause

View full flowchart

A flowchart like this is essentially a visual representation of OWL+SWRL rules.

Our system is no longer a dumb logbook—it becomes a knowledge graph that ‘understands’ that one cause can lead to multiple symptoms, and one symptom can have multiple causes, each with its own diagnostic path.

From Data to Expert System

As this system grows, we can extract several key benefits:

Guided Diagnostics: A junior technician gets a flashlight with Symptom C (Flickers). The system says: “Start by checking the Contacts. In 82% of previous cases, that was the cause.”
Pattern Recognition: The system might find that Housing Type Y more often leads to Cause 3 (Corrosion) than Housing Type Z. That’s crucial feedback for product design.
Knowledge Preservation: The expertise of your senior technician is digitized. His intuitive ‘feel’ for a problem becomes weighted relationships in the knowledge graph.

After all, the right diagnosis is essential to ultimately perform the actual repair.

Making AI Smart

By capturing not just data, but the concepts, relationships, and rules between them, we build a declarative system that doesn’t just remember what happened—it understands why. This works fundamentally differently from an AI model that assumes connections from vast training data, while an ontological system knows the connections defined by experts.

None of the above requires AI (in the sense of an LLM, multimodal model, or agent). But AI can use such a system as a tool. In that sense, AI becomes the user interface for the knowledge system. The benefit: you harness AI’s strengths while maintaining a deterministic and trustworthy foundation.