1.

Introduction to Expert Systems

Preface to Chapter 1
This opening chapter serves as the gateway to understanding one of the most commercially
successful branches of Artificial Intelligence. We will explore how the field moved away from
trying to simulate the general human mind toward a more practical goal: emulating the deep,
specialized knowledge of human experts. By defining what an expert system is and how it
differs from the software we use daily, we establish the core vocabulary and concepts that will
support the rest of this handbook.

1.1 What is an Expert System?

An Expert System is a computer program designed to simulate the problem-solving behavior of
a human who is an expert in a narrow, specialized domain. While a typical program might
handle data processing or simple calculations, an expert system handles "knowledge." It is
designed to provide advice, make diagnoses, or recommend solutions in areas where a human
would normally need years of training to be effective. At its core, an expert system is a
"knowledge-based" system—it doesn't just calculate; it reasons using a set of facts and
heuristics (rules of thumb) provided by human specialists.

1.2 The Evolution of Artificial Intelligence

The history of AI is often viewed in stages. Early AI, in the 1950s and 60s, focused on "General
Problem Solvers"—the idea that a few basic laws of logic could solve any problem. However,
these systems were overwhelmed by the complexity of the real world. In the 1970s, researchers
realized that the power of a program lies in its knowledge, not just its logical processing. This
led to the development of early pioneers like DENDRAL (which identified chemical structures)
and MYCIN (which diagnosed blood infections). These successes proved that computers could
be highly "intelligent" if they were given a massive amount of specific information about a tiny
slice of the world.

1.3 The Difference Between Conventional Programming

and Expert Systems
To appreciate expert systems, one must understand how they differ from conventional software.
●​ Control vs. Knowledge: In conventional programs, the "knowledge" and the "control"
(the logic) are integrated into a single sequence of code. In an expert system, the
knowledge is kept separate in a "knowledge base," and the logic is handled by a generic
"inference engine."
●​ Certainty vs. Uncertainty: Conventional programs require all data to be precise and
present; if a single variable is missing, the program may crash. Expert systems are
 designed to handle incomplete or "fuzzy" data, reaching the best possible conclusion
with whatever clues are available.
●​ Transparency: While conventional programs are "black boxes" (you see the input and
the output but not the reasoning), expert systems include an "explanation facility" that
can tell the user exactly which rules it used to reach its conclusion.

1.4 The General Architecture of an Expert System

A standard expert system consists of several interconnected components that separate the
"what" from the "how":
●​ Knowledge Base: The heart of the system, containing the facts and the IF-THEN rules.
●​ Inference Engine: The processor that decides which rules apply to the current situation
and executes them.
●​ Working Memory: A temporary database that stores the facts of the current problem
being solved.
●​ Explanation Facility: The part that explains the system's reasoning to the user.
●​ User Interface: The mechanism through which the user and the system communicate,
often in natural-language-like queries.

1.5 Characteristics of an Expert System

A true expert system possesses several defining traits. First, it must perform at an expert level,
meaning it provides high-quality advice consistently. Second, it must have high-speed
symbolic reasoning, dealing with concepts and relationships rather than just numbers. Third, it
must be robust, meaning it shouldn't fail the moment a problem becomes slightly unusual.
Finally, it must be self-explanatory, allowing a user to audit its logic to ensure the advice is
sound.

1.6 The Human Expert vs. the Artificial Expert

While expert systems are powerful, they are not a perfect replacement for humans. Human
experts have common sense, the ability to learn from metaphors, and the capacity to adapt to
radically new situations. Artificial experts are "brittle"—they are brilliant within their narrow box
but "stupid" the moment they step outside it. However, the artificial expert has distinct
advantages: it is permanent (it doesn't retire or forget), it is easy to document, it is consistent
(it doesn't have "bad days"), and it is low-cost to maintain once developed.

1.7 When to Use an Expert System

Not every problem requires an expert system. They are best suited for tasks that meet specific
criteria:
1.​ Narrow Domain: The problem must be specific (e.g., "fixing a specific type of engine"
rather than "fixing everything").
2.​ Expert Availability: There must be human experts who actually know how to solve the
problem.
3.​ Complexity: The problem must be hard enough to require an expert, but not so hard
that it's impossible to solve.
4.​ Symbolic Nature: The problem should involve logic and reasoning rather than just
intense mathematical "number crunching."
2. The Representation of Knowledge
Preface to Chapter 2
The transition from a human expert’s intuition to a functioning computer program requires a
bridge called Knowledge Representation. In this chapter, we investigate how to formalize the
vast, often messy web of human experience into structured data. We will examine the classical
methods of representing knowledge—logic, rules, and networks—and discuss why the choice of
representation is perhaps the most critical decision in the design of any expert system.

2.1 The Meaning of Knowledge

Before representing knowledge, we must distinguish it from data and information.
●​ Data: Raw facts and figures (e.g., "The temperature is 102 degrees").
●​ Information: Data with context (e.g., "The patient has a temperature of 102 degrees").
●​ Knowledge: The ability to use information to achieve a goal (e.g., "If the patient has a
temperature of 102 degrees, they likely have a fever and should be tested for infection").​
In expert systems, we are specifically interested in Epistemology—the study of the
nature, structure, and origins of knowledge.

2.2 Procedural vs. Declarative Knowledge

Knowledge representation generally falls into two philosophies:
1.​ Procedural Knowledge: Focuses on "how" to do something. It is often represented as a
sequence of steps or actions (e.g., a recipe or a C++ function).
2.​ Declarative Knowledge: Focuses on "what" is true. It describes facts and relationships
without explicitly stating the order in which they should be processed. Expert systems
lean heavily on declarative knowledge, allowing the inference engine to decide the "how"
later.

2.3 Formal Logic

Logic is the oldest and most mathematically rigorous method of representation.
●​ Propositional Logic: Deals with statements that are either true or false. Symbols (P, Q)
represent facts, and connectives ($\neg, \wedge, \vee, \rightarrow$) represent
relationships.
●​ Predicate Logic: An extension of propositional logic that allows us to describe
properties of objects and relationships between them using quantifiers (Universal
$\forall$ and Existential $\exists$). For example, $\forall x (Human(x) \rightarrow
Mortal(x))$.

2.4 Production Rules

Production rules are the most popular representation for expert systems. They follow the form:
IF (condition/premise) THEN (action/conclusion).
●​ Example: "IF the engine does not turn over AND the battery is old, THEN the battery is
dead."​
Rules are intuitive for humans to provide and easy for computers to process in a modular
fashion. Unlike traditional "If-Then" statements in programming, production rules in an
expert system are independent units that are only executed when the "Inference Engine"
determines they are relevant.

2.5 Semantic Networks

A semantic network represents knowledge as a graph of nodes and arcs.
●​ Nodes: Represent objects or concepts.
●​ Arcs (Links): Represent relationships between concepts, such as IS-A (inheritance) or
HAS-A (property).
●​ Inheritance: This is a key benefit; if we know a "Robin" IS-A "Bird," the Robin
automatically inherits properties like "Has Wings" from the Bird node.

2.6 Frames and Schemata

Developed by Marvin Minsky, frames are data structures for representing "stereotypical"
situations.
●​ A frame consists of slots (properties) and fillers (values).
●​ Example: A "Car" frame might have slots for "Wheels" (default 4), "Fuel" (Gas), and
"Engine."
●​ Frames allow for "default reasoning"—if the system knows it's looking at a car, it
assumes it has four wheels unless told otherwise.

2.7 The Knowledge Engineering Process

The act of capturing knowledge from a human and putting it into the system is called
Knowledge Engineering. This involves:
1.​ Knowledge Acquisition: Interviewing experts and observing them at work.
2.​ Formalization: Choosing the right representation (Rules? Frames? Logic?).
3.​ Implementation: Coding the knowledge into the knowledge base.
4.​ Verification: Ensuring the system's knowledge is accurate and doesn't contain
contradictions.

2.8 Meta-Knowledge
Knowledge about knowledge is called Meta-knowledge. For an expert system to be truly
sophisticated, it needs to know its own limitations. This includes knowing which rules are most
important, when to seek more information, and how to resolve conflicts when two rules
disagree.

3. Methods of Inference
Preface to Chapter 3
If knowledge representation (Chapter 2) is the "body" of an expert system, then inference is its
"mind." In this chapter, we explore how the inference engine processes the stored knowledge
base to solve problems. We will move beyond simple IF-THEN logic to examine the formal
structures of reasoning, including how a system searches for answers and how it decides which
path to take when several possibilities exist.

3.1 Reasoning and Inference

Reasoning is the mental process of drawing a conclusion from a set of premises. In an expert
system, we formalize this as Inference. There are three main types of reasoning used in AI:
●​ Deductive Reasoning: Starting with a general rule and applying it to a specific case to
reach a certain conclusion. (e.g., "All birds fly; this is a bird; therefore, it flies.")
●​ Inductive Reasoning: Observing specific patterns and generalizing them into a rule.
●​ Abductive Reasoning: Starting with a set of observations and finding the most likely
explanation (common in medical diagnosis).

3.2 State Space Search

A problem can be viewed as a "state space"—a collection of every possible configuration of the
problem.
●​ Initial State: Where the system starts (the current symptoms or data).
●​ Goal State: The solution (the diagnosis or plan).​
The inference engine must find a path through this space. Because the number of
possible states can be massive, the system must use effective search strategies to avoid
a "combinatorial explosion" of data.

3.3 Trees, Lattices, and Graphs

To navigate the state space, the system uses mathematical models.
 ●​ Trees: A hierarchical structure where each node (except the root) has one parent. This
is the simplest path for reasoning.
●​ Graphs and Lattices: More complex structures where nodes can have multiple parents.
This is common when different sets of facts can lead to the same conclusion. The
inference engine must be able to detect cycles (loops) in these graphs to prevent the
system from getting stuck.

3.4 Forward Chaining (Data-Driven Reasoning)

Forward Chaining starts with the available facts and works toward a goal.
1.​ The system looks at the facts in working memory.
2.​ It finds rules whose "IF" parts match those facts.
3.​ It adds the "THEN" parts (new facts) to memory.​
This process repeats until a goal is found. This is best for "bottom-up" tasks like
monitoring a factory or a stock market, where new data is constantly coming in and you
need to see what it implies.

3.5 Backward Chaining (Goal-Driven Reasoning)

Backward Chaining starts with a goal (a hypothesis) and works backward to see if the facts
support it.
1.​ The system picks a goal (e.g., "The patient has the flu").
2.​ It looks for rules that conclude this goal.
3.​ It then tries to prove the "IF" conditions of those rules.​
If the conditions aren't in memory, the system turns them into sub-goals and keeps
working backward. This is the most efficient method for diagnosis, as the system only
asks for information that is relevant to the hypothesis.

3.6 Conflict Resolution (Priority, Recency, Specificity)

In a real-world system, many rules might "fire" at once. The Conflict Set is the collection of all
rules whose conditions are met. To choose the best one, the inference engine uses Conflict
Resolution:
●​ Priority (Salience): Important rules are given higher weights.
●​ Recency: Rules triggered by the most recently updated facts are preferred to keep the
system "on track."
●​ Specificity: A rule that handles a specific case (e.g., "If it's an Ostrich") is preferred over
a general rule (e.g., "If it's a Bird").

3.7 The Markov Algorithm

The Markov Algorithm is a precursor to modern production systems. It treats reasoning as an
ordered sequence of string replacements. It taught AI researchers that the order in which rules
are placed in a knowledge base can radically change the system's output. While modern
systems are more flexible, the Markov principle remains: the logic of a system is defined by how
it chooses between competing rules.

4. Reasoning Under Uncertainty

Preface to Chapter 4
In a perfect world, an expert system would always have complete, accurate, and consistent
data. However, real-world expertise—whether in medicine, geology, or finance—is plagued by
ambiguity. A doctor might not be 100% sure of a diagnosis, or a sensor might provide a noisy
reading. In this chapter, we explore how expert systems manage "shades of gray." We will move
from the mathematical rigor of classical probability to the more flexible, heuristic approaches like
Certainty Factors and Fuzzy Logic that better mimic human intuition.

4.1 The Nature of Uncertainty

Uncertainty in expert systems arises from several sources. Data may be incomplete (missing
test results), unreliable (a faulty sensor), or vague (a patient saying they feel "a bit warm").
Furthermore, the rules themselves may be uncertain; for example, "If the patient has a cough,
they might have the flu." To be useful, an expert system must have a way to quantify this doubt
and propagate it through the reasoning chain so that the final conclusion reflects a realistic level
of confidence.

4.2 Errors and Induction

Human experts often use Inductive Reasoning, which involves making a general conclusion
based on a limited set of observations. While powerful, induction is inherently uncertain because
a single counterexample can invalidate the conclusion. In expert systems, errors can be
introduced through "noise" in the data or through a knowledge base that contains overly
generalized rules. Understanding the difference between a systematic error (bias) and a random
error is crucial for a knowledge engineer when refining the system's performance.

4.3 Probability Theory and Bayes' Theorem

The most mathematically sound way to handle uncertainty is through Probability Theory. At its
heart is Bayes' Theorem, which provides a formula for updating the probability of a hypothesis
as new evidence becomes available.
●​ Prior Probability: The initial belief in a hypothesis before seeing evidence.
 ●​ Posterior Probability: The updated belief after seeing evidence.​
Bayesian networks are powerful because they allow a system to reason about cause
and effect mathematically. However, they require a massive amount of statistical data
(the "priors") which is often unavailable in many expert domains.

4.4 The Limits of Classical Probability in AI

While probability is mathematically perfect, it often fails in practical expert system design. First,
humans are notoriously bad at providing accurate numerical probabilities; an expert can say a
symptom is "common," but they struggle to say it occurs exactly "22.4% of the time." Second,
classical probability requires that all events be "mutually exclusive and exhaustive," a condition
rarely met in complex real-world scenarios. This led AI researchers to develop "Heuristic"
methods that are less mathematically strict but more aligned with how experts actually think.

4.5 Certainty Factors (The MYCIN Model)

To solve the problems of classical probability, the creators of the MYCIN medical expert system
developed Certainty Factors (CF). A Certainty Factor is a number (typically between -1 and 1)
that represents the "measure of belief" in a fact or rule.
●​ 1.0 means the fact is absolutely true.
●​ -1.0 means the fact is absolutely false.
●​ 0.0 means total ignorance.​
The beauty of CFs is that they allow the system to combine evidence from different
rules. If two different rules suggest the same conclusion, the system uses a specific
formula to "strengthen" the certainty factor of that conclusion, mimicking the way a
human gains confidence when multiple clues point the same way.

4.6 Fuzzy Logic and Linguistic Variables

Developed by Lotfi Zadeh, Fuzzy Logic addresses the problem of vague, "linguistic"
descriptions. In standard logic, a person is either "Tall" or "Not Tall." In Fuzzy Logic, we use
Membership Functions to describe degrees of truth.
●​ A person who is 6'0" might have a "0.8 membership" in the set of "Tall" people.​
Fuzzy logic allows expert systems to use natural language terms like "very hot," "slightly
low," or "moderately fast." This is incredibly useful in control systems (like high-speed
trains or washing machines) where the system needs to make smooth adjustments
rather than abrupt "on/off" changes based on precise thresholds.
5. Inexact Reasoning
Preface to Chapter 5
While Chapter 4 introduced the mathematical and heuristic ways to measure doubt, Chapter 5
deals with the structural challenges of reasoning when the ground is constantly shifting. In
classical logic, once something is proven true, it stays true forever. However, in human
expertise, we often make assumptions that we later discard when we learn more. This chapter
explores the fascinating world of nonmonotonic reasoning, truth maintenance, and the complex
theories that allow machines to reason effectively even when the evidence is incomplete or
conflicting.

5.1 Dealing with Missing Information

In an ideal scenario, a user provides every piece of data an expert system requests. In reality,
users often don't know the answer or find the data too expensive or dangerous to obtain (e.g.,
an invasive medical test). Inexact Reasoning allows a system to function despite these gaps.
●​ Default Reasoning: The system assumes the most likely value for a missing piece of
data (e.g., assuming a patient is not pregnant unless told otherwise).
●​ Impact of Omission: The inference engine must be able to calculate whether the
missing info is "critical." If a rule requires three conditions and one is missing, the system
must decide whether to skip the rule entirely or proceed with a reduced certainty score.

5.2 Nonmonotonic Reasoning

Most traditional logic is Monotonic, meaning the set of true statements only ever grows. If you
learn "Fact A," you never have to un-learn it. However, human reasoning is Nonmonotonic.
●​ Example: If I tell you "Tweety is a bird," you reason that "Tweety can fly." But if I then tell
you "Tweety is a penguin," you must retract your previous conclusion.​
Expert systems use nonmonotonic reasoning to handle "provisional" truths. This requires
a sophisticated tracking system to ensure that when a fact is retracted, all other
conclusions based on that fact are also wiped away to prevent the system from
becoming inconsistent.

5.3 Truth Maintenance Systems (TMS)

A Truth Maintenance System (or Reason Maintenance System) is a component that works
alongside the inference engine to manage dependencies. Its job is to maintain "logical
consistency."
●​ Justification: Every time the system derives a new fact, the TMS records why it
believes that fact (the justification).
●​ Dependency Directed Backtracking: If a contradiction is discovered (e.g., the system
believes both "The engine is on" and "The engine is off"), the TMS looks back through
 the justifications to find the specific assumption that caused the conflict and removes it.
This ensures the knowledge base remains a "sane" and reliable reflection of the world.

5.4 Evidential Reasoning and the Dempster-Shafer

Theory
Sometimes, uncertainty isn't about a single number, but about a "range" of possibilities. The
Dempster-Shafer Theory is a mathematical framework for dealing with Evidential Reasoning.
●​ Unlike Bayesian probability, which requires a probability for every outcome,
Dempster-Shafer allows for Ignorance.
●​ It uses a "Belief" function and a "Plausibility" function. The gap between the two
represents the "Uncertainty Interval."​
This is particularly useful when you have multiple sources of evidence (e.g., different
sensors or different experts) that provide overlapping or slightly conflicting information. It
allows the system to say, "Based on what I know, the truth is somewhere in this range."

5.5 Closed World Assumption vs. Open World

In expert systems, we must decide how to treat things the system doesn't know.
●​ Closed World Assumption (CWA): If a fact is not explicitly stated in the knowledge
base, the system assumes it is false. This is common in database systems and simple
expert systems.
●​ Open World Assumption: If a fact is not known, the system treats it as unknown.​
Choosing between these is a fundamental design decision. A system diagnosing a rare
disease cannot assume the patient doesn't have it just because it's not in the database;
it must acknowledge its own ignorance to avoid dangerous "false negative" conclusions.
6. Design of Expert Systems
Preface to Chapter 6
Building an expert system is a unique software engineering challenge. Unlike traditional
applications where requirements are gathered from end-users, expert systems require the
extraction of deep, often subconscious knowledge from a human specialist. This chapter
focuses on the "Knowledge Engineering" process—the methodology of planning, designing, and
testing a system to ensure it doesn't just process data, but truly reflects the wisdom of an expert.
We will examine the life cycle of these projects and the rigorous methods used to verify that the
system is both accurate and useful.

6.1 The Knowledge Engineering Life Cycle

The development of an expert system follows a structured path known as the Knowledge
Engineering Life Cycle. Because these systems are often experimental, this cycle is typically
iterative and evolutionary rather than linear.
1.​ Planning: Defining the scope, identifying the human expert, and determining the
feasibility.
2.​ Knowledge Acquisition: The intensive process of gathering rules and facts from the
expert.
3.​ Knowledge Representation: Choosing the data structures (rules, frames, etc.) that best
fit the knowledge.
4.​ Implementation: Coding the knowledge into a shell or programming environment.
5.​ Testing and Refinement: Running the system against real-world cases to find gaps in
its logic.

6.2 Knowledge Acquisition and the Knowledge Engineer

The Knowledge Engineer is the bridge between the computer and the human expert. Their
primary task is Knowledge Acquisition—eliciting the "how" and "why" behind an expert's
decisions. This is often difficult because experts frequently use intuition and may not be
consciously aware of the specific rules they follow. The engineer must use various techniques,
such as:
●​ Interviews: Both structured and unstructured conversations.
●​ Protocol Analysis: Asking the expert to "think out loud" while they solve a real-world
problem.
●​ Observation: Watching the expert work in their natural environment to catch subtle cues
and habits.

6.3 The Bottleneck of Knowledge Acquisition

The "Knowledge Acquisition Bottleneck" is the most famous challenge in AI. It refers to the fact
that extracting knowledge from a human is a slow, expensive, and error-prone process. An
expert's time is valuable and scarce, and translating their nuanced understanding into rigid
IF-THEN rules often leads to a "loss of fidelity." To overcome this, modern designers sometimes
use Automated Knowledge Acquisition tools, which allow experts to enter rules directly into
the system or use machine learning to induce rules from existing data.

6.4 System Selection and Justification

Not every problem should be solved with an expert system. A critical part of design is
Justification. An expert system is justified only if:
●​ The problem is narrow and well-defined.
●​ There are recognized experts who can solve it.
●​ The problem is complex enough that it isn't trivial, but not so complex that it requires
"general common sense."
●​ There is a high payoff for capturing the expertise (e.g., the expert is retiring, or the
knowledge needs to be distributed to many locations).

6.5 Verification and Validation (V&V)

Once a system is built, it must be rigorously tested through Verification and Validation:
●​ Verification ("Building the system right"): This is a technical check. Does the code
run correctly? Are there any redundant or contradictory rules? Does the inference engine
follow the intended logic?
●​ Validation ("Building the right system"): This is a performance check. Does the
system's advice match the advice of the human expert? Does it solve the real-world
problem effectively?​
Validation often involves "blind testing," where both the system and a human expert are
given the same cases, and their answers are compared by an independent panel of
specialists.

6.6 User Interface and Explanation Facility

A poorly designed interface can render the most brilliant knowledge base useless. The User
Interface must allow for a natural dialogue, often utilizing "menu-driven" or "natural language"
interactions. Crucially, the system must include an Explanation Facility. When the system
provides a conclusion, the user must be able to ask:
●​ How? (The system shows the chain of rules it used).
●​ Why? (The system explains why it is asking a particular question).​
This transparency is what builds user trust and allows the system to be used as a
teaching tool for novices.
7. Introduction to CLIPS
Preface to Chapter 7
Up to this point, we have discussed the philosophy and logic behind expert systems. Chapter 7
introduces CLIPS (C Language Integrated Production System), a productive development and
delivery expert system tool which provides a complete environment for the construction of
rule-based and/or object-based expert systems. Created by NASA’s Johnson Space Center, it
has become one of the most widely used expert system tools in the world.

7.1 What is CLIPS?

CLIPS is a type of programming language designed specifically to handle "knowledge." Unlike
procedural languages (like C or Java) where you define a sequence of steps, CLIPS is
data-driven. The program responds to changes in data (facts) rather than following a rigid
pre-defined path.

The Three Basic Components:

1.​ Fact-List: A global memory for data.
2.​ Knowledge Base (Rule-Base): Contains all the rules (the program).
3.​ Inference Engine: The "brain" that decides which rules should execute based on the
current facts.

7.2 Basic CLIPS Syntax: Fields and Symbols

CLIPS syntax is inspired by LISP and uses a prefix notation enclosed in parentheses.
●​ Fields: The basic unit of information in CLIPS. They can be symbols (words), numbers,
or strings.
●​ Symbols: Must start with a printable ASCII character (excluding special delimiters like (,
), &, etc.).
●​ Case Sensitivity: CLIPS is case-sensitive; Apple and apple are different symbols.

7.3 Managing Facts

Facts are the "chunks" of information the system knows.
●​ Entering Facts (assert): You add facts to the fact-list using the assert command.
○​ Example: (assert (duck))
●​ Viewing Facts (facts): Displays the current list of facts in memory.
●​ Removing Facts (retract): Removes a fact by its index number.
○​ Example: (retract 0)
●​ Clearing Memory (clear): Removes all facts and rules from the environment.

7.4 The deffacts Construct

Entering facts manually via assert is tedious. The deffacts construct allows you to define a set of
facts that are automatically loaded into memory when the reset command is issued.

(deffacts status-of-animals
(animal duck)
(animal dog)
(animal cat))

7.5 The Components of a Rule (defrule)

A rule in CLIPS is the implementation of an IF-THEN statement. It consists of the Left-Hand
Side (LHS) and the Right-Hand Side (RHS), separated by the symbol =>.
●​ LHS (The IF part): Contains patterns to be matched against the fact-list.
●​ RHS (The THEN part): Contains actions to be performed if the patterns are matched.

Example Rule:
(defrule duck-sound
(animal duck) ; Pattern (LHS)
=>
(printout t "Quack!" crlf)) ; Action (RHS)

7.6 The Agenda and Execution

When facts match the LHS of a rule, the rule is placed on the Agenda.
●​ The Agenda: A list of rules whose conditions have been met but have not yet executed.
●​ The run Command: This command triggers the Inference Engine to start firing rules
from the agenda.
●​ Refraction: A fundamental concept in CLIPS. Once a rule fires on a specific set of facts,
it will not fire again on those same facts. This prevents the system from getting stuck in
infinite loops (e.g., repeatedly printing "Quack!").

7.7 Variables and Pattern Matching

Variables allow rules to be generic. In CLIPS, variables begin with a question mark (?).
●​ Example: (animal ?name) will match (animal duck), (animal dog), or any fact following
that pattern.
●​ The variable ?name is "bound" to the value found in the fact, which can then be used on
the RHS.

Summary of Chapter 7
●​ CLIPS provides a toolset for building expert systems based on facts and rules.
 ●​ Facts are stored in the fact-list; Rules are stored in the knowledge base.
●​ The Inference Engine automatically matches facts to rules using a process called
Pattern Matching.
●​ Rules move to the Agenda before they are executed with the run command.

8. Advanced Pattern Matching in CLIPS

Preface to Chapter 8
In Chapter 7, we learned the basics of defining rules and asserting facts. However, real-world
expert systems require more than just simple matches; they need the ability to compare values,
exclude specific data, and perform logical operations across multiple conditions. Chapter 8
explores the "Advanced Pattern Matching" capabilities of CLIPS. We will examine how field
constraints, mathematical expressions, and complex logical operators (AND, OR, NOT) provide
the precision necessary to build sophisticated, high-performance knowledge bases.

8.1 Field Constraints

Field constraints allow a rule to be more selective about the data it matches. Instead of just
matching a variable, we can restrict what that variable is allowed to be.
●​ The Literal Constraint: Matches a specific value.
●​ The Connective Constraint (~): The "Not" constraint. It matches anything except the
specified value. For example, (color ~red) matches any color fact as long as the color is
not red.
●​ The Pipe Constraint (|): The "Or" constraint. It allows a field to match one of several
possibilities. For example, (color red|blue|green).
●​ The Ampersand Constraint (&): The "And" constraint. It is often used with other
constraints to create a range. For example, ?x&~red matches a value and binds it to ?x,
provided it is not red.

8.2 Functions and Expressions in Patterns

CLIPS allows you to perform calculations or evaluate functions directly within the Left-Hand
Side (LHS) of a rule. This is done using the Return Value Constraint or "equals" sign (=).
●​ Example: (person (age ?a&:(>= ?a 18)))​
In this case, the colon (:) acts as a "predicate constraint," allowing the rule to fire only if
the function following it returns "true." This is essential for systems that deal with
numerical thresholds, such as financial or medical monitoring systems.
8.3 The "And", "Or", and "Not" Conditional Elements
While individual patterns in a rule are implicitly linked by an "AND" relationship, CLIPS provides
explicit Conditional Elements (CE) to handle more complex logic:
●​ The and CE: Groups patterns together. While usually default, it is useful when nested
inside an or.
●​ The or CE: Allows a rule to fire if any of the listed patterns are matched. It effectively
creates multiple versions of the rule internally.
●​ The not CE: This is a "nonexistence" constraint. It allows a rule to fire only if a specific
fact is not present in the fact-list. This is a powerful tool for nonmonotonic reasoning (as
discussed in Chapter 5).

8.4 The "Test" and "Exists" Conditional Elements

●​ The test CE: Unlike constraints attached to a specific field, the test element is a
standalone pattern that evaluates a boolean expression. If the expression is false, the
rule will not enter the agenda.
●​ The exists CE: This is used to see if at least one fact of a certain type exists. Unlike a
standard pattern, exists does not care how many facts match; it only triggers once. This
is useful for preventing a rule from firing dozens of times when a single confirmation is
sufficient.

8.5 The "Forall" and "Accumulate" Elements

For even more advanced logic, CLIPS offers:
●​ The forall CE: This allows a rule to fire only if every fact that matches a certain criteria
also matches a second criteria. For example: "If all students in the class have passed
the exam, then close the course."
●​ The accumulate CE: This allows the system to perform a calculation (like a sum or
average) across all facts that match a pattern and then use that result in the rule's logic.

8.6 Variable Bindings and the "Logical" CE

We can bind an entire pattern to a variable using the ? address symbol (e.g., ?fact-address <-
(animal duck)). This is crucial for the Right-Hand Side (RHS) if we want to retract or modify the
specific fact that triggered the rule.

Furthermore, the logical CE creates a dependency: if the fact that triggered a "logical" rule is
retracted, any facts asserted by that rule’s RHS are automatically retracted by the system (Truth
Maintenance).
9. Modular Design and Execution Control
Preface to Chapter 9
As expert systems grow from simple prototypes into complex, industrial-grade applications, the
"flat" structure of having hundreds of rules in a single space becomes a liability. Chapter 9
addresses the architecture of large systems. We will explore how to partition knowledge using
modules, how to create custom procedural logic using functions, and how to control the
"saliency" of rules to ensure the inference engine remains efficient and predictable. This chapter
concludes our deep dive into the engineering of expertise.

9.1 Deffunctions and Defgeneric

While CLIPS is primarily a rule-based language, it often needs to perform procedural tasks (like
calculating a square root or formatting a string).
●​ deffunction: Allows you to define your own procedural functions using a LISP-like
syntax. These functions can be called from the RHS (actions) or LHS (logic) of any rule.
●​ defgeneric: This provides "method overloading" or polymorphism. You can define a
generic function name and then create multiple specific "methods" for it that handle
different types of data (e.g., a draw function that behaves differently for a circle versus a
square).

9.2 Defmodules and Name Scoping

To manage complexity, CLIPS uses Defmodules. A module acts as a "namespace" or a
compartment for related rules, facts, and templates.
●​ Focus: At any given time, the inference engine has a "focus" on one specific module.
Rules in other modules will not fire unless the focus is shifted.
●​ Export and Import: Modules can share knowledge. You can "export" a template from
one module and "import" it into another. This allows for a clean separation of
concerns—for example, having one module for "Data Gathering," another for
"Diagnosis," and a third for "Reporting."

9.3 Conflict Resolution in CLIPS (Saliency)

We previously discussed conflict resolution strategies like Recency and Specificity. CLIPS
allows the developer to override these using Saliency.
●​ Saliency is a numerical priority (typically from -10,000 to 10,000) assigned to a rule.
●​ Rules with higher saliency are placed higher on the agenda and will fire before rules with
lower saliency, regardless of when their facts were added.
●​ Caution: While powerful, overusing saliency can make a system hard to debug because
it forces a procedural "order" onto what should be a declarative, data-driven system.
9.4 Integration with Procedural Languages
One of the greatest strengths of CLIPS is its ability to be "embedded." Because it is written in C,
it can be easily integrated into larger software systems.
●​ Embedded CLIPS: You can call CLIPS from a C, C++, or Java program, passing data
into the fact-list and retrieving the results of the inference process.
●​ User-Defined Functions: You can write a function in C and "register" it with CLIPS,
allowing your rules to trigger hardware actions, query external databases, or update a
web interface.

9.5 Global Variables (Defglobal)

Standard CLIPS variables exist only within the scope of a single rule. To maintain a value
across many rules or modules, we use Defglobal.
●​ Globals are useful for tracking system-wide states, such as a "risk-level" in a financial
system or a "current-mode" in a flight controller.
●​ They provide a stable reference point that stays constant while the fact-list is rapidly
changing.

9.6 Summary of the Knowledge Engineering Journey

Throughout this handbook, we have moved from the abstract definition of an "Expert" to the
literal code required to build one. We have seen that:
1.​ Knowledge is the power; the engine is just the vehicle.
2.​ Representation (rules, frames, logic) must match the problem domain.
3.​ Uncertainty is a feature of the real world, not a bug to be ignored.
4.​ Modular Design is the only way to ensure a system remains maintainable as it matures.

With the tools provided in CLIPS and the theories of inference and uncertainty, you are now
equipped to capture human wisdom and preserve it within a machine.