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.