Expert systems: architecture & the five modules

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:

1. User interface — handles dialogue with the user (Q&A, menu, or graphical).
2. Knowledge base — the domain rules plus case-specific data (the production rules).
3. Inference engine — applies the KB to the problem, running the recognize–act cycle (the control, reused across domains).
4. Explanation subsystem — answers *how* and *why* queries.
5. 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.