6108C23 SHSpec-44  Basics of Auditing

     The constants of an auditing session are there: You must start the
session, get all the rudiments in -- at sensitivity 16; we don't use the third
of a dial drop rule anymore now -- flatten the process you start, and end the
session.  To do this, you need to have TR's, metering, etc.  For a PC to be in
comm with the auditor, it is necessary for the auditor to be in comm with the
PC.  An auditor who would make invalidative comments or not get a command
across is not there giving a session and isn't someone the PC can be in comm
with.  So add to the "in session" definition that the auditor has to be giving
a session, i.e. actually running a session.  The way to run a session is to
run a session.  The limitation on telling someone how to run a session
involves the amount of disagreement the auditor has with the forms and actions
he's using to run the session.  One's disagreement with handling rudiments
could be because of the relative ineffectiveness of the processes, but one
could also have far more fundamental disagreements, e.g. that the PC shouldn't
need auditing.  It works this way.  You, using the elements of auditing, could
make anybody an ARC breaky PC by running him with ruds out.  You could get a
lower scale PC and have a propitiative PC.  If you have difficulty or
disagreement with ruds, you could produce considerable randomity.

     The key rudiment is the PTP.  It's sneaky because it doesn't necessarily
fall at first.  The PC may have no reality on something being a PTP to him.
There is an interesting limiting factor on cases: As a result of auditing, the
PC goes into action in his life; he then accumulates problems and now is being
audited with PTP's.  One of the primary characteristics of case gain is the PC
going into action.  He may lose interest in auditing as a result.  You could
expect him to get more problems, not less.  This is the same as with getting
more withholds -- that is another indicator of case advance.  So don't be
lulled by the quiet PC.  As auditing progresses, he may well start having more
problems, which the auditor must not neglect.  The mitigating factor here is
that as the PC increases his ability, he blows these things faster.  If that
isn't happening, it must be because ruds are out.

     An auditor who expects the PC to be doing something besides being a PC is
in trouble.  You must grant the PC his PC beingness.  It's OK for him to have
his case in session.  All a PC is supposed to do is follow the session as
given by the auditor.  This is what the auditor expects of him, that's all.
If you grant the PC this beingness, you'll find auditing simplified because
you won't expect him to report on how things are going or whatever.  It's
necessary for you to find out what's going on.  Scientologists are
understandably prone to run a big ought-to-be.  This is fine anywhere but in
session.  The ought-to-be gets joined up with a "probably is", a supposition
which interferes with seeing where the PC really is at.  The PC could be in a
sweet old lady mockup, but in the valence of a space commander.  If the mockup
is factual and the case isn't advancing, the "factual" presentation must have
some unknowns in it which must be in wild disagreement.  Cases resolve on the
is-ness of the case, not on the ought-to-be's.  The is-ness of the case must
be totally unknown if the case isn't resolving.  And it's not what the PC is
telling you that is causing his no-progress; if you just keep auditing that,
you are in a Q and A, and you won't get a result.  You should question the PC
on the basis of, "What exactly are you complaining about?  What is the is-ness of it?" If something isn't resolving, you haven't gotten the isness of it.  The first isnesses you have are:

          1. A session.

          2. Ruds.

          3. What you are addressing on the case.

If you've got the is-ness of the session and the is-ness of the rudiments and
the person continues to complain, and you try to help them with a certain
"is-ness", it's just a "probably" and isn't the is-ness if it doesn't help
rapidly.

     The most trouble you'll have is with a PTP LD.  It can be tricky to get
the is-ness of it.  We now have a test to tell us if a process is working.
Anything except 2wc which is just to find out where the PC is at (not the 2wc
process, but just staying in 2wc with the PC) is a process, and you are
committed to flattening what you started, whether it was in model session or
not, whether it's a rudiment or anything else.  So you'd better have a good
grip on what you start before you start it.  Otherwise you'll get unfinished
cycles on the PC.  If you see this, you could run Prehav 13 on auditors, but
there's the liability of livening up levels, which means you're running a
terminal which is in wild disagreement with the PC's case and livening up the
whole Prehav scale.

                [Details on setting the PC up for Goals running]

     The second rudiment is the auditor.  Ninety percent of the charge will be
blown on Routine 1A, but to get the rest, you could take up the subject of the
auditor.  If these things are that important to a case, they're all worth
handling.  They're a preliminary to clearing as well as to the individual
session.