Expert systems: production rules, Rete, MYCIN and XCON

An expert system is a program that solves problems in a narrow specialist domain by applying a knowledge base of rules elicited from human experts through a general-purpose inference engine. Because its knowledge is a set of readable rules, it can explain each conclusion by listing the rules and facts that produced it.

1. What an expert system is

An expert system is the most commercially successful form of symbolic AI. It has three parts:

• A knowledge base of domain rules (“if the organism is gram-negative and rod-shaped and anaerobic, then it is probably Bacteroides”), usually a few hundred to a few thousand of them.
• A working memory (or case database) holding the facts of the problem at hand: this patient’s lab results, this customer’s computer order.
• An inference engine, a domain-independent program that decides which rules apply to the current facts and applies them. Swap the knowledge base and the same engine reasons about a different field.

Most systems also have an explanation facility that answers “why are you asking this?” and “how did you conclude that?” from the rule trace, and a knowledge-acquisition interface for adding and editing rules. The founding lesson came from DENDRAL at Stanford: performance comes from large amounts of specific domain knowledge more than from a clever general reasoning method. Edward Feigenbaum called the work of building such systems knowledge engineering [16]. The broader history of the 1980s expert-system boom and bust is on the history of symbolic AI.

2. Production systems and the inference engine

2.1 Production systems

What it is. A production system is a set of condition–action rules (productions) plus a working memory of facts and an interpreter that repeatedly fires rules whose conditions match. The term comes from the logician Emil Post, whose 1943 “productions” were string-rewriting rules used to study formal systems [1]. Allen Newell and Herbert Simon adopted production systems as a model of human problem solving in Human Problem Solving (1972) [2], and from there they became the standard architecture for rule-based expert systems. The psychological line of this work, which leads to Soar and ACT-R, is on cognitive architectures.

A rule. A production has a left-hand side of condition elements that may contain variables, and a right-hand side of actions that add, delete or modify facts:

Limits. Each rule is easy to read alone; what a thousand rules do together is not. Rule interactions, firing order and silent conflicts are the main source of bugs in production systems.

2.2 The match–select–act cycle

The interpreter runs one loop, called the recognize–act cycle. Write $P$ for the rules, $W_t$ for working memory at cycle $t$, and $\theta$ for a substitution of constants for the rule’s variables:

The loop halts when the conflict set ${\mathrm{CS}}_t$ is empty or a rule executes a halt action. Subtracting ${\mathrm{Fired}}_t$, the instantiations already fired, is refraction: the same rule never fires twice on the same facts.

2.3 Conflict resolution

When several instantiations match, the conflict-resolution strategy chooses. The usual ingredients are refraction (do not refire on the same facts), recency (prefer instantiations that use the most recently added facts, which keeps the system focused on its current line of work), specificity (prefer rules with more conditions, so exceptions override general rules), and explicit priority or salience numbers. The choice changes behaviour, not just speed: two engines with the same rules and different strategies can reach different conclusions. That sensitivity is one reason large rule bases were hard to validate.

2.4 OPS5

What it is. OPS5 (“Official Production System”) is the forward-chaining production-rule language Charles Forgy developed at Carnegie Mellon; its user’s manual was published as technical report CMU-CS-81-135 in July 1981 [3]. Working-memory elements are attribute–value records; rules test them with patterns and variables; the interpreter runs the recognize–act cycle using Forgy’s Rete match algorithm. OPS5 offered two conflict-resolution strategies: LEX, which orders instantiations by the recency of all the facts they use, and MEA (means–ends analysis), which gives priority to the recency of the fact matching the rule’s first condition, typically the current goal.

Where it mattered. OPS5 was the language of R1/XCON (§5.3), the first widely cited commercial expert-system success, and the model for later engines: the forward-chaining, Rete-based design of CLIPS, Jess and Drools descends from this line. Limits. Control was implicit in the conflict-resolution strategy, so programmers encoded sequencing with “goal” or “phase” facts, which made programs hard to read.

2.5 Forward chaining

Forward chaining is data-driven inference: start from the known facts, fire every rule whose conditions hold, add the conclusions, and repeat until no rule adds anything new (or a goal fact appears). The match–select–act cycle above is forward chaining with a one-rule-at-a-time selection policy. It suits problems where the data arrive first and many conclusions are wanted: configuration (XCON), monitoring, event processing, eligibility and pricing rules. For pure Horn-clause rules with no deletions, forward chaining reaches a unique fixed point whatever the firing order; the proof and a worked example are on What is symbolic AI? [21] Limits: it derives everything derivable, including facts irrelevant to the question, which wastes work when only one answer is needed.

2.6 Backward chaining

Backward chaining is goal-driven: start from a hypothesis, find rules whose conclusion would establish it, and treat their conditions as sub-goals, recursively, until each sub-goal is a known fact, or a question the system can ask the user. MYCIN worked this way: to decide which organisms to treat, it pursued the goal “identity of the organism”, and every condition it could not derive became a question to the physician, asked only when relevant. Prolog is also backward chaining, with resolution and depth-first search (see logic programming and theorem proving). It suits diagnosis and classification, where there are a moderate number of candidate conclusions and data are expensive to gather. Limits: it can loop on recursive rules without extra bookkeeping, and it re-derives shared sub-goals unless results are cached. Many engines, including Drools, support both directions.

3. Fast matching: the Rete algorithm

3.1 The Rete algorithm

What it is. Rete (Latin for “net”) is Charles Forgy’s algorithm for the many pattern / many object match problem: find every instantiation of every rule against every fact, cycle after cycle. Forgy first described it in a 1974 working paper, developed it in his 1979 Carnegie Mellon PhD thesis, and published the standard account in Artificial Intelligence in 1982 [4].

The problem it solves. A naive interpreter re-tests every condition of every rule against all of working memory on every cycle. But one cycle changes only a few facts, and many rules share the same conditions. Rete exploits both regularities:

• State saving (temporal redundancy). Rete stores partial matches between cycles. When a fact is added or removed, only the consequences of that change are computed; nothing already matched is re-matched.
• Node sharing (structural similarity). Rules are compiled into one network. A condition that appears in several rules is tested once, and a join that several rules begin with is computed once.

How it works. The alpha network tests single facts against single conditions and stores the passing facts in alpha memories. The beta network is a chain of two-input join nodes that combine partial matches with the next condition, checking that shared variables agree; results are stored in beta memories. A complete match reaching a rule’s terminal node enters the conflict set.

Take the two rules from §2.2. Both begin with $\mathrm{Order}\left(o\right)\wedge \mathrm{Has}(o,\mathrm{cpu})$. Rete builds three alpha memories and two joins, the first of them shared:

Compiled separately, the two rules would need five condition tests and three joins; shared, they need three tests and two joins. The larger saving is incremental. Joins distribute over union, so when a new fact $w$ arrives only the new part is computed:

Adding Has(o9, disk) touches only ${\alpha }_3$ and one join against the stored ${\beta }_1$; R1 is not looked at, and ${\beta }_1$ is not recomputed.

Where it is used today. Rete and its descendants sit inside CLIPS, Jess and, as the ReteOO implementation, older Drools versions; Forgy later built commercial successors. Limits. Rete trades memory for time: beta memories can grow large, and a rule whose conditions join badly (a cross product before a selective test) can make them explode. Deleting facts is as costly as adding them. Its cost per cycle depends on how much the cycle changes, which is why it is often described as largely insensitive to the number of rules; a workload that changes most of working memory every cycle gets little benefit.

3.2 TREAT and lazy matching

Daniel Miranker’s TREAT (1987) drops beta memories and recomputes joins on demand, arguing that in many programs the stored partial matches cost more to maintain than they save [5]. The same trade-off drives modern “lazy” matchers: Drools’s PHREAK, the default since Drools 6, evolved from its Rete implementation but delays join work until a rule could actually fire, so rules without data in all their joins cost little [22].

4. Reasoning under uncertainty

4.1 Certainty factors (MYCIN)

What they are. Medical rules are rarely certain: a set of findings “suggests” an organism. Edward Shortliffe and Bruce Buchanan’s certainty-factor model (1975) attaches to each rule and each conclusion a number in $[-1,1]$: +1 means definitely true, −1 definitely false, 0 no evidence either way [6]. It was defined from a measure of increased belief and a measure of increased disbelief, $\mathrm{CF}=\mathrm{MB}-\mathrm{MD}$.

How it works. Three rules propagate the numbers.

1. Premise. A conjunction of conditions is as certain as its weakest part: the premise tally is the minimum of the conditions’ CFs. MYCIN treated a premise as satisfied only if the tally exceeded 0.2, a pragmatic threshold for pruning the search [7].
2. Rule application. A rule with strength ${\mathrm{CF}}_{\mathrm{rule}}$ contributes ${\mathrm{CF}}_{\mathrm{rule}}\times \mathrm{tally}$ to its conclusion.
3. Combination. Two contributions $X$ and $Y$ to the same hypothesis combine as follows. This is the form used in MYCIN and every EMYCIN system from about 1977, after Bill van Melle redefined the mixed-sign case [7]:

Worked example. Two rules support a hypothesis with 0.6 and 0.4: $0.6+0.4(1-0.6)=0.76$. Support grows but never passes 1. The mixed-sign case fixed a real failure. Under the original definition, eight or nine supporting rules could push cumulative belief to about 0.999, and a single disconfirming rule with CF 0.8 would then leave $0.999-0.8=0.199$, below the 0.2 threshold: one piece of negative evidence wiped out the rest. The revised function gives $0.199/(1-0.8)\approx 0.99$, while two nearly balanced contributions still cancel: $(0.55-0.5)/(1-0.5)=0.1$ [7]. The function is commutative and associative, so evidence can be folded in one rule at a time in any order.

Limits. Certainty factors are not probabilities. David Heckerman showed in 1986 that the original definitions are inconsistent with the combining functions, and that any consistent probabilistic reading implies conditional-independence assumptions that most real domains violate, so evidence can be over-counted as rule sets grow [8]. The model survives in shells and textbooks; for new systems, Bayesian networks and other probabilistic models replaced it.

4.2 Subjective Bayesian inference (PROSPECTOR)

PROSPECTOR took the probabilistic route. Richard Duda, Peter Hart and Nils Nilsson’s subjective Bayesian method (1976) gives each rule $E\to H$ two expert-supplied numbers, a sufficiency factor $\mathrm{LS}$ and a necessity factor $\mathrm{LN}$, and updates the odds of the hypothesis by Bayes’ rule in odds form [9]:

An $\mathrm{LS}$ of 10 means observing the evidence multiplies the odds by ten. When the evidence itself is uncertain, PROSPECTOR interpolated between the two updates. It shares the certainty-factor model’s weakness: chaining many rules multiplies odds as if the pieces of evidence were independent.

5. The classic expert systems

5.1 DENDRAL

Begun at Stanford in 1965 by Edward Feigenbaum, Joshua Lederberg, Bruce Buchanan and the chemist Carl Djerassi, DENDRAL inferred the structure of organic molecules from mass-spectrometry data and is usually called the first expert system [10]. It worked by plan–generate–test: a planner used chemistry knowledge to derive constraints from the spectrum, a generator enumerated only the molecular graphs consistent with them, and a tester predicted each candidate’s spectrum and ranked the fit. Its sibling Meta-DENDRAL learned new fragmentation rules from spectra of known molecules, an early case of machine learning producing readable rules. DENDRAL’s lesson, that performance lay in specific knowledge, shaped everything after it.

5.2 MYCIN

MYCIN was developed at Stanford in the early 1970s as Edward Shortliffe’s doctoral work, with Bruce Buchanan, Stanley Cohen and others, and written in Lisp [11]. It identified bacteria causing severe infections such as bacteremia and meningitis and recommended antibiotics, using about 600 backward-chaining rules with certainty factors. A typical rule: if the stain of the organism is gram-negative, and its morphology is rod, and its aerobicity is anaerobic, then there is suggestive evidence (0.6) that the organism is Bacteroides. In a blinded evaluation on ten meningitis cases published in 1979, experts rated MYCIN’s therapy acceptable in 65% of cases, against 42.5% to 62.5% for five faculty members [12]. It was never used clinically: consultations meant typing answers to its questions at a terminal outside the clinical workflow of the time, and liability questions were unresolved. Its influence came through EMYCIN, TEIRESIAS and its explanation facility (§6).

5.3 XCON (R1)

R1, called XCON inside Digital Equipment Corporation, was written by John McDermott at Carnegie Mellon as an OPS5 production system to configure VAX-11/780 computer orders: given a customer’s order, it worked out what was missing and how the components should be laid out. It went into use at DEC’s plant in Salem, New Hampshire, in 1980 [13]. McDermott’s 1982 paper describes 772 rules; the rule base kept growing through the 1980s as DEC’s product line grew, and by contemporary estimates the system saved DEC tens of millions of dollars a year [14]. R1 is forward chaining at its most natural: the order arrives as data, and rules fire as partial configurations make them applicable. It is also the textbook case of maintenance cost. DEC’s product line changed constantly, and keeping the rule base consistent took a permanent team of knowledge engineers.

5.4 PROSPECTOR

PROSPECTOR was built at SRI International in the late 1970s by Richard Duda, Peter Hart and colleagues to assess mineral-exploration sites, combining geologists’ ore-deposit models as inference networks with the subjective Bayesian updating of §4.2. In 1982 it became the first reported case of a computer program locating previously unknown ore: given pre-drilling exploration data for Mount Tolman in Washington State and rules from a porphyry-molybdenum specialist, it identified the location of ore-grade mineralization that drilling confirmed [15].

6. Shells, knowledge engineering and explanation

6.1 Expert-system shells

A shell is an expert system with the domain knowledge taken out: an inference engine, rule language, explanation facility and editing tools, ready to be filled with rules for a new field.

• EMYCIN (“Empty MYCIN”), by William van Melle at Stanford (1979), is usually called the first shell: MYCIN’s domain-independent core of backward chaining, certainty factors, explanation and knowledge-acquisition routines [17]. It was used to build consultation systems in several areas of medicine, such as PUFF for pulmonary-function tests, and in engineering, such as SACON for structural analysis.
• CLIPS (C Language Integrated Production System) was prototyped at NASA’s Johnson Space Center in spring 1985 because Lisp-based tools did not fit NASA’s operational computers; version 3.0 was released in July 1986 [18]. It is a forward-chaining, Rete-based engine in portable C, public domain, and still maintained.
• Jess, from Sandia National Laboratories, brought a CLIPS-like rule language to Java in the 1990s and influenced the Java rule engines that followed.

The 1980s market sold shells on the promise that experts could write rules themselves. In practice the hard part was the knowledge, not the engine.

6.2 Knowledge engineering

Knowledge engineering is the discipline of eliciting, structuring, encoding and maintaining expert knowledge. Feigenbaum put the term in the title of his 1977 IJCAI paper, which drew the field’s lessons from DENDRAL and MYCIN [16], and Building Expert Systems (Hayes-Roth, Waterman and Lenat, 1983) codified the process [19]: identify the problem, conceptualise its key concepts, formalise them, implement, and test with the expert, in a loop. Elicitation techniques include structured interviews, think-aloud protocol analysis and repertory grids. Later methodologies such as CommonKADS (2000) shifted from extracting rules to building explicit models of tasks and domains [20]. Randall Davis’s TEIRESIAS (1976) was an early tool that helped experts debug MYCIN’s rules by tracing a wrong conclusion back to the rule that caused it [7].

6.3 The knowledge-acquisition bottleneck

The limiting cost of an expert system is getting knowledge in. Feigenbaum identified this as the key bottleneck in 1977 [16]. Experts often cannot state the rules they follow; what they say and what they do differ; rules elicited from different experts conflict; and the knowledge keeps changing, as XCON’s product catalogue did. Every new rule can interact with every old one, so maintenance cost grows faster than the rule base. The bottleneck is a large part of why the 1980s boom ended, and it is the main reason machine learning, which acquires its knowledge from data, took over.

6.4 Explanation facilities

Because conclusions come from rule firings, an expert system can explain itself exactly. MYCIN answered WHY (why are you asking this question? because it is a condition of the rule being tried, which serves this goal) and HOW (how did you conclude this? by these rules, from these facts). The explanation is the reasoning trace, not a post-hoc rationalisation, which is the property the pillar page calls a faithful explanation. Its limit is that it explains the rules, not whether the rules are right.

7. Expert systems today: business rules engines

7.1 Business rules engines

The expert system never disappeared; it was renamed. A business rules engine is a production system used to keep decision logic (pricing, eligibility, underwriting, fraud screens, claims handling, tax and compliance rules) outside application code, where analysts can read and change it.

• Drools, created by Bob McWhirter and Mark Proctor, is an open-source Java business rules management system with forward and backward chaining, a Rete-derived engine (PHREAK) and its own rule language, DRL. It is developed in the KIE community, which entered the Apache Incubator in January 2023, and ships commercially from Red Hat [22].
• Commercial decision managers such as IBM Operational Decision Manager (descended from ILOG JRules) serve the same role in banks and insurers.
• Decision tables and DMN. Many rule sets are now written as decision tables in the Object Management Group’s Decision Model and Notation standard, which engines such as Drools execute.
• CLIPS remains in use in research, teaching and embedded systems.

What changed is the ambition. Today’s rule engines do not claim to capture expertise; they execute written policy. That is the job production rules do well: the policy is explicit, auditable and changeable, and each decision can cite the rule that made it.

8. Timeline

9. Where expert systems break

• Brittleness. A case slightly outside the rules gets no answer or a confidently wrong one, with no warning that it is outside the system’s competence.
• The knowledge-acquisition bottleneck (§6.3): knowledge is expensive to extract and more expensive to keep current.
• Rule interaction. Behaviour depends on how rules combine and on the conflict-resolution strategy, so validating a large rule base is hard.
• Ad hoc uncertainty. Certainty factors over-count correlated evidence (§4.1).
• No common sense and no perception. Inputs must be supplied as symbols by a person or another system.

These are the general limits of symbolic AI at their sharpest. The strengths are the other side of the same design: exactness within the rules, explanations that are the actual computation, and behaviour that changes when one rule is edited.

10. Expert systems and fail-safe models

A fail-safe model is an AI model whose failures drive it to a controlled, safe state: it abstains when evidence is missing, and learning can narrow what it does but never widen what it is allowed to do. Expert systems show both halves of the problem. Their good half is that a conclusion exists only if a chain of named rules produces it, so “no rule fired” is a clean, inspectable abstention, and every answer can cite its reasons. Their bad half is that the rules themselves had no gate: whatever a knowledge engineer typed in became authoritative, and an ad hoc number such as a certainty factor could push a conclusion over a threshold that nothing independent checked.

A fail-safe design keeps the first property and adds the missing gate. Proposals, whether from a person, a rule-learning procedure or a language model, are not knowledge until a symbolic layer admits them against sources; a model may propose; only the floor admits a fact. Peel, by Perslis Research, is built on that principle and is, to our knowledge, the first fail-safe model; the exact claim and the closest earlier work are on What is a fail-safe model? There is no neural network in the loop that decides, its knowledge is typed, sourced cards rather than free-standing rules, and its learning is readable counts. Peel is a research prototype. It inherits the expert system’s explainability without claiming to have solved its brittleness: outside its admitted knowledge it answers “unknown”. For how Perslis uses a symbolic layer more broadly, see Symbolic AI at Perslis and the paper The Orchestration Gap.

11. Questions

What is an expert system?

An expert system is a program that solves problems in a narrow specialist field by applying rules elicited from human experts through a general inference engine. It keeps the knowledge base separate from the reasoning procedure, and it can explain each conclusion by listing the rules and facts that produced it.

What are the main components of an expert system?

A knowledge base of rules about the domain, a working memory holding the facts of the current case, and an inference engine that matches rules to facts and fires them. Most systems add an explanation facility that answers why and how questions, and tools for adding and editing rules.

What is the difference between forward chaining and backward chaining?

Forward chaining is data-driven: it starts from the known facts and fires every rule whose conditions hold until nothing new can be added. Backward chaining is goal-driven: it starts from a hypothesis and works back through rules that could prove it, turning their conditions into sub-goals. XCON used forward chaining; MYCIN used backward chaining.

What is the Rete algorithm?

Rete is a pattern-matching algorithm for production systems, developed by Charles Forgy at Carnegie Mellon and published in 1982. It compiles rules into a network that shares tests common to several rules and stores partial matches between cycles, so each change to working memory is processed incrementally instead of re-matching every rule against every fact.

How do MYCIN's certainty factors work?

Each rule and conclusion carries a certainty factor between -1 and 1. A rule's contribution is its own factor times the weakest of its conditions. Two positive contributions X and Y combine as X + Y(1 - X), two negative ones as X + Y(1 + X), and contributions of opposite sign as (X + Y) / (1 - min(|X|, |Y|)).

What was the first expert system?

DENDRAL, begun at Stanford in 1965 by Edward Feigenbaum, Joshua Lederberg, Bruce Buchanan and Carl Djerassi, is usually called the first expert system. It inferred the structure of organic molecules from mass-spectrometry data. MYCIN, R1/XCON and PROSPECTOR followed.

Why did expert systems decline?

Knowledge had to be elicited from experts and written as rules by hand, which was slow and expensive, and large rule bases were hard to keep consistent as the world changed. The systems were brittle outside their rules, specialised Lisp hardware lost its market in 1987, and machine learning offered a way to acquire knowledge from data instead.

Are expert systems still used today?

Yes, mostly under the name business rules engines. Production-rule engines such as Drools, IBM Operational Decision Manager and CLIPS run pricing, eligibility, underwriting, fraud and compliance rules in banks, insurers and government, often using match algorithms descended from Rete.

12. References

1. E. L. Post. Formal Reductions of the General Combinatorial Decision Problem. American Journal of Mathematics 65(2):197–215, 1943.
2. A. Newell, H. A. Simon. Human Problem Solving. Prentice-Hall, 1972.
3. C. L. Forgy. OPS5 User’s Manual. Technical Report CMU-CS-81-135, Carnegie Mellon University, July 1981.
4. C. L. Forgy. Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem. Artificial Intelligence 19(1):17–37, 1982. (Earlier: On the Efficient Implementation of Production Systems, PhD thesis, Carnegie Mellon University, 1979.)
5. D. P. Miranker. TREAT: A Better Match Algorithm for AI Production Systems. Proceedings of AAAI-87, 1987.
6. E. H. Shortliffe, B. G. Buchanan. A Model of Inexact Reasoning in Medicine. Mathematical Biosciences 23:351–379, 1975.
7. B. G. Buchanan, E. H. Shortliffe (eds.). Rule-Based Expert Systems: The MYCIN Experiments of the Stanford Heuristic Programming Project. Addison-Wesley, 1984. Chapter 10, “Uncertainty and Evidential Support”, gives the revised combining function.
8. D. Heckerman. Probabilistic Interpretations for MYCIN’s Certainty Factors. In L. N. Kanal, J. F. Lemmer (eds.), Uncertainty in Artificial Intelligence. North-Holland, 1986. arXiv:1304.3419
9. R. O. Duda, P. E. Hart, N. J. Nilsson. Subjective Bayesian Methods for Rule-Based Inference Systems. Proceedings of the AFIPS National Computer Conference 45, 1976.
10. R. K. Lindsay, B. G. Buchanan, E. A. Feigenbaum, J. Lederberg. DENDRAL: A Case Study of the First Expert System for Scientific Hypothesis Formation. Artificial Intelligence 61(2), 1993.
11. E. H. Shortliffe. Computer-Based Medical Consultations: MYCIN. Elsevier, 1976.
12. V. L. Yu et al. Antimicrobial Selection by a Computer: A Blinded Evaluation by Infectious Diseases Experts. JAMA 242(12):1279–1282, 1979.
13. J. McDermott. R1: A Rule-Based Configurer of Computer Systems. Artificial Intelligence 19(1):39–88, 1982.
14. V. E. Barker, D. E. O’Connor, J. Bachant, E. Soloway. Expert Systems for Configuration at Digital: XCON and Beyond. Communications of the ACM 32(3):298–318, 1989. doi:10.1145/62065.62067
15. A. N. Campbell, V. F. Hollister, R. O. Duda, P. E. Hart. Recognition of a Hidden Mineral Deposit by an Artificial Intelligence Program. Science 217(4563):927–929, 1982. doi:10.1126/science.217.4563.927
16. E. A. Feigenbaum. The Art of Artificial Intelligence: Themes and Case Studies of Knowledge Engineering. Proceedings of IJCAI-77, 1977.
17. W. van Melle. A Domain-Independent Production-Rule System for Consultation Programs. Proceedings of IJCAI-79, 1979.
18. G. Riley. About CLIPS. clipsrules.net. https://www.clipsrules.net/AboutCLIPS.html
19. F. Hayes-Roth, D. A. Waterman, D. B. Lenat (eds.). Building Expert Systems. Addison-Wesley, 1983.
20. G. Schreiber, H. Akkermans, A. Anjewierden, R. de Hoog, N. Shadbolt, W. Van de Velde, B. Wielinga. Knowledge Engineering and Management: The CommonKADS Methodology. MIT Press, 2000.
21. S. Russell, P. Norvig. Artificial Intelligence: A Modern Approach, 4th ed. Pearson, 2020.
22. KIE Community. Drools 6 Performance with the PHREAK Algorithm. blog.kie.org, February 2014. https://blog.kie.org/2014/02/drools-6-performance-with-the-phreak-algorithm.html