Chapter 6 — Building a rule system (a real historical example)

MYCIN: the system that worked and was never used

In the 1970s, Stanford built MYCIN to diagnose blood infections and recommend antibiotics. About 600 rules, looking like this:

IF   the infection is primary-bacteremia
AND  the site of the culture is one of the sterile sites
AND  the suspected portal of entry is the gastrointestinal tract
THEN there is suggestive evidence (0.7) that the organism is bacteroides

Two things to notice:

The 0.7 — a "certainty factor". Real knowledge isn't black and white, so MYCIN attached confidence numbers and combined them. (These were later shown to be mathematically inconsistent with probability theory, and were replaced by proper Bayesian networks in the 1980s.)
It could explain itself. Ask "WHY are you asking about the portal of entry?" and it would show you the rule it was trying to satisfy. Ask "HOW did you conclude bacteroides?" and it would print the chain. No LLM can do this — that traceability is the enduring superpower of symbolic systems.

MYCIN performed as well as or better than Stanford infectious-disease faculty in a blinded evaluation. And it was never deployed. Why:

Maintenance: keeping 600 rules current as medicine changed was more work than it saved.
Integration: no hospital IT to plug into (this was the 1970s).
Liability: who is responsible when the machine is wrong?
Data entry: a doctor had to type in dozens of facts per case.

The lesson that still applies

Reason 1 is the one that generalises. It has a name: the knowledge-acquisition bottleneck. Getting knowledge out of experts and into rules is slow, expensive, incomplete, and never finished. Machine learning's entire pitch is: don't extract the knowledge — extract the data, and let the machine find the rules.

Where rule systems are still the right answer (this is important)

Do not read Part 2 as "rules are obsolete". Use rules when:

Situation	Why rules win
Tax, payroll, billing, compliance	The rules are literally written in law. You need them applied exactly and traceably.
Safety limits	"Never spend more than X", "never send data outside the EU" must be guaranteed, not probable.
Auditability required	Regulators want "why?" answered with a rule, not "the weights said so".
No data available	A new product has zero historical examples; you have domain knowledge instead.
Combinatorial problems	Scheduling, routing, timetabling — use a solver, not a neural net.

A modern production system is usually a hybrid: an LLM handles language, and deterministic code enforces the rules that must not be violated. We'll build exactly that in Part 11.

Practice (15 min)

Write down three rules that your workplace (or a workplace you can imagine) must enforce deterministically — things you would never let a probabilistic model decide. Examples: refund limits, access permissions, data-residency.

This list is a useful instinct to develop early: know what must never be learned.

Check yourself

What is the knowledge-acquisition bottleneck?
Name two things MYCIN could do that an LLM cannot.
Give a situation where you should use rules, not ML.