Production systems: rules, working memory, recognize–act
The three components of a production system and the control loop that turns rule-firing into state-space search.
What a production system is
A production system is the architecture underneath rule-based AI — every expert system in Module 6 is one. It has exactly three components, and you should be able to name all three cold:
- Production rules — a set of *condition–action* pairs. The condition is a pattern; the action says what to do when the pattern matches. Written
IF conditions THEN action. - Working memory — the current description of the world: the facts the system currently holds. Rule conditions are matched against working memory.
- The recognize–act cycle — the control loop. It (a) matches working memory against every rule condition, (b) collects the rules that match into the conflict set, (c) picks one by conflict resolution, (d) fires it (runs its action, changing working memory), and repeats until no rule matches.
These three map *exactly* onto state-space search: rules are the operators (arcs), working memory is the current state (node), and the recognize–act cycle is the search strategy. A rule is enabled when its conditions are all present in working memory; the set of enabled rules is the conflict set, i.e. the applicable operators at this state.
Conflict resolution
When several rules are enabled at once, the system must choose. This is where heuristic control enters. The three classic strategies (from OPS5) are:
- Refraction — a rule may not fire again on the same data, preventing loops. - Recency — prefer rules matching the most recently added facts (keeps a depth-first focus on the current reasoning thread). - Specificity — prefer the rule with *more* conditions (a more specific rule beats a general one).
Worked example: a recognize–act loop
Working memory starts with {has_feathers, cannot_fly, swims}. Three rules classify a bird. We use specificity to break ties and refraction so each rule fires once.
- Cycle 1: only R1 (1 condition, has_feathers) is enabled → fire it → assert is_bird.
- Cycle 2: now R2 (is_bird ∧ cannot_fly ∧ swims) and R3 (is_bird ∧ can_sing) are candidates, but can_sing is not in working memory, so only R2 is enabled → fire → assert is_penguin.
- Cycle 3: no rule matches new data → halt.
Each firing is one application of modus ponens and one arc in the state-space graph. The full trace *is* the proof.