6203C01 SHSpec-120  Model Session I

     Model session was instituted because auditors were varying patter to a
degree that a session was hardly recognizable and because as early as 1954,
scientologists were arguing about the proper way to do auditing.  There was a
need for a standard way to do it.  Also, it was found that if all sessions
were on the same pattern, subsequent sessions tended to run out earlier
sessions.  This has considerable value.  There is predictability, because of
the application, and auditing thereby becomes a better communication.

     The rudiments' value became extreme at the moment auditors began having
difficulties finding goals and terminals.  Rudiments in present form are less
than four to five months old.  Ruds began in 1955.  Having them in can make
the difference between auditing and no-auditing.  Model Session is tailored
against clearing; it is not tailored so much for prepchecking.  The ruds are
vital for assessment.  Since prepchecking takes up a lot of the things found
in the ruds, there could be a confusion between prepchecking and ruds.
Rudiments can be used by the PC to throw the session if you use any form cf
O/W in the rudiments, because the PC can now get into a whole new channel of
overts, while you had some previously-started chains you wanted to get
handled.

     Rudiments are vital to a session.  They get and hold a PC in session.
However, they can throw a PC out of session as well as into session if they
are used to prevent a PC from communicating with the auditor.  If the PC comes
in with all the answers to yesterday's prepcheck questions, he is already in
session.  The process of checking rudiments can create an ARC break if the PC
is already in session.  The E-meter won't tell you if the PC is in session, since the process of checking to see if the PC is ready can throw the PC out of session.  Also, the E-meter will not register when the PC is so ARC broken that the auditor has no command value over him.  The PC must be "way south -- very ARC broken -- for this to be the case.  So before you start Model Session, ask if it is all right for you to start the session.  If you get no answer or "No!", you can tell that you will get no reads on ruds.  Pay attention to the PC; get what is wrong before you expect to get much on the meter.  If the PC will talk to you pretty easily, the meter will read, if he won't, it won't.  If the auditor rejects the PC's data that he is ARC broken because the meter didn't read, the PC will get ARC broken with the meter.

     The reason you start the session is to be sure the PC knows he is on a
specialized section of track, that what is going to happen is not a social
relationship, but that there is a special auditor - PC relationship.  To
ensure that the special auditor-PC relationship is in existence, ask the PC if
the session has started for him.  If he says, "No," give Start of Session
again and ask again.  If he says, "No," again, assume that it has started
anyway and that the PC has an ARC break with life somewhere.  The beginning
rudiments are designed for the order of logical progress for a session.  If
you put PTP first, you would be running a session without goals, havingness,
clearing the auditor, etc.  [For Model Session patter of this time period, see
HCOB 21Dec61 "Model Session Script, Revised".] The order of actions in Model
Session tends to clear out the other things.  I.e. starting with goals tends
to put him in session by putting his attention on his case.  Having can clean
up ARC breaks, etc.

     You can put a PC in session by clever use of goals in ruds, if your
definition of goals is broad enough.  The PC has some goal, some hopeful
postulate for the future, which no one has recognized or acknowledged.  Even
if the PC's goal is to die, if you acknowledge it and grant him the beingness
of having it, he can then change it.  If the PC isn't giving any goals,
explore some future possibilities with him, one way or the other.  Find such
things as what the PC is sure is going to happen in the session and sort out
the goal involved with that.  Don't go overboard as far as number of goals is
concerned, but get the PC to make some.  This presupposes, of course, that the
PC doesn't come in already in session, telling you something he really wants
to tell you.

     Goals for life or livingness are there to differentiate from session
goals.  This is not very vital, and you never check up on it.  It is there to
expose PTP's of long duration.  If the same life or beingness goal keeps
recurring, you will know that there is a PTP to take up.  If they don't
contain problems, fine.  This shows the PC that you are interested in him.

     The next step, havingness, is easy to audit and beneficial for all
concerned.  The PC will usually run it, too, no matter what else he may or may
not run.  Finding the havingness process can take awhile, but it is easy
enough.  If you find one early in the PC's auditing, it will be changed before
too long, so watch it closely.  The more complex processes will work better
early on.  It is especially useful to find the havingness process early on if
the PC ARC breaks easily.  The havingness of the PC in the session is directly
proportional to the smoothness of the auditing.  It is ARC breaks that reduce
havingness, whether created by the auditor, the environment or whatever.  When
using havingness to heal an ARC break, be sure to flatten it.  Run it for a
half an hour or an hour.  Not doing it this way is why auditors don't have
reality on the fact that havingness clears up ARC breaks.  They don't see that
it is working.  Stopping it prematurely can give the PC quite a jolt.  Don't
cause ARC breaks with a havingness process, for God's sake!  Make it part of
the process to inquire how he is doing during the process, so it doesn't
become a signal that you are about to end the process.  An intelligent use of
havingness would be to use it when there is a shadow of dropped interest on
the part of the PC, less comm, etc.  But it should not be used to interrupt
the PC's in-sessionness.  The stable rule is not that you run havingness
whenever the PC dopes off.  You can get the same read during assessment
whether the PC is conscious or not, so there it is not necessary.  You use it
to help the PC get better into session.