Echoes
Echoes
XCON and the Maintenance Paradox
XCON configured VAX computers for Digital Equipment Corporation through the 1980s, hundreds of orders a day, and it worked. Start there. Early on, maintaining it meant teaching it: find the gap, add the knowledge. Years and contributors later, developers were uncertain what some rules did and reluctant to touch them. Digital started a redesign not because the system was failing but because it was getting hard to change. That transition has less to do with expert systems than with what happens whenever encoded knowledge becomes the thing you can't turn off.
XCON and the Maintenance Paradox
XCON configured VAX computers for Digital Equipment Corporation through the 1980s, hundreds of orders a day, and it worked. Start there. Early on, maintaining it meant teaching it: find the gap, add the knowledge. Years and contributors later, developers were uncertain what some rules did and reluctant to touch them. Digital started a redesign not because the system was failing but because it was getting hard to change. That transition has less to do with expert systems than with what happens whenever encoded knowledge becomes the thing you can't turn off.
Scale in Numbers
XCON was an expert system that configured Digital Equipment Corporation's computer orders — matching components, checking compatibility, generating floor plans. It went into production in 1980 with about 700 rules. By 1987 it had grown to 6,200 rules drawing on roughly 20,000 parts, and it worked: DEC's engineers reported "no problem with XCON's performance."
Keeping it current was the problem. Fifty percent of those rules changed every year — around 3,100 modifications annually. Each change required understanding how one rule interacted with thousands of others, and the people who'd written the originals had often moved on. Rule rationale lived in someone's memory, or nowhere. The engineers noted that update costs "do not grow linearly." The codebase became what they called "a rat's nest of special rules, tightly coupled rules," while still producing correct output.
Agent systems that maintain representations of APIs, form fields, and business rules across target platforms face the same grind. The external world doesn't hold still while you figure out what broke.
Parallel Failure Modes
When the List Broke
Anti-virus software started with a simple bet: name every known threat, update the list weekly, scan for matches. It worked fine when there were a few hundred viruses. Then new malware samples hit hundreds of thousands a day, and the list became impossible to keep current. The industry had to surround signatures with behavioral detection, reputation scoring, and heuristics — layers that could characterize threats nobody had named yet. A story about what happens when the thing you maintain grows faster than you can update it.
When the Combinations Outgrew the Room
After deregulation, American Airlines carried over 500,000 fares in its reservation system. Every rule made sense on its own. But nobody could predict what the system would do when you changed one, because the interactions between fare classes, routing constraints, and capacity controls across a flight network had outgrown any person's ability to hold them. The fix wasn't better rules. It was a statistical layer that absorbed combinations no human could work through by hand. A different kind of maintenance failure than the one next door, with a similar ending.
Source Trails
