6108C22 SHSpec-43 PTPs -- Unknownnesses

[Details on goals running]

Normally a PC is ARC breaky because he is being audited over undetected
PTP's, which he will not-is in order to get auditing. The auditor should
suspect it, for instance, when auditing an executive. It is problems alone
which give you this terrific timelessness. They show up as a sticky meter, an
unchanging graph, slow reaction time, not moving around much in life.
Problems stick and float forward in time, and the guy is stuck in a past
moment. Another useful definition of "problem" is "unknown". A problem is an
accumulation of not-knowingnesses and a consideration of the person as to the
value of the not-knownnesses. Remember that the thetan is stuck to his bank,
valences, etc., by mystery. Mystery is the glue of life. If you want
freedom, you must restore knowledge; if you want slavery, establish
ignorance. Create not-knows. So a common denominator of all problems is an
unknown. A problem cannot exist in the absence of unknowingness. As the
dianetic axiom puts it, "Randomity can be caused by a missing datum." [Axiom
105: An unknown datum can produce data of plus or minus randomity. Axiom 107:
Data of plus or minus randomity depends for its confusion on former plus or
minus randomity or absent data.] Man's difficulties were getting more and more
involved because of the missing data: a technology about Man, based on the
fundamental missing datum, "What is Man's nature?" or "What is Man trying to
do?" When the PC runs, "Describe the problem," he may well be giving lots of
aspects of the basic unknown problem. If you run unknownness on the subject
of problems, you cut through to this central problem rapidly. A thetan is a
mystery sandwich.

Two way comm is an inquiry of the PC as to what is going on and an
invitation for him to look at it. It should be limited to such questions as,
"How are you doing? What's worrying you? What is that all about?" Processes
aren't two way comm. No process is involved in two way comm except 2wc. If
you start a process, be sure you flatten it. This datum has never varied; it
applies to running unknownness of problems. It's OK to handle a PTP by asking
what unknown is connected with it. This runs PTP's fast. Use any version of
the odd-numbered postulates: not-know, forget, doubted, pretended. Don't use
2wc to handle problems. You don't have to be repetitive; get all versions of
not-know off of it.

[More details on running of PTP's]

Routine 1A consists of everything you can think of in terms of problems
processes. It gives a total ability to confront problems without being upset
by the unknownness of them. Man doesn't like having to confront the unknowns
of life. It's hard to do, because there is nothing there to confront. We're
back to processing loss when you process unknowns, since a loss is a
not-know. So someone with lots of problems experiences a sense of loss. What
is so maddening about a loss is that you don't know what is happening with
the thing lost. The PC will misassign causes of loss, too. Because some
terminal is gone and there is lots of unknownness on it, the guy will go to
the bottom of the Prehav scale and pretend some knowingness and pretend
cause. The two are closely associated. It makes someone who is a real inventor feel strange when he gets down to the Inventor's Club and the others "know all about it" and "invented it two years earlier". Someone in that state can't duplicate; if they were asked, "What did you invent?", they'd answer with some irrelevance, so that's a good rebuttal.

Pretended knowingness and pretended cause are blood brothers and
continually come up together. This is at the bottom of the not-know scale
because it is a substitute know. The way you handle it is not direct. You go
at it by way of problems. The guy has had so many problems, he has begun to
substitute false solutions. Those are the pretended knowingnesses you see on
the case. So you don't process the pretended knowingnesses. You process the
problems, and the PC will fly. You enter at the level of reality of what a
problem is, and the false solutions and pretended cause fade out. Flattening
Routine 1A means getting the guy comfortable confronting unknowns. Then he
won't be obsessively escaping from them and no longer experiencing a lot of
anxiety about them. [ Cf. Alan Watts' The Wisdom of Insecurity] Jealousy is
basically an inability to confront the unknown. The sickness one experiences
with it is not because of betrayal. It is just another aspect of the unknown
of faithful/unfaithful, or "something they know that I don't," etc.

Why does a case suddenly dive into the middle of the bank and refuse to
come out? The guy is unable to not ask why. There's an unknown in the
incident. The guy gets some glimmer of the unknown, and he dives into it. He
cannot confront an unknown and becomes hectic at the idea that an unknown
exists. The oddity is that all knowingnesses are invented knowingnesses.
With sn inability to confront the unknown, you eventually get an inability to
confront the known. Then this goes down to an inability to confront at all,
so any little tiny incident of the day becomes a problem he dwells on. So
don't judge by the apparent size of the problem whether he will be stuck on
it. If he can't confront the unknown at all, he will be totally glued into
all his unknowns all along the track.

You could run, "What unknown about an auditing session could you
confront / would you rather not confront?" You will solve anybody's difficulties
with auditing. You could run it on an old timer who doesn't much like
auditing anymore or on someone who is having trouble learning to audit, etc.
One old timer would get every PC's somatic -- because it's a mystery! He
instantly snaps terminals with these unknowns. This process would blow him
out. It is a very workable, specific process. It could be used for anyone
who has left off doing some formerly successful activity, or someone who is
having trouble learning something, e.g. a language. "What is unknown about a
German?" would handle problems with the German language.

The treatment of a condition is an attempt to alter a valence without
addressing the valence, and this just doesn't work. So some process addressed
directly at the condition, unless it aimed at solids, like engrams, won't do
it. Address the valence; find whose condition it is; handle the terminal
[Cf., again XDN "wants handled" rundown]. Long lists of goals won't be that
useful, but long lists of valences could be. Out of this, you could get a
process for PTP's of long duration: "W/W would have (condition)? What isn't
known about that person? What might you have done to him? What might you
have withheld from him?" You would strip off valences and get off problems and
O/W at the same time.

If you run lots of not-know, you've got to remedy havingness because the
whole bank is coming unglued.