An expert system is a program that reproduces the decisions of a human specialist in a narrow domain by reasoning over explicitly encoded expert knowledge. It was the first commercially successful form of AI in the late 1970s and 1980s, and its core ideas survive today in business rules engines, clinical decision support, fraud and compliance rules, configuration tools, and the guardrail layers wrapped around LLMs.
Part of Knowledge & Reasoning. The two main families are covered in depth in Rule-based Systems and Knowledge-based Systems.
Five components recur in nearly every expert system:
A product that packages the engine, UI and explanation facility with an empty knowledge base is called an expert system shell (EMYCIN, CLIPS, Jess; today Drools and other business rules management systems).
The term is used loosely, but two styles are worth distinguishing. Rule-based systems encode expertise as flat IF-THEN productions and are the classic expert-system form. Knowledge-based systems use richer structures — frames with inheritance, ontologies, semantic networks, or libraries of past cases — and reason with classification, inheritance or analogy in addition to (or instead of) rules. Most large real systems mix both.
Experts rarely reason in certainties. MYCIN attached certainty factors in [-1, 1] to rules and facts and combined them with simple formulas such as the one above. CFs are easy to elicit and worked well in practice, but they are not probabilities and can behave inconsistently when evidence is correlated. Later systems moved to Bayesian networks for principled probability, Dempster-Shafer theory for explicit ignorance, or fuzzy logic for vague linguistic terms.
DENDRAL inferred molecular structure from mass-spectrometry data; MYCIN recommended antibiotics and introduced backward chaining with explanations; XCON configured VAX computer orders for Digital Equipment Corporation. The 1980s boom was followed by disillusionment when systems proved expensive to build and maintain and brittle outside their narrow scope. The techniques did not vanish: they became business rules engines, decision tables (DMN) and validation layers inside ordinary enterprise software.
# Backward-chaining diagnosis with certainty factors and a HOW explanation.
RULES = [
# (id, conclusion, premises, cf)
("R1", "flu", ["fever", "body_aches", "cough"], 0.7),
("R2", "flu", ["fever", "sudden_onset"], 0.5),
("R3", "cold", ["sneezing", "cough", "no_fever"], 0.6),
("R4", "see_doctor", ["flu", "high_risk"], 0.9),
]
def combine(a, b): # both positive
return a + b * (1 - a)
class Engine:
def __init__(self, facts):
self.facts = dict(facts) # fact -> cf
self.trace = {}
def prove(self, goal):
if goal in self.facts:
return self.facts[goal]
cf_total = 0.0
for rid, concl, prem, cf in RULES:
if concl != goal:
continue
premise_cf = min(self.prove(p) for p in prem) # AND = min
if premise_cf > 0.2: # firing threshold
cf_total = combine(cf_total, cf * premise_cf)
self.trace.setdefault(goal, []).append(rid)
self.facts[goal] = cf_total
return cf_total
def how(self, goal):
return f"{goal} concluded via rules {self.trace.get(goal, [])}"
eng = Engine({"fever": 1.0, "body_aches": 0.8, "cough": 1.0,
"sudden_onset": 0.9, "high_risk": 1.0})
print("flu:", round(eng.prove("flu"), 3))
print("see_doctor:", round(eng.prove("see_doctor"), 3))
print(eng.how("flu"))
Unknown facts default to 0 here; a real system would ask the user, and the explanation facility would answer "WHY?" by showing which rule's premise it is trying to establish.
The knowledge acquisition bottleneck — experts' time and their difficulty articulating tacit knowledge — was historically the main cost. Today rule induction from data (decision trees, association rules) and LLM-assisted drafting of rules from policy documents can lower it, provided a human still reviews the output.
| Strengths | Limits |
|---|---|
| Transparent, explainable decisions | Brittle outside the encoded scope; no graceful degradation |
| Works with little or no training data | Expensive knowledge acquisition and upkeep |
| Instant updates by editing rules | Large rule bases develop hidden interactions |
| Deterministic, auditable for regulators | Poor at perception and noisy, high-dimensional input |
Consider three rules. R1: IF fever AND cough THEN flu_suspected. R2: IF flu_suspected AND age > 65 THEN high_risk. R3: IF high_risk THEN advise_test. A patient is 70 with fever and cough.
Forward chaining starts from the facts. R1 matches and adds flu_suspected; R2 now matches and adds high_risk; R3 adds advise_test. The engine stops when no rule adds anything new. This suits monitoring and configuration, where you want every consequence of the data. Production engines use the Rete algorithm (Forgy, 1982), which caches partial matches so only rules affected by a changed fact are re-evaluated.
Backward chaining starts from a goal: should we advise a test? Only R3 concludes advise_test, so the engine sets high_risk as a sub-goal, which needs flu_suspected and age > 65, which needs fever and cough. Facts that are not known are asked of the user, which is why MYCIN-style consultations feel like a structured interview. It evaluates only rules relevant to the question, and the chain of sub-goals directly supports "why are you asking?" explanations.
MYCIN attached a certainty factor (CF) between −1 and 1 to each rule and conclusion. When two rules independently support the same conclusion with positive CFs a and b, the combined CF is a + b(1 − a). If one rule gives 0.6 and another 0.5, the combined certainty is 0.6 + 0.5·0.4 = 0.8: more evidence raises confidence, but it never exceeds 1. A rule's conclusion CF is the rule's CF times the CF of its premise (using the minimum over AND-ed conditions). Certainty factors were practical but not probabilistically coherent; later work showed they can contradict Bayes' rule under some dependencies, which helped motivate Bayesian networks. Fuzzy logic handles a different problem, vague categories such as "high temperature", rather than uncertain evidence.
Large language models are fluent but not guaranteed to follow a policy exactly, and their reasoning is hard to audit. Rules are the reverse: rigid but exact and traceable. A practical hybrid uses the LLM for what it is good at (turning messy text into structured fields, and turning structured decisions into readable language) and a rule engine or decision table for the decision itself. Eligibility, pricing, compliance and clinical protocols fit this pattern, because the organization can review, version and test the rules independently of the model, and every decision has a rule trace.
The validation burden shifts to the extraction step: test the LLM's field extraction against labeled examples, and make the rule engine reject or escalate when required facts are missing rather than guessing.
Further reading: Buchanan, B. & Shortliffe, E. (1984), Rule-Based Expert Systems: The MYCIN Experiments of the Stanford Heuristic Programming Project; Forgy, C. (1982), "Rete: A fast algorithm for the many pattern/many object pattern match problem"; McDermott, J. (1982), "R1: A rule-based configurer of computer systems" (XCON); Jackson, P. (1998), Introduction to Expert Systems (3rd ed.); Russell, S. & Norvig, P., Artificial Intelligence: A Modern Approach, chapters on logical agents and knowledge representation.