Memra

Production systems: rules, working memory, recognize–act

◈ 3 cards

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:

  1. 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.
  2. Working memory — the current description of the world: the facts the system currently holds. Rule conditions are matched against working memory.
  3. 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.

Production rulesIF conditions THEN action — R1, R2, R3, fixed for the whole runRecognize–act cyclematch, collect the conflict set, resolve, fire, repeatWorking memorystarts {has_feathers, cannot_fly, swims}; grows as rules firefixedchanges every cycle
The control loop is the only component that touches both of the others. Rules sit above it and are never rewritten during a run; working memory sits below it and is rewritten by every firing — which is exactly the long-term / short-term memory split Newell and Simon were modelling.
matchWM vs rulesconflict setR2 onlyresolvespecificityfire R2+ is_penguin
Cycle 2 of the worked example, left to right: matching finds only <code>R2</code> enabled, specificity picks it, and firing asserts <code>is_penguin</code>. <strong>The last arrow is not drawn: control returns to <em>match</em></strong>, because working memory just changed. The loop ends only when the conflict set comes back empty — cycle 3.
strategypreferswhat that buysrefractiona rule not yet fired onthis datathe same rule cannot loopforeverrecencyrules matching the newestfactsa depth-first focus on onethreadspecificitythe rule with moreconditionsa special case beats thegeneral one
Conflict resolution is where heuristic control enters a production system — it is the operator-selection heuristic of state-space search wearing rule-based clothes. The worked example uses two of the three at once: specificity to choose, refraction to stop.
NORMAL ~/memra/learn/comp-456/production-systems-recognize-act utf-8 LF