There are two ways that were described for implementing this task. In the first, a goal hierarchy was specified for each of the individual operators in subtraction (e.g., borrow, regroup, write difference, etc.). This implementation utilized a number of pre-specified problem spaces and a lot of control knowledge, resulting in very little opportunity for learning.
The second implementation featured only a single problem space and little control knowledge; only the operators were detailed beforehand. Every operator was considered acceptable at every state in the problem space; thus, productions were included that generated acceptable preferences whenever the operators are considered. The task of this system then is to learn the subtraction procedure (since there are no pre-specified choices for preferring one operator over another). As problem solving progress, tie impasses are generated for the acceptable operators and chunks are created that create best preferences for the operators that led to the solution. These learned chunks are general; only one or two chunks are generated for each operator. The generality of the chunks derives, in this case, from operator subgoaling; problem solving for the application of an operator is minimal, based on the each operator's simple preconditions, and thus results in general chunks. Generality also comes from the choice of representation: the way in which the operators were implemented allowed chunks to be built without testing the value of each digit. Such a careful choice of representation is an issue in the design of Soar systems.
Go to a discussion of this capability for multiple architectures.