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.