From experiential knowledge to an expert system

Experienced people often notice early that something is wrong. They see an inconsistent number, hear a risky phrase or recognise that a case does not fit the usual category. This judgement may feel intuitive, but it is rarely without foundation. Behind it are observed patterns, exceptions, consequences and priorities refined over years. An expert system does not begin by copying a person. It begins by making one bounded part of that decision work visible and testable.

Experience is more than a collection of rules

Experts do not act like a rigid if-then program. They consider sequence, context and interactions. A rule that works in the normal case may fail for a certain audience, a missing piece of evidence or a high-consequence situation. Knowledge automation therefore fails when it collects isolated maxims.

Experience contains at least four layers: recognisable signals, a reasoned rule, known exceptions and a measure of the consequences of error. Only their combination explains why the same observation can lead to different decisions in two cases.

The goal is not a complete encyclopaedia of a field. It is a small decision space whose inputs, rules, boundaries and outcomes are clear enough for experts to inspect and others to apply.

Start with a decision, not a profession

“Build a digital expert” is not a workable brief. A concrete question is better: Is this brief ready for the next phase? Which of three categories fits this case? What information is missing before a recommendation? A useful slice has a recognisable trigger and bounded outcome.

First state who uses the decision and which action depends on it. Then define the required inputs. Anything interesting but irrelevant to the decision stays outside. This limit prevents a system from sounding generally intelligent while helping reliably in no specific case.

The outcome needs a stable form too: a classification with reasoning, a list of missing information, a risk signal or escalation to a specialist. “Generate an answer” is not sufficient. The outcome must enable a sensible next action.

Examples show the normal case; counterexamples show the boundary

A rule remains abstract until cases make it visible. A positive example shows input, relevant observation, applied rule and reasoned outcome. It explains not only what was decided, but what the decision depended on.

Counterexamples are even more valuable. They resemble the normal case but must not produce the same outcome. A mandatory document may be missing, a small exception may change the risk or two statements may conflict. Such cases prevent a system from confusing surface similarity with professional equivalence.

A good knowledge module therefore contains at least one typical case, one difficult borderline case and one prohibited case. The borderline case shows when more review is needed. The prohibited case shows when the system must stop. Contrast gives the rule its shape.

Every rule needs a validity range

Rules become dangerous when they circulate without conditions. Each professional rule needs prerequisites: For which situation, data quality, audience and period does it apply? Which factors override it? Who may confirm an exception?

A validity range need not be complicated. Four fields often suffice: applies when, does not apply when, uncertain when and review again from. This makes visible that knowledge has a state. A proven rule can age when requirements, products or surrounding conditions change.

Exceptions should not be footnotes. A frequent exception may be its own case class. A rare but consequential exception needs a clear escalation signal. Robustness comes not from the largest number of rules, but from explicit transitions between rule, exception and human judgement.

Language models and deterministic logic have different roles

Language models are strong at reading unstructured material, extracting information, asking follow-up questions and explaining reasoning. They are less suited to applying binding rules identically every time or deciding alone whether a hard boundary has been crossed.

A dependable architecture separates interpretation from decision. The model can map information from a text into a fixed schema. A deterministic rule checks required fields, thresholds or prohibited combinations. The model can then explain the result without quietly reinventing the rule.

This separation makes failures localisable. Was information extracted incorrectly? Was the rule incomplete? Or did the case lie outside the validity range? A monolithic prompt mixes these questions. A small expert system turns them into distinct, testable steps.

Knowledge needs provenance, versions and test cases

A professional rule is only as reliable as its foundation. Every rule should carry provenance: a document, observed practice, accountable decision or provisional hypothesis. These categories are not equally strong and should not be treated as equals.

Changes need versions. If a threshold is adjusted or an exception added, it should remain clear which cases are affected and which tests must run again. Without versioning, a system may appear to improve while nobody knows why its outcomes changed.

Test cases are the memory of the expert system. They record how a case should be handled and why. Every significant wrong decision should—after anonymisation and cleaning—become a new test or clearer boundary. The system then grows from verified experience rather than ever longer instructions.

The system supports responsibility; it does not assume it

An expert system can make professional work more accessible and consistent. It can identify missing information, apply rules reliably and explain why a case was escalated. It must not imply that an output is correct merely because formal rules produced it.

People remain responsible for the selection, currency and consequences of rules. They decide which knowledge enters the system, which errors are tolerable and which cases must never close without approval. Even a transparent system can apply a wrong or outdated rule consistently.

The best expert system is therefore not an artificial substitute for expertise. It is a readable collaboration between experience, formal verification and human judgement. It makes visible where knowledge holds—and where it ends.

The decision module

A compact module keeps one bounded professional decision testable in a single place:

# DECISION MODULE

**Decision question**
Which bounded question should be answered?

**Required inputs**
Which information must exist, and which source governs?

**Professional rule**
If …, then …, because …

**Validity range**
Applies when … / not when … / uncertain when …

**Examples**
Normal case, borderline case and prohibited case.

**Deterministic check**
Which required fields, thresholds or combinations are fixed?

**Escalation**
When does the system stop, and who decides then?

**Version and tests**
What changed, and which cases must be rerun?

Experiential knowledge does not become smaller when translated into rules, cases and boundaries. It becomes shareable. The translation must not be confused with simplification: good systems do not preserve every detail of an expert. They preserve the distinctions on which a responsible decision depends.

Worksheet: Build a small expert system

Choose a recurring professional decision with manageable consequences. Do not design a whole product; build one testable decision module.

1. Bound the decision space. Write one question, one user group and the next action. Remove everything that is unnecessary for this decision.

2. Write rule and provenance. Formulate an if-then rule with reasoning. Label whether it comes from a source, practice, decision or hypothesis.

3. Build three contrasting cases. Write a normal, difficult borderline and prohibited case. Explain which detail changes the outcome.

4. Define validity and verification. Add applies when, not when and uncertain when. Choose at least one deterministic check.

5. Define escalation and tests. Write two stop signals, one accountable role and the test cases that rerun after every change.