XCON Took Expert Systems Into Daily Operations

A computer order can look complete on paper and still fail when the parts reach the factory. A component needs a compatible enclosure, a cable, a particular arrangement, or another component the customer did not know to request. Someone who configures these systems every day carries a great deal of practical knowledge about those dependencies. When the number of products and possible combinations grows, the work becomes both repetitive and unusually easy to get wrong.

Digital Equipment Corporation used an expert system called R1, or XCON, to help configure computer orders. John McDermott’s 1982 account describes it in regular use by the company’s manufacturing organization. That made it a different kind of evidence from a convincing laboratory demonstration: the system had to participate in a continuing operational process. (McDermott, “R1: A Rule-Based Configurer of Computer Systems”)

A configuration is a set of obligations

The system’s job was not to remember a catalogue. It had to work out how ordered parts should fit together and which additional parts were required. That meant representing relationships among products, physical arrangements, and constraints, then applying them to an individual order.

The distinction is familiar outside computing. An engineer reviewing a proposed assembly needs more than a list of parts; they need to know which version of each part is involved, what it connects to, and which requirements apply in this particular arrangement. XCON made that kind of knowledge operational. Its rules did not merely describe the product line. They affected what the factory would build.

That usefulness changed the threshold for success. A demonstration can choose cases that show the idea clearly. An operational system receives the awkward order placed on Tuesday, the newly released product, the exception that sales promised, and the part that has just been withdrawn. The knowledge base must remain aligned with a moving business. Where it does not, a neat rule can produce an expensive mistake.

Maintenance was part of the product

Commercial expert systems expanded during the 1980s, and knowledge engineers consequently needed to establish requirements, work with operational specialists, test real cases, investigate failures, and keep rules current. A rule base could grow far beyond the size a single person could hold in mind. One change might make an earlier rule obsolete or create an interaction nobody intended.

The difficulty was not only that experts were busy and hard to interview. Products changed. Local practices differed. Experienced workers sometimes agreed on the usual case while disagreeing about an exception. New people arrived with different language for the same component. Knowledge engineers needed to preserve coherence across these changes, not simply add every new statement to the pile.

An order that fails exposes two possible defects. The system may have represented the rule incorrectly, or the rule may no longer describe the product and process. The repairs differ. One calls for a correction to the model or software; the other calls for renewed consultation with the people who own the work. A third possibility is that the order itself sits outside the intended scope. Treating every failure as a missing rule can make a knowledge base larger without making it better.

This is why the commercial history matters. XCON showed that represented expertise could do useful work at scale. It also made knowledge maintenance a continuing cost of that usefulness. Rules had owners, dependencies, and consequences, even when the early language of expert systems made them sound like self-contained pieces of advice.

The system could not freeze the factory

I find the XCON case more instructive when it is read as an account of operations than as a claim about machine expertise. The system did not need to resemble a human configurator. It needed to help produce correct configurations amid changing products and real orders. That required an arrangement for finding errors and revising the knowledge on which the program relied.

The 1980s made the maintenance problem visible. The next difficulty was more fundamental. If the rules depended on what experts said, what happened when experts could not state all the distinctions they used, or when their descriptions of the work disagreed with what they did? The field had called this knowledge acquisition. The term was about to look much too simple.