Expert Systems and Rule-Based AI: Rise, Fall and Legacy

In the 1980s, "AI" in industry meant one thing: expert systems. These programs captured the knowledge of human specialists as if–then rules and used it to diagnose diseases, configure computers and approve loans. Studying them teaches us both the power of explicit knowledge and the reasons the field moved towards learning.

Architecture of an expert system#

A classical expert system has five parts:

1. Knowledge base — the domain rules, e.g. IF the infection is meningitis AND the patient is a child THEN consider organism X.
2. Working memory — the facts about the current case.
3. Inference engine — applies rules to facts (forward or backward chaining).
4. Explanation facility — answers "why?" and "how?" questions by showing the chain of rules.
5. Knowledge acquisition interface — tools for knowledge engineers to add and edit rules.

The separation of knowledge from inference was a key insight: the same engine (an "expert system shell") could be reused across domains.

Forward chaining with a tiny rule engine#

RULES = [
    ({"fever", "cough"}, "respiratory_infection"),
    ({"respiratory_infection", "chest_pain"}, "suspect_pneumonia"),
    ({"suspect_pneumonia"}, "recommend_xray"),
    ({"rash", "fever"}, "suspect_measles"),
]

def forward_chain(facts, rules):
    facts = set(facts)
    trace = []
    changed = True
    while changed:
        changed = False
        for premises, conclusion in rules:
            if premises <= facts and conclusion not in facts:
                facts.add(conclusion)
                trace.append(f"{' & '.join(sorted(premises))} => {conclusion}")
                changed = True
    return facts, trace

facts, why = forward_chain({"fever", "cough", "chest_pain"}, RULES)
print(facts)
print("\n".join(why))      # the explanation facility for free

Real engines such as CLIPS and Drools use the Rete algorithm, which avoids re-checking every rule on every cycle by caching partial matches in a network. This makes rule systems with thousands of rules run efficiently.

Conflict resolution#

When several rules can fire, the engine needs a policy: prefer the most specific rule, the most recently added fact, or a rule with higher priority ("salience"). The choice can change the system's behaviour significantly.

Handling uncertainty: MYCIN's certainty factors#

MYCIN (Stanford, 1970s) diagnosed bacterial blood infections with around 600 rules. Because medical evidence is uncertain, each rule carried a certainty factor (CF) in $[-1, 1]$. When two rules support the same conclusion with positive factors $CF_1$ and $CF_2$, MYCIN combined them as

In evaluations, MYCIN's recommendations were judged comparable to those of infectious-disease specialists — impressive for the era — though it was never used routinely in hospitals, due to legal, ethical and integration concerns.

Famous systems#

Why expert systems declined#

1. The knowledge acquisition bottleneck. Experts find it hard to articulate what they know; interviewing them is slow and expensive.
2. Brittleness. Systems failed abruptly outside their narrow domain and had no common sense.
3. Maintenance. Thousands of interacting rules became impossible to update safely.
4. No learning. They could not improve from experience or new data.

Machine learning addressed the first and fourth problems directly: instead of asking experts for rules, learn the mapping from examples.

The legacy is alive#

Rule-based systems never disappeared. They run in business rules engines for insurance and banking, clinical decision support alerts, compliance checks and fraud detection, where auditability matters. Many modern production ML systems are hybrids: a learned model produces a score, and explicit rules enforce hard policy constraints. Moreover, the explanation facility of expert systems foreshadowed today's field of Explainable AI.