Soar

• Uniform knowledge representation

  All the knowledge in the Soar knowledge base is in the form of productions. These productions, or "chunks", can either be present at startup (supplied by the programmer), or aquired through learning.

• Preference-based reasoning

  Decisions in Soar are made using a preference-based procedure. Each operator or state suggested during Soar's elaboration phase has a particular preference associated with it expressing the desirabilty of choosing that operator or state with respect to the other operator or states suggested during the elaboration phase. Soar examines these preferences and chooses the operator or state that is most beneficial. This fearure can also be used as a forgetting mechanism, assigning the "rejected" preference to knowledge that is inconsistent with the current situation or goals.

• Procedural knowledge: Black box hypothesis

  Unlike PRODIGY's Glass box hypothesis, the learned productions in Soar are opaque. Once Soar learns a piece of knowledge and incorporates that into a production, the system cannot examine or alter that knowledge any longer. The productions can simply be fired reflexively as they were first learned when the appropriate preconditions appear.

• Reaction time

  The reaction time of Soar varies with experience. In a first run of the system on a problem, Soar usually contains few or no productions that apply to its current situation. This means that the system must deliberate about all or its actions, resulting in slow reaction time. However, as the system stores what it learns from experience into productions, or "chunks", its reaction time increases. On future runs of the same or similar problems, the relevant productions fire automatically, simulated a stimulus-response type system.

• Impasse driven

  The main operation of Soar in problem solving is to resolve impasses. Impasses occur when Soar does not know what to do, whether it be due to a complete lack of knowledge, choosing between to possible decisions, or one of a number of other possible impasses. Subgoals are created to resolve impasses, and by achieving these subgoals, Soar attempts to solve the problem.

• Reflexive learning

  Learning in Soar is reflexive. Anytime an impasse is resolved, Soar places the knowledge of how the impasse was resolved, including state preconditions and final conditions, into a "chunk". Thus, Soar saves the learned knowledge of how to resolve the impasse by keeping these "chunks", or productions, in its long term memory.

• Very large knowledge base

  The Soar system was designed to work with a very large knowledge base of productions. Because Soar learns reflexively whenever it resolves an impasse, it accumulates large amounts of knowledge during its existence. Soar systems have been known to have thousands, hundreds of thousands, and in some cases, even millions of productions or more without massive amounts of slow down in performance.

• Knowledge Access Efficiency

  With a very large knowledge base containing perhaps a million or more productions, accessing the knowledge in an efficient manner is an important issue for the architecture. During the Elaboration Phase in Soar, all the productions in the memory that apply are fired in parallel. This parallel operation allows the architecture to access all the relevant knowledge in the long-term memory in an efficient, tractable way.