
| FHJ                | DHJ   |       |       |       |
|--------------------|-------|-------|-------|-------|
| x¯                 | s.d.  | ¯x    | s.d.  |       |
| Rules              | 188   | -     | 175   | -     |
| Decision Avg.      | 87.1  | 20.9  | 141.1 | 38.7  |
| Avg. Rule Firings  | 720.3 | 153.5 | 855.6 | 199.6 |
| Avg. CPU Time (ms) | 413.1 | 121.6 | 391.6 | 114.0 |

Table 1: Summary of knowledge and performance data from the Blocks World. The agents performed the tower-building task for each of 981 configurations. Task order was randomly determined.

## 4.3.1 Knowledge Differences

Total knowledge decreased about 7% in the DHJ agent. This small reduction is consistent with expectation. The aggregate comparison is misleading because knowledge was both added (16 productions) and deleted (29).

Removing Consistency Knowledge**: In Soar, the subtask operator and subgoal are**
terminated separately. Soar monitors impasse-causing assertions to determine if a subgoal (such as the subtask goal) should be removed via FHJ. However, the removal of a subtask operator requires knowledge. The original, FHJ architecture treats the initiation of an operator as a persistent assumption and requires knowledge **to recognize when a selected**
operator should be interrupted or terminated. This knowledge can be categorized as consistency knowledge because it determines the time at which a subtask should be terminated, even when the initiating conditions for the subtask no longer hold.

In DHJ, only the effects of operators are persistent; all other assertions are entailments of the situation. Thus, the initiation of a subtask is now treated as an entailment and a subtask remains selected only as long as the initiation conditions for the subtask hold. This change removes the need for knowledge to terminate the subtask: when the subtask initiation conditions are no longer true, the subtask is automatically retracted. Thus, termination knowledge was removed for all subtask operators.

Filling Gaps in Domain Knowledge**: The persistence of subtasks in the original architecture allows FHJ agents to ignore large parts of the state space in their domain knowledge.**
For example, the knowledge that initiates stack and put-on-table **subtasks assumes that** the gripper is currently not holding a block. As these tasks are executed, the gripper, of course, does grasp individual blocks. The conditions for initiating stack or put-on-table when holding a block were ignored in the original domain knowledge.

The DHJ agent now requires knowledge to determine which subtasks it should choose when holding blocks, because subtasks can be interrupted while the agent still holds a block. 16 productions were necessary, primarily for the stack and put-on-table **operators. It is** important to note that this knowledge is necessary domain knowledge. FHJ agents could not solve any problem in which they began a task holding a block because they lacked domain knowledge for these states. These additions are thus **a positive consequence of**
DHJ. The architecture's enforcement of consistency revealed gaps in domain knowledge.