Expert Systems: The Boom Everyone Forgot

Between roughly 1980 and 1987, artificial intelligence was a commercial industry selling rule-based systems to large corporations, with its own hardware vendors, its own trade press and its own bubble. It is the most thoroughly forgotten profitable period in the field’s history, and the reasons it ended are more instructive than the reasons it started.

The idea, and why it was a genuine advance

The core insight belongs to Edward Feigenbaum at Stanford and is usually stated as: performance on hard real-world problems comes from domain-specific knowledge, not from general reasoning power. A system with a weak inference engine and a thousand facts about mass spectrometry beats a system with an elegant theorem prover and no facts. Feigenbaum called this the knowledge principle, and it was a direct rejection of the general-problem-solver programme that Dartmouth-era AI had pursued.

The architecture that followed from it separates two things that earlier programs mixed together:

That separation is the reason the industry could exist. You could sell the same engine to a bank and a refinery, and the domain experts — who were not programmers — could in principle read and correct their own rules. It also gave the systems something almost no modern model has: a complete, human-readable explanation of any conclusion, which was the literal chain of rules that fired.

DENDRAL and MYCIN: the research systems

DENDRAL began at Stanford in 1965, a collaboration between Feigenbaum, Bruce Buchanan, the geneticist Joshua Lederberg and the chemist Carl Djerassi. It inferred candidate molecular structures from mass spectrometry data by generating possible structures and pruning them with rules that encoded what a chemist knew about how molecules fragment. It ran for well over a decade and produced results published in the chemistry literature — an AI system that contributed to another field’s journals, which remained rare for a long time afterwards.

MYCIN came out of Edward Shortliffe’s doctoral work at Stanford in the mid-1970s. It diagnosed bacterial infections of the blood and recommended antibiotic regimens, from a rule base of roughly five hundred rules. It introduced two things that outlived it. The first was certainty factors: a numeric confidence attached to each rule and propagated through the chain, an attempt to handle uncertainty without full Bayesian machinery — mathematically unprincipled, as its own authors later acknowledged, but usable. The second was explanation: you could ask MYCIN why it was asking a question, and get the rule.

A published evaluation in 1979 had MYCIN’s therapy recommendations for meningitis cases rated by external specialists against those of Stanford faculty, with the program’s recommendations judged acceptable at least as often as the humans’. And it was never used on a patient. The reasons are worth listing, because none of them is about accuracy:

• Delivery. In the 1970s using MYCIN meant a terminal connected to a mainframe and a session of typed questions taking substantial time. There was no plausible route to a physician’s workflow.
• Liability. Nobody had an answer to who is responsible when the program is wrong — a question that is still not settled for clinical AI and is now a regulatory subject rather than a philosophical one.
• Scope. It knew about a narrow class of infections. Presented with a patient whose problem was outside its rule base, it had no way to know that, which is the failure mode that recurs through this entire history.

XCON: the one that made money

R1, later renamed XCON, was written by John McDermott at Carnegie Mellon from 1978 and deployed at Digital Equipment Corporation from 1980. Its job was configuration: given a customer’s VAX order, work out every cable, cabinet, board and power supply required, and check that the resulting machine would actually function. DEC had been doing this by hand, with errors that were expensive to discover at the customer’s site.

XCON is the system that made the commercial case for the whole field. The figures usually reported are that it began with around 750 rules, grew past 10,000 by the late 1980s, and saved DEC on the order of $25 million a year. Those numbers come from DEC’s own accounts and from the academic write-ups of the period; they are given here as reported figures rather than as independently audited ones.

The less-quoted number is the one that matters more. Keeping XCON current required a permanent team — reported in the tens of people — because DEC’s product line changed constantly and every change was a rule change. The system was a success and it was also a demonstration of the cost structure that would kill the industry.

The industry, 1980 to 1987

By the mid-1980s there were three distinct businesses: shell vendors selling the inference engine and rule editor as a product; consultancies selling knowledge engineering as a service; and hardware vendors selling Lisp workstations to run it all on.

• Shells and tools. Teknowledge, IntelliCorp, Inference Corporation and Carnegie Group were the best-known American vendors. EMYCIN — MYCIN with the medical knowledge removed — was the canonical demonstration that the engine was separable from the knowledge.
• Hardware. Symbolics and Lisp Machines Inc, both out of the MIT AI Lab, plus Xerox’s Interlisp machines. These were genuinely excellent development environments and genuinely expensive.
• Government programmes. Japan’s Fifth Generation project from 1982, the UK’s Alvey Programme from 1983, ESPRIT in Europe and DARPA’s Strategic Computing Initiative from 1983.

The four things that broke them

1. The knowledge acquisition bottleneck. Feigenbaum’s own term for it. Extracting an expert’s decision procedure into explicit rules is slow, and it fails on the most valuable part of expertise, which the expert cannot articulate. An expert who says “it just looked wrong” has knowledge the method cannot capture. That is precisely the knowledge that statistical learning captures from examples without anyone stating it, and it is the deepest reason the paradigm lost.
2. Brittleness at the boundary. Inside its rule base the system was superb. One step outside it, the system did not degrade gracefully — it produced a confident answer derived from rules that did not apply, with no signal that anything was wrong. A human expert given an unfamiliar case says so.
3. Maintenance cost grows faster than the rule base. This is the killer and it is arithmetic. Rules interact, so the number of potential interactions grows roughly with the square of the rule count. Ten rules have on the order of a hundred possible interactions; ten thousand rules have on the order of a hundred million. Nobody can hold that in their head, and there was no equivalent of a regression test suite. Systems reached a size at which adding a rule reliably broke something else and nobody could predict what.
4. They could not learn. Every improvement required a human to author it. A system that has processed a million cases knows exactly what it knew on day one. Set against a method that improves from data, this is not a competition.

Why rule bases stop scaling — the arithmetic, with assumptions stated

  Assume each new rule can interact with any existing rule
  (conflict, subsumption, unintended chaining).

  Potential interaction pairs in a base of n rules:  n(n-1)/2

     n =    100  →      4,950 pairs
     n =  1,000  →    499,500 pairs
     n = 10,000  → 49,995,000 pairs

  Adding rule n+1 to a 10,000-rule base introduces 10,000 new
  pairs to reason about. If a knowledge engineer can check one
  pair a second without stopping, that is about three hours of
  checking per rule added.

  This is an upper bound: real rule bases are partitioned and most
  pairs never meet. But nothing in the architecture enforces the
  partitioning, and nothing tells you when you have broken it.

Where the technology actually went

Expert systems did not fail in the sense of not working. They stopped being called AI, which is a different thing entirely, and the technology was absorbed into ordinary software where it remains extremely widely deployed.

• Business rules engines. Drools, IBM ODM and their commercial equivalents are direct descendants, including the Rete pattern-matching algorithm that Charles Forgy developed for OPS5 in the late 1970s. Insurance underwriting, claims adjudication and eligibility determination run on them.
• Clinical decision support. Drug interaction checking and dosing alerts in hospital systems are rule bases with a different name, and their explanation property is the reason they are permitted where a statistical model is not.
• Tax and compliance software. Tax law is a rule base written by a legislature. Nothing has ever displaced the rule-based approach here, because the rules are the ground truth rather than an approximation of it.
• Configurators. XCON’s actual job — checking that a specified configuration is valid — is now a standard feature of enterprise ordering systems.

The one project that carried the original ambition forward without compromise was CYC, begun by Douglas Lenat at MCC in 1984 with the goal of hand-encoding enough common-sense knowledge to reach a threshold at which the system could read and learn for itself. It ran for nearly four decades — Lenat died in 2023 — and accumulated millions of assertions. Whether it succeeded depends entirely on what you thought it was for; what is not in dispute is that no hand-encoding project has come close to the breadth that statistical models acquired from text, which is the empirical result the whole symbolic-versus-connectionist argument eventually turned on.

One capability was lost in the transition and has not been recovered. An expert system could tell you exactly why it concluded what it concluded, because the explanation was the derivation. Modern models produce explanations that are generated text rather than a record of the computation, which is a different and much weaker guarantee — the distinction examined in whether a stated chain of reasoning is the actual one.