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 for the working memory given above might be informally written as
Rule 31condition:
[birdcage is open] and
[tweetie is in birdcage] and
[sylvester is in room]
action:
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
[birdcage is closed]
[tweetie is in birdcage]
[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 1condition:
[user inserts coins]
action:
print: "Would you like tea or coffee?"
read: [RESPONSE]
remove: [user inserts coins]
add: [user wants RESPONSE]
Rule 2
condition:
[user wants coffee]
action:
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.