What was XCON, the expert system that configured computers for Digital Equipment Corporation?

In the late 1970s, buying a minicomputer was not like buying a laptop. A customer ordering a VAX from Digital Equipment Corporation (DEC) chose the processor, memory, disk drives, terminals, cabinets and the cables to join them, often piece by piece. Salespeople were not always technical experts, so orders regularly arrived missing a cable or a controller, or with parts that would not fit together. Each mistake meant delays, frustrated customers and free replacement parts.

DEC's answer was a computer program that knew the rules of putting a VAX together. Its author, John McDermott of Carnegie-Mellon University in Pittsburgh, called it R1; inside DEC it became XCON, short for "expert configurer." From January 1980 it was used routinely in DEC's manufacturing organization, starting at the company's plant in Salem, New Hampshire.

What XCON did

XCON's job, as McDermott described it, had two parts. First, it read a customer's order and noticed what was missing, adding the components needed for the system to work. Second, it produced diagrams showing where each component should go: which cabinet, which slot, which cable. Technicians used those diagrams to assemble the machine.

The VAX-11/780 offered plenty of room for error. A typical system had about 90 components, and the database XCON drew on described 420 different ones, each with eight or so properties that mattered for configuration, such as size, power needs or how many devices it could support.

How it worked

XCON was a production system, a program made of many independent rules. Each rule has conditions and actions: if the current situation matches the conditions, the rule "fires" and its actions change the situation. The program keeps a working memory describing the partly finished configuration, and it repeatedly looks for a rule that matches, fires it, and looks again.

In McDermott's 1980 paper, R1 had 772 rules, of which 480 were about configuration and the rest handled more general tasks. It was written in OPS4, a language for production systems created at Carnegie-Mellon. One widely read summary gives the language as OPS5, a close relative, instead.

The clever part was the method McDermott called Match. Many AI programs of the time guessed a solution, tested it and backtracked when it failed. XCON's rules carried enough knowledge to recognize, at each step, a move that was guaranteed to lead toward a valid configuration. So it rarely had to back up. In the paper's tests it worked through each order in about 2.5 minutes of computer time, firing around a thousand rules.

Here is a simplified picture of how a few rule firings build up an order (an illustration, not XCON's real rules):

Real XCON rules were longer and very specific. One, given in English in the paper, covers assigning a dual-port disk drive to two controllers when neither has any devices yet.

Building and testing it

Development began in December 1978. McDermott spent five or six days being taught VAX configuration, read DEC's two configuration manuals, and in about four months wrote a first version with fewer than 200 rules. It handled simple orders but made many mistakes on complex ones. For the next four months, DEC's configuration experts checked its output and pointed out errors; each criticism led to a fixed or split rule, and its knowledge almost tripled.

In October and November 1979, six experts examined its work on 50 orders, spending one to two hours on each. They found 12 pieces of faulty knowledge; once those were corrected, all 50 orders came out right. By mid-1980, R1 had configured more than 500 orders, and DEC's sales staff were starting to use it too.

The story behind the name is a joke about the new job title of "knowledge engineer." In the paper's footnote McDermott writes that four years earlier he could not even say the phrase; the popular retelling has him saying that three years before he couldn't spell it.

Why it mattered

XCON proved that an AI program could do daily, valuable work inside a big company. It grew to about 2,500 rules, and by 1986 it had handled some 80,000 orders with 95 to 98 percent accuracy. Estimates of its value differ: one puts DEC's savings at about $25 million a year, another at $40 million over six years. DEC followed it with XSEL, which helped salespeople configure systems with customers, and XSITE, which planned the site where a computer would be installed.

Coming right after the funding cuts of the 1970s, XCON helped turn expert systems into a business. In 1999 McDermott's paper received the AAAI Classic Paper Award.

What happened to expert systems after XCON?

Through the 1980s, companies raced to build their own. Software "shells" made it easier to write rule-based systems, specialized Lisp computers were sold to run them, and governments launched programs such as Japan's Fifth Generation project.

Then the limits showed. Rule bases like XCON's needed constant upkeep as products changed, and every new rule could interact with old ones. The systems could not learn on their own and behaved badly with unusual inputs, a weakness called being "brittle." The market for Lisp machines collapsed in 1987, and a second AI winter followed in the late 1980s and early 1990s.

Rule-based systems did not disappear, though. In 2019 rule engines still run quietly inside many business tools, such as product configurators much like XCON. What changed is that the headline progress in AI moved to systems that learn rules from data instead of having experts write them by hand.