Overview
========

The PSCM level of description for Soar is not directly implementable on a
computer.  It is defined solely by the functions to be performed in support
of search in a problem space to achieve a goal.  To define Soar, we must go
to a lower level that specifies how symbol structures are stored and
processed.  The purpose of this lower level is to flexibly support the PSCM.
In this chapter we give an abstract characterization of the Symbol-Level
Computational Model (SLCM) of Soar.  This abstracts away from the specific
syntax used in Soar as well as many of the implementation details, which are
presented in later chapters. This chapter ends by returning to the PSCM
functions defined in the previous chapters and demonstrating how the abstract
SLCM supports them using the Blocks World problem presented earlier.

Seven design decisions have been made in Soar's SLCM, all of which have
significant implications for realizing the PSCM functions in a flexible
manner.

  1. Knowledge is stored in a permanent recognitional memory and a temporary
     *working memory*.  Knowledge can be added to permanent memory, but it
     can not be changed or removed.  Permanent knowledge may be relevant to
     many different situations, but is not necessarily relevant to the
     current goals being attempted.  The memory for permanent knowledge is
     recognitional in that it continually tests the working memory.  Whenever
     permanent knowledge is found to be relevant to the contents of working
     memory, it proposes changes to working memory.
     
     In contrast to permanent memory, the contents of working memory persist
     only as long as they are relevant to the current goals.  The contents of
     working memory act as retrieval cues for permanent memory and are the
     basis of all decisions made by the architecture.
     
  2. Permanent memory only proposes changes to working memory through
     *preferences*, and does not actually deliver such changes.  These
     preferences are held in *preference memory* and changes to working
     memory are made based on a synthesis of the preferences in preference
     memory.
     
  3. All goals, problem spaces, states, and operators are explicitly
     represented by symbols in working memory once they have been proposed.
     This does not mean that the complete description of these objects is
     available, only that they are symbolized.  For example, an operator's
     preconditions and actions may never be explicitly represented; rather,
     only a symbol may represent a proposed operator.
     
  4. For each goal, there is at most a single current problem space, state,
     and operator.  This eliminates parallelism at the PSCM level.
     
  5. For each goal, there is only one state available in working memory.
     This is the *single state principle*.
     
  6. The selections of the current problem space, state and operators are
     explicitly represented by a *goal context* in working memory.  A goal
     context consists of a goal, together with the current problem space,
     state, and operator.  The explicit representation of the goal context
     makes the current selections available as retrieval cues from memory.
     
  7. There is no *a priori* control scheme that restricts the order in which
     PSCM functions are performed. For example, it should be possible to
     change the problem space in the middle of applying an operator, if new
     data suggests the current problem space should be terminated and a new
     one selected.

These assumptions lead to an SLCM where the PSCM functions for selecting
problem spaces, states, and operator are implemented by deciding on the
current values for the goal context.  These decisions are based on the
knowledge retrieved from permanent memory using the PSCM functions for
proposing, comparing, and adding refinements to the problem spaces, states,
and operators.  Operator application is performed by modifying the
representation of the state in working memory, while all PSCM functions for
manipulating goals are performed directly by the architecture.

The PSCM functions can be partitioned into the following symbol-level
operations:

PSCM Functions                                Supporting SLCM operation 
-----------------------------------------------------------------------------
Proposing, selecting, and terminating goals   Performed by the architecture 
Proposing, comparing, and refining objects    Retrievals of preferences 
                                              from permanent memory 
 
Selecting objects                             Decisions for the values of 
                                              a goal context 
Operator application                          Modifications to the state 

To realize the PSCM functions, the Soar architecture must support a permanent
memory with recognitional capabilities, a scheme for deciding on the values
of the goal context, a process for modifying states, and a mechanism for
processing goals. Sections See Working memory, *Note Recognition
memory::, and See Preference memory describe Soar's memory structures
(working memory, permanent recognition memory, and preference memory).
Section See Preference processing describes how preferences are processed
to determine the contents of working memory.  This preference-processing
scheme supports the creation of working memory elements, the selection of
problem spaces, states and operator, and the application of operators.
Section See Impasses and subgoals presents impasses, which are
responsible for goal processing.  Section See Learning gives an overview
of learning, and Section See Input and output describes input and output.
Section See Default knowledge describes the default knowledge that rests
on top of the SLCM.  This knowledge is available for all tasks, and acts as a
default response to the impasses that can arise during problem solving.  The
final section illustrates how the Blocks World task is encoded in the SLCM,
emphasizing how the abstract SLCM supports each of the PSCM functions.

Figure ? shows the abstract structure of the memory and processing components
and how they interact.  Starting from the left, {working memory} receives
input from perception.  Changes to working memory cue retrieval of
preferences from *recognitional memory*. The active preferences are stored in
*preference memory*.  The preferences are processed by the *decision
procedure*, which computes changes to {working memory}.  Traces of retrievals
from recognition memory are stored in {trace memory} which in turn are
process be chunking to build new productions which are added to recognition
memory.

*Recognition memory* contains the permanent knowledge that is encoded as
*productions*. Productions are simple "if-then" rules whose conditions
test the contents of working memory and whose actions create preferences.
Productions in recognition memory are *matched* against working memory and if
successful, add preferences to preference memory.  All productions, except
those involved in operator creation, instantiation, and application, also
remove their preferences from working memory when they no longer match.

Preferences that propose new context objects (problem spaces, states, and
operators) are also added to working memory so that they can serve as
retrieval cues for additional preferences that will determine which object is
selected to be current.

The main flow of information is shown by the dark arrows where match computes
changes to preference memory and decision computes changes to working memory,
which in turn leads to changes in match.

The working memory is also processed by *action*, which sends motor commands
to the system's effectors.  As productions are matched and fired, the
instantiated production traces are sent to *trace memory* which is then
processed by *chunking*.  The output of chunking is new productions which are
added to recognition memory.