3. Production Systems: Simulating the Black Box

We have shown how subjects may solve problems by examining the current problem state and then choosing an appropriate and applicable rule to transform that state into a new state in the search for a solution. A production system is a means of codifying this rule-based knowledge. It has three major components that are analogous to the knowledge states, mental operations, and decision-making of the human problem solver:

  1. a global database of facts called the working memory,
  2. a set of production rules, called the rulebase, that operate on those facts, and
  3. a program called the production system interpreter that decides which rule to use in a particular problem state.

3.1. The Working Memory

The contents of the working memory represent what the system `knows' about the problem at any one moment. At the start, this is the initial knowledge state, which is transformed into a new state each time an operator (production rule) is applied. At its simplest, working memory can be represented as a simple database of facts—for example,

known( [birdcage, is, open] ).
known( [tweetie is in, birdcage] ).
known( [sylvester, is, in, room] ).

At any one time the size of working memory is usually very small, just as the number of distinct items that the human mind can hold in short-term memory is small.

3.2. The Rulebase

The rulebase contains the system's equivalent of what we have previously called `operators', the `if-then' operations that change states of knowledge. In a production system, they are called production rules, or simply `productions', the conditions (the `if' part) sometimes being referred to as the rule head and the actions (the `then' part) as the rule body. Although looking superficially like `if ... then ...' statements in a programming language, they operate in a different manner. Each rule represents an independent `chunk' of knowledge which can be initiated, or fired, when the entire condition matches items in working memory. Once the rule is fired, its actions are carried out, which usually (but not always) involves removing facts that are no longer true from working memory and adding new facts that have become true. A typical rule matching the working memory given above might be written as

   rule close_cage :
       if    [birdcage, is, open] &
             [tweetie, is, in, birdcage] &
             [sylvester, is, in, room]
       then  remove [birdcage, is, open] &
             add [birdcage, is, closed].

Translated into more natural English it reads, "If ever you discover that Tweetie's cage is open while Sylvester is in the room, and that Tweetie is still in his cage, then close the cage." That is, remove the fact that the [birdcage, is, open] and add the fact that the [birdcage, is, closed]. Firing the rule will change the database in such a way that the contents of working memory become

	known( [birdcage, is, closed] ).
	known( [tweetie, is, in, birdcage] ).
	known( [sylvester, is, in, room] ).

In this example the actions to be taken on satisfying the conditions are simply to add facts to and remove facts from the database. This need not always be so; in other circumstances the actions might be of the form "Print this message to the terminal" or "Read what the user types on the terminal and add it to the database in some form"; or may just contain the instruction `stop'. For example, an automated drink dispenser might use rules such as

   rule 1 :
       if    [user, inserts, coins]
       then  print `Would you like tea or coffee?' &
             read RESPONSE &
             remove [user, inserts, coins] &
             add [user wants RESPONSE].

   rule 2 :
       if    [user, wants, coffee]
       then  print `How would you like your coffee: black or white?' &
             read RESPONSE &
             remove [user, wants, coffee] &
             add [user, wants, RESPONSE, coffee].

The capitalized RESPONSE in each rule would be a variable local to the production rule in which it is elicited. We shall see further examples of actions of this kind that permit interaction with the user, and use variables in rules, in our Automated Tourist Guide in the next section.

Production rules are unordered, in that irrespective of the order in which they are physically written into the production system rulebase (and hence the order in which they would appear, for example, on the printed page), the sequence in which they are used will depend on the current state of the working memory. (By way of analogy, think of how you might look for definitions in a dictionary or encyclopedia. Suppose the word you start with is `dugong': the definition contains further unknown words, which in turn you look up under their alphabetical listings, and so on. Your search is guided by your current state of knowledge at each moment, in such a way that you move back and forth from one entry to another, and not serially from A to Z.) If more than one rule is triggered (its head matches the database), a conflict resolution strategy is used to decide which rule is to be fired. Three types of conflict resolution strategy are listed in the next section.

In certain production systems—for example, Waterman's PAS II system for doing addition, or Newell's PSG system, used to test psychological theories about human memory and recall—rule order can be important, and the rules are tried in the order in which they are written into the rulebase, so that conflict between rules does not arise.