Basic Components of an Expert System

An expert system is typically built from several interacting components: a knowledge base, an inference engine, a working memory, and—commonly—interfaces for users and knowledge engineers, plus an explanation facility.

A standard way to understand the architecture is: the user provides a problem; the system stores problem-specific facts in working memory; the inference engine repeatedly selects and applies rules from the knowledge base; the explanation facility records (and later presents) the reasoning; and the user interface handles dialogue and outputs results. A simplified conceptual diagram is shown below.

These components collectively enable (i) knowledge representation, (ii) goal-directed or data-driven reasoning, (iii) state management for a particular consultation, and (iv) transparency through explanations. 3

Key component glossary (what each part does)

When describing “basic components,” it helps to group them by function:

• Knowledge base: the “expert’s know-how” encoded in a usable form (commonly rules such as IF–THEN, plus domain facts).
• Inference engine: the “mechanism” that performs inference by matching conditions and updating conclusions.
• Working memory: the “blackboard-like” per-session store of facts derived and provided during the current problem-solving run.
• User interface: the “front door” for entering queries and viewing results.
• Explanation facility: the “why” layer that reports how the system reached its answer.
• Knowledge acquisition: methodology/module for obtaining and updating the knowledge base content. 3

Pro Tip: In many textbooks, “basic components” refer to the trio knowledge base + inference engine + working memory, with the UI and explanation as supporting components that make the system usable and trustworthy. 2

1) Knowledge base

The knowledge base is where domain expertise is encoded so the inference engine can reason. In classic expert systems, the most common representation is production rules (IF–THEN), optionally supported by a structured set of domain facts. Such encoding is what makes the system “expert-system-like” rather than generic search. 2

A useful way to describe it for learners:

• Rules capture “if conditions then conclusions” expertise.
• Facts describe known domain entities and relationships.
• Constraints/validation knowledge may prevent contradictions or detect impossible situations (depending on implementation).

Warning: If the knowledge base is incomplete or inconsistent, the inference engine will still produce answers—but they may be wrong or unstable. Explanation facilities help diagnose this by revealing which rules were fired. 2

2) Inference engine

The inference engine performs the reasoning by applying rules over the working memory. Two major strategies used in many expert systems are:

• Forward chaining: starts from facts and repeatedly applies rules to infer more facts until a goal is reached.
• Backward chaining: starts with a goal and searches for rules that could prove it, often asking for missing evidence.

These strategies are described as fundamental reasoning modes for rule-based expert systems and are typically implemented as part of the inference mechanism or conflict-resolution policy. 2

3) Working memory (state)

The working memory holds the facts relevant to the current consultation. It changes as the inference engine fires rules and derives new conclusions.

Key learning points:

• Working memory is session-specific (it resets for a new problem).
• It is the “live” dataset the inference engine matches against.
• It commonly contains:
  • user-provided facts
  • derived facts (intermediate conclusions)
  • possibly a history/trace used for explanation

This “state store” concept distinguishes expert systems from static rule evaluation: the system is effectively performing incremental reasoning. 3

4) User interface

The user interface is responsible for communication:

• collecting inputs (questions, observations, goals)
• validating user responses
• presenting final conclusions and, optionally, intermediate findings

In many real expert system shells, the UI also supports interactive questioning, so the system can request missing information required for rule firing. 2

5) Explanation facility (justification / trace)

The explanation facility records the reasoning process so the system can answer “Why?” and “How?” It typically:

• logs which rules were fired
• records which working-memory facts satisfied each rule condition
• produces a human-readable explanation (often a chain of rule firings)

This improves user trust, supports debugging of the knowledge base, and helps with educational use-cases where the user wants to learn the rationale, not just the answer. 2

Pro Tip: When you describe the explanation facility, mention traceability: the system should link conclusions back to the exact rule firings and the supporting facts.

6) Knowledge acquisition (knowledge engineering support)

While not always counted in the smallest “core three,” knowledge acquisition is essential for building and maintaining an expert system:

• interviewing experts
• extracting decision criteria
• converting them into formal rules/facts
• validating coverage and consistency

Some systems separate this into a dedicated module or workflow, often supported by a “shell” environment (tools for knowledge base management and inference control). 2