Goal and impasse object augmentations
-------------------------------------

When Soar detects an impasse for a context slot, it responds by creating a
new goal (see Section See Impasses and subgoals on page *Note Impasses
and subgoals:: for more details on subgoals, impasses, and the results of
subgoals).  When Soar detects an impasse for a non-context augmentation, it
responds by creating an *impasse object*.  These two types of impasses are
distinguished by their ^type augmentation ({goal} and impasse).  They are
also distinguished by the fact that the goal becomes the basis for a new
context, where problem spaces, states, and operators can be selected
following quiescence.  The impasse object is just like any other object,
except that it is not linked to the context.

In spite of these differences, both a goal and an impasse object are created
with the same augmentations that describe the impasse responsible for their
creation---additional augmentations may be created by productions.  The list
below gives the seven augmentations that the architecture creates, and the
values that each augmentation can contain.

[type]  Either goal or impasse, depending on     
     whether it is a context impasse with a goal, or an attribute impasse.
     
[impasse] Contains the impasse type: tie,     
     conflict, no-change, or constraint-failure.
     
[choices] Contains multiple (for tie and conflict     
     impasses), none (for no-change impasses), or constraint-failure (for
     constraint-failure impasses).
     
[object] Contains the identifier of the  augmentation for which     
     the impasse arose.  For a context impasse, this will be the supergoal.
     
[attribute] For multi-choice and constraint-failure impasses,     
     this contains the attribute for which the values were competing.  In a
     context impasse, this would be problem-space, state, or {operator}.  For
     no-change impasses, this contains the attribute of the last context slot
     with a value (goal, problem-space, state, or operator).
     
[item] For multi-choice and constraint-failure impasses, this     
     contains all values involved in the tie, conflict, or
     constraint-failure.  If the set of items that tie or conflict changes
     during the impasse, the architecture removes or adds the appropriate
     item augmentations without terminating the existing impasse.
     
[quiescence] Goals are the only objects with     
     quiescence t, which is an explicit statement that quiescence (exhaustion
     of the elaboration cycle) was reached in the supergoal.  If problem
     solving in the subgoal is contingent on quiescence having been reached,
     the subgoal should test this flag.  The side-effect is that no chunk
     will be built if it depended on that test.  See Section *Note Chunk
     creation:: on page See Chunk creation for details.

The following is an example of a goal context that is created for a tie
between three operators:

(G12 ^type goal ^impasse tie ^choices multiple ^attribute operator 
     ^object G3 ^item O9 O10 O11 ^quiescence t)

The following is an example of a goal context that is created for a no-change
impasse to apply an operator as well as part of the super-context:

(G12 ^type goal ^impasse no-change ^choices none ^attribute operator 
     ^object G3 ^quiescence t)
(G3 ^operator O2)

The following is an example of an attribute impasse that is created for a tie
between two values of the color augmentation:

(i12 ^type impasse ^impasse tie ^choices multiple ^attribute color 
     ^object G3 ^item O9 O10 ^quiescence t)