Subgoal results
---------------

Because the working memory serves as a common database for all subgoals, it
is not necessary to have explicit parameters or results for subgoals.  Both
parameters and results are determined dynamically by the nature of the
processing in the subgoal.  The parameters to a subgoal can be anything in
working memory that is matched by a production during problem solving in the
subgoal.

Figure ? shows an example where there is a context (labeled supercontext)
with problem space top-ps, a state that contains a description of the
relationships between the blocks, such as ontop and clear, and operator
build-tower.  This operator can not be applied directly, so an impasse arises
and a subgoal is created to perform whatever processing is necessary to apply
the operator.  The circles in the figure are objects (goals, problem spaces,
states, and operators), with the far left object in each context being the
goal.  The boxes are constants, such as build-tower and move-block.  The
arrows represent augmentations.  For both contexts, the goals have
augmentations for the current problem space, state, and operator.  The
subgoal has an augmentation, created by the architecture, that points to the
supergoal.  The augmentation is called object, because the supergoal is the
object for which the impasse occurred.  Attribute-impasses also have object
augmentations that point to the object that has the impassed augmentation.

The subgoal's problem space is called blocks-world, and its state is the same
state as in the supercontext.  When the move-block operator is selected to
apply in the subgoal, productions fire to modify the state.  One of these is
shown at the right of the Figure ?.  This production matches the problem
space, state and operator of the subgoal, as well as some of the substructure
of the state, and then modifies the state by adding that A is on top of B.
By changing the state in the subgoal, the state of the supergoal is also
modified, and thus a result of the subgoal is generated.

In general, the *results* of a subgoal are all preferences that were created
in the subgoal, but are linked to a super-context.  A preference is said to
be created in a subgoal if the production that created the preference tested
the goal and this is the lowest (most recent) goal of the context-stack that
is tested.  Thus, if a production tests multiple goals, the preferences in
its actions are considered to be created only in the lowest of those goals.
The architecture automatically detects if a preference in a subgoal is linked
to a super-context.

A preference can become a result directly when it is created and its
identifier is already linked to a super-context as is the case in Figure ?.
A preference can also become a result indirectly if, after it is created and
it is still in preference memory, its identifier becomes linked to a
super-context through some other result.  For example, if the problem solving
in a subgoal is constructing an operator for a super-context, it may wait
until the operator structure is complete before creating an acceptable
preference for the operator in the super-context.  The acceptable preference
is a result because it was created in the subgoal and is linked to the goal
of the super-context.  The substructures of the operator then become results
because the operator's identifier is now linked to the super-context.

When a subgoal terminates, it is removed from working memory.  This unlinks
all preferences and working memory elements created in the subgoal that are
not results, causing them to be removed from preference and working memory.
The results remained linked, and will have I-support or O-support as
described below.

The type of support received by a result is determined by the PSCM function
it plays in the super-context, and not the function (such as operator
application or state refinement) it played in the subgoal.  For example, if a
result has only I-support in the subgoal, it must have some additional
support after the subgoal is terminated because many of the working memory
elements that were tested in the production that created the result will be
removed from working memory when the subgoal is terminated.  If the result
had O-support when it was created in the subgoal, it might not even be part
of a state in a super-context, or it may be independent of any operator
application in the super-context.  For example, in a subgoal to create a
problem space, the state may have a partial description of the problem space.
The problem space is created through operator application in the subgoal, but
within the goal in which the problem space will be selected it is created
through simple proposal and refinement.

In order for the architecture to determine the PSCM function that a
preference plays, there must be a production instantiation that determines
whether the preference should receive O-support or I-support.  The actual
support the preference received in the subgoal is irrelevant in the
super-context.  Thus, whatever support the preference had in the subgoal is
removed and the architecture creates an temporary production instantiation,
called a *justification*, that summarizes the processing in the subgoal that
led to the result.  The conditions of a justification are those working
memory elements that were necessary for producing the result and were not
removed by subgoal termination.  That is, the working memory elements where
matched by productions that fired on the path to the creation of the result.
The action of the justification is the result.

The justification includes any negated conditions that were in the original
productions that participated in producing the results, and that tested for
the absence of super-context working memory elements. Negated conditions that
tested for the absence of working memory elements that are local to the
subgoal are not included.  This can lead to some cases of overgeneralization
(see Section See Problems with chunking on page *Note Problems with
chunking:: for details).

The structure of the justification determines the appropriate support for the
result in the goal.  If the justification is an operator application or
operator instantiation production, the result will receive O-support.
Otherwise, the result gets I-support from the justification. If a such a
result loses I-support from the justification, it will be retracted if there
is no other support.  Because support is determined by the conditions and
actions of the justification, support in the super-context is completely
independent of the type of support received in the subgoal.  For example, a
preference created in a subgoal by applying an operator may be computing a
refinement of a superstate, or in contrast, a refinement of a state
(containing pointers to the superstate and superoperator) in a subgoal may be
part of an operator application for the super-context.