Expert Systems: Encoding Human Expertise in Software

An expert system is a program that stores a specialist's knowledge as if-then rules and applies them to a case, step by step, with an explanation of each step. In the 1970s and 1980s these programs became the first commercially successful artificial intelligence: MYCIN recommended antibiotics, and XCON configured computer orders for Digital Equipment Corporation. Then the approach stalled, because acquiring and maintaining the rules proved too slow and expensive to scale. This article explains how expert systems work, what the famous examples did, and where their descendants still run.

What an expert system actually is

Think of a new employee handed a thick binder. Every page says "if you see this, do that," written by the best person in the department. The employee has no experience, but by following the binder and checking each page against the case at hand, they can often match what the veteran would have decided. An expert system is that binder made executable, plus a clerk who can find the right page quickly and say which pages led to the answer.

Reference summaries describe an expert system as a computer system that emulates the decision-making ability of a human expert, mainly by reasoning over knowledge stored as if-then rules, not by following a fixed procedural program (Wikipedia: Expert system). The idea was formally introduced around 1965 by Stanford's Heuristic Programming Project, led by Edward Feigenbaum.

The five parts

Most descriptions break the design into the same components, which is why people could build many systems from one template.

Component	What it does	The binder analogy
Knowledge base	Stores facts and rules about the domain	The pages of the binder
Inference engine	Applies rules to known facts to derive new facts	The clerk who finds the right page
Explanation facility	Traces the chain of rules that produced a conclusion	The clerk's note saying which pages were used
Knowledge acquisition facility	Helps experts and engineers build and update the rules	The process for revising the binder
User interface	Lets a person enter facts and read conclusions	The desk where questions arrive

The separation matters. Because domain knowledge lives in the knowledge base and the reasoning lives in the inference engine, the same engine can be pointed at a new domain by swapping the rules. That reuse is what made commercial "expert system shells" possible.

Why rules, and what a rule looks like

A rule has two halves: a condition and an action. If the condition matches the current facts, the rule can fire. The classic textbook case is a two-line argument. Given the fact that Socrates is a man and the rule that every man is mortal, the system concludes that Socrates is mortal.

Real rules are more specific, and they are written so that an expert can read them. A toy example from car repair, invented for illustration:

• Rule 1: IF the engine does not crank AND the dashboard lights are dim THEN the battery is weak.
• Rule 2: IF the battery is weak AND the battery is more than five years old THEN recommend replacing the battery.
• Rule 3: IF the engine cranks but does not start AND the fuel gauge shows empty THEN the tank is out of fuel.

Readable rules were a selling point. An expert could review the rule base the way an editor reviews a manuscript, and the Wikipedia overview lists this editability and the ability to give explanations among the main advantages.

How the rules run: forward and backward chaining

The inference engine has two basic strategies for turning rules into conclusions. Both are named for the direction of reasoning.

Forward chaining: from facts to conclusions

Forward chaining starts with what is known and fires every rule whose condition is satisfied, adding the results to the pool of facts until nothing new appears. In the car example, suppose the user reports that the engine does not crank, the lights are dim, and the battery is six years old. Rule 1 fires and adds "the battery is weak." Now Rule 2's condition is met, so it fires and adds "recommend replacing the battery." The system never looked at Rule 3, because its conditions were never true.

Backward chaining: from a goal to the facts it needs

Backward chaining starts with a candidate conclusion and works out what would have to be true. To test "recommend replacing the battery," the system looks for rules that conclude it, finds Rule 2, and asks whether the battery is weak and old. To check whether the battery is weak, it finds Rule 1 and asks about cranking and the lights. When it lacks a fact, it can ask the user.

Strategy	Starts from	Best when	Famous user
Forward chaining	The facts	Data arrives and you want to see what follows, such as assembling a configuration	XCON (written in the OPS5 production-rule language)
Backward chaining	A hypothesis	There are few possible answers and many facts you could collect, such as diagnosis	MYCIN

An automated phone menu is a fair analogy for backward chaining: the system asks only the questions needed to settle the branch it is currently examining, and skips the rest. Forward chaining is closer to a sorting facility, where every parcel is checked against every rule as it arrives.

Production systems and the speed problem

Systems like XCON were built on production systems: a rule base, a working memory of current facts, and an interpreter that repeatedly matches rules against memory, picks one of the matches, and executes it. When several rules match at once, a conflict resolution strategy decides which fires first, using simple criteria such as rule order and priority or more complex ones such as how recently a rule fired (Wikipedia: Production system).

The obvious implementation, checking every rule against every fact after every change, gets slow as the rule base grows. Charles Forgy of Carnegie Mellon University solved this with the Rete algorithm, first described in a 1974 working paper and elaborated in his 1979 doctoral thesis and a 1982 paper. It matches many rules against many facts efficiently by trading memory for speed, and it was first used as the core of OPS5, the language that XCON was built in (Wikipedia: Rete algorithm). Rete-based engines such as CLIPS, Jess, and Drools are still in use.

DENDRAL: the project that set the pattern

The first system that people usually call an expert system predates MYCIN by years. DENDRAL began at Stanford in 1964 as a collaboration among Edward Feigenbaum, Bruce Buchanan, the geneticist Joshua Lederberg, and the chemist Carl Djerassi. Its job was to help organic chemists work out the structure of an unknown molecule from its mass spectrum, the pattern of fragments a molecule breaks into inside a mass spectrometer. By 1970 it was performing structural interpretation at a postdoctoral level, and Djerassi's group used it for about a decade (Wikipedia: Dendral).

DENDRAL's method was called plan-generate-test. A planner used chemical knowledge to find constraints, a generator produced every candidate structure consistent with them, and a tester threw out the candidates that failed. Its learning component, Meta-DENDRAL, proposed new mass-spectrometry rules from data. DENDRAL is considered the first expert system because it automated part of what an organic chemist actually did, and it influenced MYCIN, XCON, and others.

The lesson from DENDRAL is the one that defined the whole field: a modest reasoning method became powerful once it was loaded with a great deal of domain-specific knowledge. Power came from the knowledge, not from clever logic.

MYCIN: 600 rules and a number for doubt

MYCIN was developed at Stanford in the early 1970s over roughly five or six years, as Edward Shortliffe's doctoral dissertation, directed by Bruce Buchanan, Stanley Cohen, and others. It was written in Lisp and ran on a DEC PDP-10 mainframe. Its task was to identify the bacteria behind severe infections such as bacteremia (bacteria in the blood) and meningitis, and to recommend antibiotics with doses adjusted for body weight (Wikipedia: Mycin).

This is a historical description, not medical guidance. MYCIN was a research system and was never used to treat patients.

How it worked

MYCIN used about 600 production rules and reasoned backward from a goal, asking the physician questions about the patient as it went. It kept its medical knowledge separate from the reasoning code, which is why its designers could later strip out the infectious-disease rules and keep the engine. The result was EMYCIN, an "essential MYCIN" shell for building new rule-based systems.

The certainty factor

Medicine rarely offers yes or no. So MYCIN attached a certainty factor to its rules and conclusions, on a scale running from −1 (false) through 0 (unknown) to +1 (true). When several rules supported the same conclusion, their factors were combined into a single value. Certainty factors were built to mimic how clinicians describe confidence, and they are not probabilities in the strict mathematical sense.

The evaluation

In a Stanford Medical School evaluation, eight infectious disease specialists judged therapy recommendations for 10 test cases. The recommendations came from MYCIN and from a group of human prescribers. MYCIN's recommendations were rated acceptable 65% of the time. Five faculty members scored between 42.5% and 62.5%. Those numbers come from a small test and mean only that on 10 cases the program held its own against human prescribers. They do not mean that MYCIN diagnosed infections with 65% accuracy, a reading that is easy to fall into.

Why it was never deployed

MYCIN never treated a patient in routine care. Ethical and legal concerns about who is responsible for a computer's advice played a part, but the main barrier was practical. The program was stand-alone, required users to type in all of the patient data, and ran on a time-shared mainframe, years before personal computers.

One feature of MYCIN proved lasting: it could explain itself. A physician could ask why a question was being asked or how a conclusion was reached, and the program would show the rules it had used. That ability to show its reasoning is the property that makes rule-based systems attractive again in regulated settings, as a later section covers.

XCON: the expert system that earned its keep

If MYCIN was the proof of concept, XCON was the proof of profit. John McDermott of Carnegie Mellon University developed it starting in 1978, in the OPS5 production-rule language, to help Digital Equipment Corporation (DEC) choose the components for VAX computer orders. It first entered use in 1980 at DEC's plant in Salem, New Hampshire. McDermott's 1980 paper on the system later received the AAAI Classic Paper Award, in 1999 (Wikipedia: Xcon).

The problem suited rules. A customer order named a computer and a set of options, and someone had to make sure the parts were complete and compatible. The constraints were numerous but explicit. XCON, also called R1, selected the components that turned a customer's requirements into a working configuration.

Year	Reported size or result
1980	First use at DEC in Salem, New Hampshire
1986	About 80,000 orders processed, with 95 to 98% accuracy
1987	6,200 rules
1989	10,129 rules

Wikipedia's summary reports an estimate of about $25 million a year in savings for DEC. That is a reported estimate, not an audited figure, and it should be read as the order of magnitude of the benefit.

The growth in the table is also a warning. A 1987 analysis found that maintaining XCON did not scale in a straight line: as it grew from 700 to 6,200 rules, with about half the rules changing each year, enhancing it became very difficult. The success was real, and so was the bill for keeping it current.

The boom of the 1980s, and what ended it

XCON's results persuaded companies that expertise could be bottled. By 1985, corporations were spending over $1 billion a year on AI, mostly on in-house AI departments, and a supporting industry of software and hardware firms had grown up around expert systems. The Expert system overview adds that two-thirds of Fortune 500 companies were applying the technology in daily business, and the AI winter account supplies the spending figure (Wikipedia: AI winter).

Governments spent too. The US Defense Advanced Research Projects Agency (DARPA) launched its Strategic Computing Initiative in 1983 in response to Japan's Fifth Generation project, and by 1985 it had spent $100 million on 92 projects at 60 institutions. Japan's trade ministry had set aside $850 million for the Fifth Generation project in 1981.

The decline came in stages.

• 1987: the market for specialized Lisp machines, the dedicated computers on which many expert systems ran, collapsed as cheaper workstations matched their performance. One account describes an industry worth half a billion dollars as being replaced in a single year.
• 1987 to 1988: DARPA's AI funding was cut deeply, and new AI spending was cancelled in 1988.
• Early 1990s: most commercial Lisp companies failed, including Symbolics, Lisp Machines Inc., and Lucid. Systems such as XCON were by then judged too expensive to maintain, hard to update, unable to learn, and "brittle," meaning they made serious errors on unusual inputs.
• June 1, 1992: Japan's Fifth Generation project ended, with its goals unmet.

Some historians also argue that expert systems were victims of their own success: rule engines became standard tools, and the term fell out of fashion even as the technology spread. Both stories can be true at once.

Why the approach hit a wall

The limits were not mysterious. They fell into four families, and each has a modern counterpart.

Limit	What it means	Why it hurt
Knowledge acquisition	Experts are scarce and find it hard to state what they know	The most commonly cited problem; every rule had to be extracted by interviews and revised by trial
Maintenance	The domain changes, so rules must change	XCON's 1987 analysis: half of 6,200 rules changing yearly
Brittleness	Cases outside the rules produce silent mistakes	No graceful degradation, no sense of "I am out of my depth"
No learning	The system cannot improve from experience	Every improvement needs a person to write a rule

The knowledge acquisition bottleneck

Experts rarely work by consulting a mental list of rules. A veteran mechanic hears an engine and "just knows." Turning that into explicit statements takes many hours of interviews, and what an expert says they do can differ from what they actually do. Large rule bases also become hard to check: the problem of verifying that rules do not contradict each other can reduce to a task computer scientists classify as NP-complete, which means the effort can explode as the rule base grows.

The common sense gap and Cyc

Experts also depend on background knowledge so basic that nobody writes it down: a person who is feverish is uncomfortable, a patient is a human, time moves forward. Early systems had none of that, so they were competent inside a narrow domain and clueless one step outside it. Douglas Lenat began the Cyc project in July 1984 at the research consortium MCC to write that background knowledge down by hand. By 2002 it had reportedly absorbed about $60 million and 600 person-years of effort. By 2017 it held about 1.5 million terms, and its open version was shut down that year (Wikipedia: Cyc). Cyc did not fail so much as show how large the task is.

Brittleness has a machine learning cousin

A rule-based system that gets an unusual input wrong has the same weakness as a trained model that meets data unlike its training set. In both cases the system behaves confidently outside the region where it was built. Our guide to overfitting and underfitting covers the learning-side version, and our article on why AI hallucinates shows how modern language models can fail the same way.

Uncertainty: from certainty factors to probabilities

Real decisions rest on incomplete evidence, so every serious expert system needed a way to say "probably." MYCIN's certainty factors were one answer. Other systems associated a probability with each rule, and still others borrowed from fuzzy logic, which treats a statement such as "high fever" as true to a degree between 0 and 1. The Wikipedia overview describes these as sophisticated mechanisms for uncertain reasoning layered on top of simple rules.

The lasting insight was that confidence has to be represented explicitly, not hidden. Modern probabilistic models do this more rigorously, and a language model that gives a fluent answer with no visible confidence level lacks something MYCIN had, since MYCIN attached a number for doubt to its conclusions.

Where rule-based AI still works

Expert systems did not vanish. They changed names. In the 2000s, rule capabilities were built into business application suites from SAP, Siebel, and Oracle, and rule engines now often support business rules management and business process automation. NASA's Johnson Space Center created the CLIPS rule language in 1985, with a name and syntax inspired by Forgy's OPS5. It is written in C and is public domain, with version 6.4.1 released in April 2023 (Wikipedia: CLIPS).

Clinical decision support

Hospital software still uses IF-THEN logic where the rule is clear and the stakes are high. A common knowledge-based decision support rule reads: if a clinician orders drug X for a patient who is taking drug Y, show an alert. Systems of this kind check orders and report warnings to the person placing the order. The same overview notes a related weakness: when systems fire too many alerts, clinicians may pay less attention to all of them, which is called alert fatigue (Wikipedia: Clinical decision support system). That is a maintenance problem, which is the old expert-system problem in a new setting.

Not every diagnostic aid is rule-based. DXplain, built at Massachusetts General Hospital with work starting in 1984 and a first version in 1986, produces ranked differential diagnoses using a pseudo-probabilistic algorithm that weighs each finding, and it is used for clinician training and reference (Wikipedia: DXplain). For the broader picture of how machine learning is entering clinical work, see AI in healthcare.

Decisions that must be explained

A decision that must come with reasons is the setting where a transparent rule base has a real advantage. In the United States, Regulation B, which implements the Equal Credit Opportunity Act, requires that the statement of reasons for an adverse action be specific and indicate the principal reasons (Wikipedia: Right to explanation). A system whose conclusions come from named rules can produce reasons directly.

In Europe, the picture is less settled. Recital 71 of the General Data Protection Regulation (GDPR) mentions a right to obtain an explanation of an automated decision, but recitals are not binding, and the right does not appear in the binding text of Article 22. Scholars disagree about whether a right to explanation exists. Wachter, Mittelstadt, and Floridi argued in 2016 that it does not, while others, including Goodman and Flaxman, read the regulation more generously. This is a summary of public information, not legal advice. For how modern models can encode unfairness that such explanations are meant to catch, see AI bias and discrimination and AI loan approval and lending discrimination.

Knowledge graphs and neuro-symbolic AI

The central expert-system idea, that structured knowledge is worth building, survived in different clothes.

Knowledge graphs

A knowledge graph stores facts as entities connected by relationships, optionally with an ontology (a formal description of what kinds of things exist and how they relate) that lets people and programs reason over the contents. The idea of the graph is old, but the public face of it is Google's Knowledge Graph, announced on May 16, 2012, with the tagline "things, not strings." At launch it held more than 500 million objects and more than 3.5 billion facts about them and the relationships between them (Google). It was built on open projects such as DBpedia and Freebase and later added data from Wikidata and Wikipedia (Wikipedia: Knowledge graph).

	Expert system	Knowledge graph
Unit of knowledge	If-then rule	Entity and relationship
Typical reasoning	Chain rules to a conclusion	Look up and traverse connections
Strength	Explains a decision as a chain of named rules	Covers a huge number of facts with a flexible structure
Weakness	Rule maintenance does not scale	Facts do not by themselves yield decisions

The two are complements more than competitors. A graph supplies facts, and a rule layer can reason over them.

Neuro-symbolic AI

Neuro-symbolic AI pairs neural networks, which learn statistical patterns from data, with symbolic methods such as knowledge representation and automated reasoning. The argument for it is that deep learning is good at fast, pattern-based judgments and weak at reliable, step-by-step logic, while symbolic methods have the opposite profile (Wikipedia: Neuro-symbolic AI). One example is AlphaGeometry from Google, described in a 2024 paper in Nature on solving olympiad geometry problems without human demonstrations.

Modern language models bring the old tension back. Retrieval systems let a model look up facts instead of recalling them from its weights, as retrieval-augmented generation does, and techniques such as chain-of-thought reasoning have models write out intermediate steps in a way that resembles a rule trace. The tools are different, but the goal is the one MYCIN had: an answer with its reasons attached. Researchers working on mechanistic interpretability are pursuing a harder version of the same thing, which is reading the reasons out of a trained network.

Common misunderstandings

• "MYCIN was 65% accurate." The 65% was the share of its recommendations judged acceptable by specialists in a 10-case evaluation. It is not a diagnostic accuracy rate.
• "Expert systems failed." XCON processed tens of thousands of orders and saved DEC money by the estimates above. What failed was the claim that the method would scale to general intelligence and stay cheap to maintain.
• "Expert systems are the same as machine learning." They are opposites in method. Rules are written by people, and models are trained on data. Our overview of AI, machine learning, and deep learning lays out the differences.
• "Chatbots like ChatGPT are expert systems." A language model is a neural network trained on text, and its knowledge is spread through its parameters. There is no editable rule base to inspect. See how large language models work.
• "Rule-based AI is obsolete." It handles huge volumes of everyday decisions, including business rules and drug-interaction alerts, because rules are predictable and auditable.

FAQ

Q: What is the difference between an expert system and a regular program? A: In a regular program, the logic is woven into the code, so changing a decision means editing the program. In an expert system, the knowledge sits in a separate rule base that an expert can read, and a general-purpose inference engine applies it. That separation also lets the system explain which rules led to an answer.

Q: Did MYCIN ever treat real patients? A: No. It was a research system developed at Stanford in the early 1970s and evaluated on test cases. Its recommendations were rated acceptable 65% of the time in one evaluation, but ethical and legal questions about responsibility, and a stand-alone design that required typing in all patient data on a time-shared mainframe, kept it out of routine care.

Q: Why did expert systems decline in the late 1980s? A: Several things happened together. Maintaining large rule bases proved costly, as XCON's growth from 700 to 6,200 rules showed. The Lisp machine market collapsed in 1987. Government funding was cut, and the systems were brittle outside their domains and could not learn. Some historians add that rule engines simply became ordinary software and lost the label.

Q: What is the knowledge acquisition bottleneck? A: It is the difficulty of getting an expert's knowledge into a form a program can use. Experts are scarce, their time is expensive, and much of what they know is intuitive and hard to state. It is the most commonly cited problem with expert systems.

Q: Are expert systems still used? A: Yes, usually under other names. Rule engines support business rules management and process automation, CLIPS remains available as public-domain software, and IF-THEN logic drives many clinical alerts. The expert-system label is rarer than the technology.

Q: Is a knowledge graph an expert system? A: No. A knowledge graph stores entities and the relationships between them, and queries traverse those connections, while an expert system applies if-then rules to reach conclusions. They can be combined, with a graph supplying facts and rules reasoning over them.

Q: Could modern AI rebuild the rule bases that people used to write by hand? A: Researchers are exploring it. Language models can draft candidate rules from text, which could ease the knowledge acquisition bottleneck, but the output still needs expert review. A model can state a plausible rule that is wrong, which is the failure that rule-based design was meant to avoid, so verification remains the hard part.

The takeaway

Expert systems showed that a narrow reasoning method becomes useful when it is loaded with real domain knowledge. DENDRAL did it for chemistry, MYCIN for infectious disease, and XCON for computer configuration, and XCON's savings made the case in dollars. The design that made them readable, a rule base separated from a reasoning engine with an explanation attached, is the same design that made them expensive to grow: every rule had to be extracted from a person, checked, and revised as the world changed.

That trade explains why the story did not end in 1987. Learning systems took over the problems where data is plentiful and rules are hard to write, while rules kept the jobs where decisions must be audited, explained, or kept predictable. The open question for current AI is how to combine the two, so that a system can learn from data and still show its reasons. MYCIN's explanation facility was aimed at exactly that about fifty years ago.

---

Read next:

• Neural Networks and Deep Learning: Mimicking the Brain
• The History of Artificial Intelligence: A Complete Timeline
• What Is Machine Learning? Explained Simply, with Real Examples

Sources

• Wikipedia, Expert system, Mycin, Xcon, Dendral, and Production system. Used as secondary summaries of the primary literature.
• Wikipedia, AI winter and Cyc.
• Wikipedia, Rete algorithm and CLIPS.
• Wikipedia, Clinical decision support system and DXplain.
• Wikipedia, Right to explanation, summarizing GDPR Recital 71 and Article 22, Regulation B (12 CFR 1002.9(b)(2)), and Wachter, Mittelstadt, and Floridi (2016).
• Google, Introducing the Knowledge Graph: things, not strings, May 16, 2012.
• Wikipedia, Knowledge graph and Neuro-symbolic AI.

Last verified: October 2026