Recognition memory
==================

The recognition memory contains *productions*, simple if-then rules that
consist of *conditions* (the if part of the rule) and *actions* (the
then part of the rule).  The conditions of productions are continually
matched against all of the contents of working memory.  Conditions can
contain variables, so that a single condition can match against different
data in working memory.
 
The action of a production is to create *preferences* for changes to working
memory. Thus, a production does not change working memory directly, but
instead creates preferences that are later combined by a decision procedure
to determine the contents of working memory.

If all of the conditions of a production are matched with consistent
bindings, the production is said to be *instantiated* with the working memory
elements that matched the conditions.  The preferences in the actions of the
instantiated productions are then added to preference memory.  In contrast to
most production systems, Soar fires all matched production instantiations in
parallel, without any conflict resolution.  This parallel firing of
productions is called an *elaboration cycle*. Parallel firing is possible
because the actions of the productions create preferences without modifying
working memory directly.  Therefore there are no race conditions or
inconsistencies between actions.  Inconsistencies will show up during the
processing of the preferences, where they can be handled explicitly.

Just as the elements of working memory must be linked, so must a production's
conditions.  That is, all conditions must either test a goal augmentation, or
they must test an augmentation that is linked through the variable for the
identifier to another augmentation that is a goal augmentation or is linked
to a goal augmentation.