MYCIN Made the Questions Part of the System

The chemists working with DENDRAL could judge a proposed molecular structure against a spectrum and their own specialist knowledge. In the 1970s, another Stanford team took the same broad idea into medicine. The program, MYCIN, asked about a patient and proposed advice concerning infectious disease and treatment. A wrong proposal there was not merely an unhelpful hypothesis for a chemist to discard. The stakes of the question changed the engineering work. (National Library of Medicine, MYCIN history)

MYCIN is often introduced as a system of if–then rules. That description is accurate and incomplete. A rule can connect an observed condition with a possible conclusion, but somebody must decide which conditions the program should ask about, what to do when an answer is missing, how strongly the conclusion follows, and how to explain the path it took. The knowledge engineer could not simply collect medical statements and wait for intelligence to appear.

A rule needs a situation

Imagine a rule that says a particular finding supports one diagnosis. The sentence alone leaves open who observed the finding, whether the observation is reliable, whether another condition changes its significance, and what the system should do if the laboratory result is not yet available. A physician working through a case can ask another question or notice that a detail does not fit. A computer program needs a designed way to request and use those details.

The MYCIN work made that design visible. Its question-and-answer exchange drew the user through a case. Its rules expressed specialist distinctions about organisms and treatments. It also represented degrees of confidence using a method called certainty factors, an attempt to work with incomplete and uncertain information without pretending every medical claim was simply true or false. Those numbers did not turn clinical judgment into arithmetic. They supplied a way for this research program to combine uncertain evidence and expose the basis of a recommendation. (Shortliffe’s account of MYCIN)

That last point matters because an answer without its route is difficult to examine. A user could ask MYCIN why it wanted a particular piece of information or how it reached a conclusion. The explanation was generated from the structure of its reasoning. The program did not have to invent a plausible story afterward; the rules it had used remained available for inspection.

There are limits here. An explanation of which rules fired is not necessarily a complete medical explanation, and a traceable route does not make its premises correct. The system could show its work while still depending on a mistaken observation, a missing exception, or a rule that no longer reflected practice. Traceability helps a specialist inspect an answer; it does not transfer professional responsibility to the software.

The expert and the engineer did different jobs

The characteristic arrangement was a subject expert working with a knowledge engineer. The expert understood the medicine. The engineer investigated how selected parts of that expertise could be represented and used. Both were needed to decide whether the resulting program asked sensible questions and produced advice worth considering.

This work could not be completed in one interview. A case exposed a missing question; another exposed a rule that was too broad. A specialist’s answer might depend on context they had not thought to mention until a proposed recommendation looked wrong. The engineer then had to revise the representation and examine the next case. This was the DENDRAL method under a different kind of pressure.

MYCIN was an important research demonstration, not evidence that computers had replaced physicians. The distinction protects the history from its own publicity. It was possible to build a program that applied a considerable body of medical rules and explained parts of its reasoning. It was much harder to establish a complete, current, accountable clinical system in a changing institution. (National Library of Medicine, MYCIN history)

Naming the work

Edward Feigenbaum’s 1977 paper, “The Art of Artificial Intelligence: Themes and Case Studies of Knowledge Engineering,” gave the field a public name while such systems were being built. It argued from cases in which specialist knowledge, represented with care, supplied much of an AI system’s practical power. (Feigenbaum, 1977)

The name carried a problem inside it. Engineering suggests that an object can be specified, built, tested, and maintained. Human expertise is not always so orderly, and in medicine its use carries institutional and professional obligations the rule base cannot absorb. The next decade would put knowledge systems into commercial operations. There, the burden of maintaining them would become impossible to treat as a research footnote.