Expert systems: architecture & the five modules

The five-module ES architecture, the shell concept (empty KB), and how the explanation subsystem answers why and how.

What makes a system an expert system

An expert system encodes a large amount of domain-specific knowledge to reach expert-level performance in a narrow domain — strong-method problem solving, in contrast to the weak, domain-general methods (GPS, means-ends) of early AI. Three properties define one: it supports inspection of its reasoning (intermediate steps and explanations), it is easily modified (add or delete a rule with no global side effects), and it reasons heuristically with imperfect knowledge. All three fall out of the production-system architecture and its separation of knowledge from control.

The five modules

A rule-based expert system has five structural modules:

User interface — handles dialogue with the user (Q&A, menu, or graphical).
Knowledge base — the domain rules plus case-specific data (the production rules).
Inference engine — applies the KB to the problem, running the recognize–act cycle (the control, reused across domains).
Explanation subsystem — answers how and why queries.
Knowledge-base editor — helps the knowledge engineer add, debug, and maintain rules.

The key architectural move is separating the inference engine from the knowledge base. Rules are written as natural if-then knowledge rather than code; the same engine can be reused; and editing rules never touches the control software. An expert system shell is precisely this architecture with the knowledge base emptied out — you fill it for a new domain. CLIPS, JESS, and EMYCIN are shells.

Why and how explanation

Because the search proceeds one rule at a time, explanation is almost free in a goal-driven system:

A why query (asked when the system requests information) is answered by showing the current rule being attempted — "I need this because rule R's IF part must hold to conclude my current goal."
A how query (asked about a concluded fact) is answered by tracing the chain of rules that derived it, back to the user-supplied facts.

Contrast a conventional Java program: pausing it mid-line tells you nothing about why that line runs. The rule-at-a-time structure is what makes high-stakes domains (medicine, law) accept expert-system advice.

Worked example

The inference engine itself was built in Module 5 (forward/backward chaining). This lesson is the surrounding architecture. Picture a car-diagnosis ES: the KB holds rules like engine_wont_start ∧ lights_dim → battery_dead; the engine chains them; a why asks "because I am trying to prove battery_dead and rule R needs lights_dim"; a how for battery_dead replays [engine_wont_start, lights_dim] → battery_dead. Strip the rules out and you have a shell ready for a new domain.

The load-bearing line in this stack is the one between the inference engine and the knowledge base: control above, domain rules below, neither able to reach into the other. Lift the highlighted band out and the four remaining modules are an expert system shell — CLIPS, JESS, EMYCIN — waiting for a new domain to be dropped in.