6306C19 SHSpec-276 Summary of Modern Auditing

Processes fall into categories, according to which case conditions they
handle. Cases deteriorate as they go down the time track. One factor against
which they deteriorate is confront, and the other factor is duplication.
Confront has to do with willingness, and duplication has to do with ability.
As the PC becomes less willing to confront, he becomes less able to
duplicate. Similarly, processes are allowed to deteriorate [and fade out of
use] through failure of willingness to confront and ability to duplicate.
CCH's, for example, went out for five years through getting down into the
effort band. There was no duplication. You would have a very exact sort of
process if you ran, "What are you able to/unable to duplicate?", along with
other flows. You add more legs to it as the case needs more complexity. A
high-scale case, not being much troubled by flows, could go far on one leg
only. You can get different viewpoints on different flows, also. This can
give you TA action, where you might not otherwise get it. "You add enough
brackets to get TA." There is no perfect way to run brackets, since the number
of available flows is virtually infinite. The idea of flows is something that
monitors all case levels and breaks its back around Level 4. Above Level 4
any or all flows could be run. A person well downscale, below Level 4, almost
at the bottom, can only run one flow. Such a person can't function on any
other dynamic than the first. He can't conceive of another viewpoint, though
he needs to run more than one flow. There is a problem here.

This is a problem of the dynamics: How many can a person function on?
There are many facets of processing, by which you could match up a case to its
ideal process. You might be able to figure out the perfect process
mathematically, but there is the point about the need for workability that we
mustn't lose sight of. A process should not be "perfect". It should be
complex enough to be workable. The complexity factor also goes into the
number of processes you need. We should not emulate modern science. "Modern
science is a method of precisely determining overwhelming nonsense."

We also have to determine the common denominators present in all cases.
The processes that have survived the development of scientology are those that
have broad workability. They include ARC, the mid-ruds buttons, and common
incidents on the time track, the common denominators of all cases.
Kraepelin's list of psychiatric case types is ridiculous. It is like saying,
"I am auditing Betty, so it is a Betty case type," or "Well, everybody is a
George case type." In the first case, you get too many case types; in the
second case, you get too few. There is a middle ground. This is a finite
number of case types, classified according to their behavior in auditing
sessions, and a larger but still finite number of processes. It is only
useful to divide cases up into case types so that you can match them up to the
processes. the case types are based on behavior in session, not in life. You
get a finite number of them, then match them up with processes. that raise
the PC upscale.

You can't expect auditors to memorize more than a few types of auditing
processes perfectly. If you expect more of auditors than this, they end up
mixing types and styles of auditing and you get hash. Repetitive processing
seems easy, now that you are familiar with it. In fact, any type of
processing you have learned well presents no particular problem.

CCH's got badly learned. They are a kid glove type of process, since
cases that get CCH's exclusively are low on the effect scale and can't
tolerate being mauled about. [LRH tells an anecdote about dropping CCH's
because "they weren't getting results," then giving a TVD and discovering that
no one knew what he was doing.] They had utterly alter-ised the process. It
was then that he stopped just creating new processes and began to insist on
perfect duplication of what had already been developed.

We stopped accumulating process types when LRH found out that it was
variation that made processes and process types stop producing results.
People shifting from the original type of process would then apparently bring
about a need for a new process type. Process types are dependent on how many
you can keep in line. How to keep processes in line and working is a more
important factor than you might think. When a process seems to have stopped
working, you will find that variations from the original have crept in. The
simpler process types tend to survive better than the more complicated ones.
They are also perhaps easier to keep in line in their unvaried form. But even
the simpler ones will drift out of line.

A process can die when it is too simple and gets used very seldom. Reach
and withdraw is a good example of this type of process. It works at Level 8
and is the only type of process you could use on an animal. Processes that
work very slowly also tend to get dropped, since they are seldom run to a flat
point, so you don't see results. We don't really know how much reach and
withdraw processes can do.

Processes can vanish because of disrespect; we use one diffidently. ARC
processing disappeared for awhile because of this. That they are the only
workable processes for a certain type of case gets lost, and so those cases
get lost. Reach and withdraw is one of these. It is slow but sure and it is
almost lost from lack of respect for its potential. There are lots of
processes in the band of reach and withdraw that are ignored. Book and bottle
hangs right in between reach and withdraw and CCH's It contains duplication
like the latter, but is the former type of process. Lots of cases won't move
unless run on these processes. They won't move on CCH's. We mustn't lose
processes.

We have been pressing so much at the top of the scale of cases that the
bottom has been neglected, so these lower scale processes have dropped out.

The next division in processing is what the auditor knows is wrong with
the case vs. what can be done with the case. These can be two very different
things. Modern processes have nothing to do with what is wrong with the case.
The viewpoint of curing specific conditions by specific processes is an
outmoded viewpoint, left over from old medical practices. One must run what
the PC can run and not fixate on curing. That is a sort of Q and A,

II. A case with a temporary relapse into heavy problems may not be able,
for the moment, to be run on problems, a repetitive-type process. Therefore,
you had better be able to undercut problems processes.

"If [a] case is dramatizing something, that something is not real to the
case." That is a guiding rule of processing. What you are guided by is not
"Are we handling what is obviously wrong with him?" but "Does the case respond
to the process that is being run on the case? 1.e. does the case get TA when
the ruds for the session are in?" You must, of course check that:

1. The session ruds are in.

2. Flows are in line.

3. The process is not already flat or unsuitable.

For instance, speaking of flows, most of the stuff we run, e.g. the Helatrobus
implants, are motivators. So if you had TA, and it ceased after you had run
several flows, the flows may be getting stuck.

We are interested in increasing the capabilities of the case. He should
at least be getting easier to audit, because that means that he is getting
more responsive to external orders, getting more capable of viewing his track
and pictures, getting into less trouble, getting better at locating BPC. The
case would be getting more done per session, too. Auditors tend not to notice
that a case is paining and winning, because they are too close to the case and
they don't observe the slow gradient. The way to spot it is to notice how the
case was a month ago. If the case is progressing well; if he is interested in
and happy doing what he is doing, don't change it, unless there is no TA for a
long time. Give TA motion time to develop, also.

It may take several sessions to establish the PC's case level.

Run engrams using the precise system and commands given. The precision
of the system tends to develop the PC's precision on the track. Don't word
the item too adventurously. Make it finite enough so that there is a hope of
reaching basic. It should be something he is worried about and can reach. If
you run a chain of "being held still", you are asking for lots of still
points, which may be hard to get to the root of.

What you validate, you produce, with the exception that getting the PC to
confront what he doesn't want to lets him take over the automaticity of
producing it, so it stops being produced.

Modern processes are built on and monitor the degree of withdrawal of the
person into himself, and those things that will lead the PC out from himself,
so he is no longer so restricted. Thus reach and withdraw is the most basic
action. You should have some idea about types of processes -- how and why
they work -- and what case level they are most effective on. And you should
get good at estimating where the case must lie, and upgrading the case from
that point. Always run the case a little steeper than it thinks it should be
run. The reaction of the case, in terms of protest or ARC break, has almost
no bearing on whether what you are running is the right process. You look
amidst the "Yap! Yap!" and see if the PC is running the auditing command.
Protest is a common denominator of the whole track and this universe. It is
how the thetan makes pictured. It is more fundamental than duplicating.