I have found a way to undercut the speed of a goals terminal run.

This consists of a discovery of a new piece of the puzzle — The Modifier.

By use of the Modifier the basic terminal of a goals chain may be isolated without running off the upper terminal.

Routine 3 consists of finding a goal, finding a terminal and running it on the Pre- Hav Scale, combined with sec checking. Then one finds a new terminal for the goal, etc, etc.

ROUTINE 3A consists of:

1. Having pc write a goals list.
2. Adding various types of goals to the list (Secret, etc).
3. Assessing the list and locating the goal by elimination. (The above steps are unchanged from Routine 3.)
4. Compiling a list of MODIFIERS by asking the pc what would make the goal impossible to attain, what would keep it from happening, what would be its consequences if attained, etc.
5. Assessing Modifier list by elimination. (Assess Modifiers without repeating goal.)
6. Combining goal and Modifier as the question for terminal (who or what would [goal & modifier] ) and compiling a terminals list.

1. Assessing terminals list by elimination to obtain the terminal. (Same as Routine 3)
2. Assessing Pre-Hav Scale for level. (Same as Routine 3)
3. Forming multi-bracket commands and running or using a packaged command. (Same as Routine 3)

Routine 3A is also combined with ordinary sec checks as well as a Dynamic sec check gained from a Dynamic Assessment.

Havingness and Confront are also found and used during auditing of terminal on levels.

The resulting terminal will be found to be more fundamental than the Routine 3 type terminal and should run much faster.

I developed this by deducing that if a goal is held in suspense in time, it must have another side to it like a problem.

A problem is postulate-counter-postulate.

To stay fixed, a goal must have a counter-postulate.

Both goal and Modifier must be contained in one basic terminal, otherwise the postulates would not be out of reach of the pc.

This terminal may be far more real to the pc and the whole package may blow more rapidly.

In those cases where a goal has been found, do Routine 3A Steps 4 through 9. Get Modifier and terminal checked out when found.

So far the Modifier list has been very short, the pc getting it on the first question in some cases and half a dozen in others. Ten would seem a fair number.

Definition: A Modifier is that consideration which opposes the attainment of a goal and tends to suspend it in time.

In practice all Modifiers so far found have Dianetic type denyers in them which put them semantically out of sight.

Example: Goal: To be a Willow Wand. Modifier: So as never to be reached. Accordingly, the pc also never reaches the Modifier in his thinking but dramatizes

it.

Goal + Modifier for terminal use would be “Who or what would be a willow wand

so as never to be reached”. Terminal assessed from list: “A bending reed”.

In those cases that have gone Clear, the Modifier ran out, almost unnoticed. In those cases that haven’t gone Clear, the pc is still dramatizing the Modifier while running the goal and cleaning off one terminal from a chain.

I suppose we may find in some cases that we have the Modifier but not the goal. In such a case the question would have to be (in Step 4 above) “What goal would make one eventually decide to be that way”. I do not know positively of any such cases as yet, I am only providing for the possibility. Where the person’s “goal” seems to be a defeat, I would suspect it was the Modifier with the goal before it not yet found.

Nothing in this means that all terminals are wrong. Some may be found to be the same terminal as before. Others will be found to be more basic. A few will seem not to compare.

All cases now running on a goals terminal as per Routine 3 should be reassessed at once as per Routine 3A to save time in auditing.