Thank you.

Well, I'm glad to see you're so rested tonight. I really am very happy to see that. But why are you so pale? I doubt it's the light.

All right. This is . . .

Audience: One March.

One Mar. AD 12, the month of bad auditing

All right. Saint Hill Special Briefing Course.

I'm going to talk to you tonight about Model Session. The genus of Model Session came about because auditors were varying patter to a point where a session was hardly distinguishable as a session from one to the next, and because, frankly, as early as 1954, I began to notice that Scientologists were quarreling between themselves as to what was the right way to go about a session.

I say this advisedly because actually, practically, fisticuffs and ARC breaks, and so forth, "You didn't run this session right," you see? And "Here you should say so-and-so."

We know now this was because he had missed a withhold. But it became evident very early that a Model Session was necessary. However, the session sort of evolved and over a long period of time, why, a great deal of patter and so forth was used very variable. And the genus of Model Session itself very precisely was a discovery that if all sessions were on the same pattern, then subsequent sessions tended to run out earlier sessions.

And the value of this is not to be gainsaid. You have an auditing session today and if you get the same wording in an auditing session tomorrow and the next day and the next day, just by duplication, you get a predictability on the part of the pc because duplication is taking place and auditing becomes a better communication thereby.

Now, I do not pretend that Model Session in its present form is either perfect English or perfect form or anything else, but it is a usable form. It is acceptable and it's been agreed upon.

Recently the rudiments entered in much more heavily than previously, and the value of rudiments became extreme at the same moment that the first auditor had difficulty finding goals and terminals and going down lists.

Editor's Note: the Model Session LRH described in this lecture was from HCOB 21 December 1961. This HCOB was later cancelled. The full data on the points of Model Session are given in the lecture. The current HCOBs on Model Session are in the Technical Bulletin Volumes.

And it was discovered that some people just couldn't have anything like a session unless the rudiments were in. As a result the need of rudiments became, well, just they were the difference between auditing and no auditing.

Of course, rudiments are quite early, but in its — 1955 — but in its present form these rudiments are less than four, five months old. And its present form has even been refined even a little bit further beyond your Model Session script — one end rudiment has been changed. But this is all in the line of evolution, and this end rudiments are your newest and they came about because assessments were not occurring in numerous sessions because pcs were doing peculiar things with the auditing session and that's where you get the end rudiments.

So Model Session is actually tailored against clearing. It is not so much tailored against Prepchecking or something like that. Beginning and end rudiments in Prepchecking might occasionally even get in your road, but they will never get in your road in actual assessment. They are vital in assessment. They are not quite so vital in Sec Checking, old Sec Checking and present time Prepchecking. They're not quite as vital as that.

Prepchecking, of course, takes up an awful lot of the things which are found in the rudiments. And as a result, there can become — come into being a confusion between Prepchecking and rudiments, and rudiments can actually throw the session.

The pc can use rudiments to throw the session on the auditor. All he has to do is have a rudiment out and his Prepchecking is parked for the day providing you use any form of O/W to resolve any of the rudiments. If you use any O/W of any kind whatsoever on any of the rudiments, regardless, you are instantly and at once in trouble on Prepchecking.

In other words, the preclear can throw the session over into a new channel of withholds while you are sitting there with 0A, 1, 1A, 1B, 1C, 1D, 1E, 1F, 0B, 1, 1A, 1B, 1C, and the pc comes in and all — your first chain had to do exclusively with candy and overts with candy or something of the sort. And your second chain that came off of this was overts against bathtubs. And your 0A, your 0B are very, very comfortably running on candy, and it went over to bathtubs in some peculiar fashion, and that connected up on glorious short circuits, and the result of this — the pc comes into session, and he has a present time problem on the subject of automobiles.

So you get a present time problem on the subject of automobiles, you use any withhold of any kind whatsoever to resolve this, and you are now over onto, whether you have put it down in that form or not, 0C- And you're not going to see, during that session, any of your 0A or any of your 0B. You won't see any of those 1 questions at all. you have been derailed. That has happened several times, and it is a frailty.

That is why I tell you that rudiments can get in your road in a Model Session during Prepchecking, but only if you use any form of withholds to get your rudiments in.

Now, you possibly could use withholds to get the rudiments in on 3D Criss Cross or a clearing routine because you're not doing withholds in the body of the session, and so there is nothing to be thrown. So it requires two different looks at rudiments.

But until you have gotten into trouble with this, you won't appreciate how agonizing the trouble can be, you see? You had a chain on candy, just to be ridiculous, and a chain on bathtubs, to be more ridiculous, and the pc came in with a chain that he was all ready to launch all on his own volition, and because he sits down and tells you he has a present time problem against — with automobiles, you now are tempted to say well, what automobile have you withheld from whom, you see? And whether you've stated it or not, you are right there on a third channel. You've got two live and you've got a third one going now. And you're not going to get off that third one in that session. Why aren't you? Because you already fouled up the session, see?

Your disobedience of the Auditor's Code — you're running a new process without flattening the old. So it's too many processes. You see?

So therefore, there's different ways that rudiments are used. Basically, rudiments are vital to a session. They get a pc in-session. They will hold him in-session. They will keep your needle from suddenly springing up on oddball othernesses. They will keep ARC breaks out of the way. They have a lot of value but at the same time, particularly in Prepchecking, they can also throw the pc out of session just as fast as they can throw the pc into session.

Pc comes in. He's all ready to get off withhold A, B. C, D. He's figured it all out. He thought it up in his sleep during the night and he's all ready to sit there and say, "Well, I've just realized that I killed a girl."

See, he's all set to say this, so you say, "Well, are you willing to talk to me about your difficulties?"

And he says, "Well, I'm all mmmmmmm-mmmmmmm. Well, yeah. I can talk to you about the difficulties. Uh . . ."

And you say, "Well, how's your havingness?"

And he says, "What, ah, well, it's all right, but you see, this girl, I mean ah, that. . ."

And you say, "Well, all right. Are you withholding anything?"

"Well, that's what I'm trying to tell you. I'm not withholding anything, you see, because I — I want to tell you about this girl."

"Well, do you have a present time problem?" He says, "God, yes! Trying to tell you what the hell this withhold is, you idiot!"

So the rudiments formed an ARC break.

In other words, the rudiments created an ARC break. See, rudiments can be used as a method of preventing the pc from communicating with the auditor. Do you see that? And an ARC break is only a prevention of communication by the pc from his viewpoint. Do you see then how rudiments can get in your road? Well, they definitely can get in your road, so therefore this is a matter of judgment.

The pc comes in, he's giving you all the answers to the Prepcheck questions you were asking him yesterday. Well, for heaven's sake, start the session and get the answers! Don't form and establish an ARC break. In-sessionness is something that has to be humanly detected. The E-Meter will do everything else for you but tell you whether or not the pc is in-session or not.

It will tell you the pc is in-session if you check the rudiments and find them all clear. But the process of checking the rudiments can establish an ARC break that will make all the rudiments unclear providing the pc is thoroughly in-session, interested in his own case, eager to talk to the auditor, quivering to get on with this situation.

Yes, your rudiments could all check out clear but you've established an ARC break. Why? You prevented the pc from talking to the auditor. Do you see this? The E-Meter will tell you everything then at a glance except one thing: whether or not the pc is in-session. Because you cannot use the E-Meter to find this out, for two reasons. The process of finding it out can throw the pc out of session wildly if the pc is eagerly in-session, and on the other side of it the E-Meter will not register that second point.

There's two points that aren't in E-Meter Essentials. And point one is the data on instant read. you only pick up instant reads for items and out-rudiments and that sort of thing. Only pay attention to instant reads, you know. The read right now. Don't bother with latent reads. You see me in demonstrations using latent reads to help the pc.

When his mind passes the charge, I can call it to attention — I'm not hounding him trying to get him to say something, but I call it to his attention as it goes by the charge on a latent read. "Hey! What was that?" See?

He's looking for something. That's only when the pc is sitting there thinking, "Wha — wha — wha — wha — what is it?" He's looking, you know, and he's looking, and he's got the garbage can turned over, and he's searching through the contents, you know, and so on. And the E-Meter goes flick, and you say, "What's that?"

"Well — I — oh — that. Oh, well, I just . . ."

"That," you see.

And he goes over and he looks at it and tells you what it is, and "Oh, well, that is important isn't it?" You see? The E-Meter can find out before he does.

You don't use that to hound him with, see? You haven't seen me hounding anybody with this. But you see me helping somebody out. That thought or that thing you just looked at is important is what I'm saying to him. Now, let's have another look at it. Otherwise, it's all instant read. And the other thing — and actually that isn't for detecting anything, you see. That's just helping the pc. The other thing is this ARC break. An ARC break can be so extreme that the E-Meter does not read at all.

The auditor has no command value of any kind over the preclear so therefore the E-Meter does not read an ARC break. So therefore, in-sessionness or the presence of an ARC break must be humanly detected. You've got to detect it. Or, let's say, Scientologically, detected by the auditor. Not humanly. That's probably a very bad phrase, and so on. I didn't mean to insult you, you're all — I didn't mean any of you were human.

All right. There's the limits of the E-Meter. The E-Meter does have that limit. The auditor must have some command value over the pc before the E-Meter will register anything. And the greater the command value over the pc, the better the E-Meter registers.

Now, this is not an extreme point. This is not a delicate point. This is yea and nay. This is black and white. How far out does a pc or a human being have to be that another human being cannot get him to register on an E-Meter? Oh, man, it's way out. It's in the cold dark of Uranus, you see? Because I can get a newspaper reporter who has come down to get a lousy story to register on an E-Meter, you understand?

You could probably get somebody who was all set to rob the house to register on an E-Meter. You understand? You must get the idea of what extreme condition it must be. What an extreme condition it must be to have no registry of any kind. And when you see the pc not registering on the E-Meter in any way, for God's sakes, assign it to a very extreme condition. It is very extreme. There's nothing light about this.

If the pc weren't so far south and so apathetic at that moment, if he had the energy to do so, he would probably cut your heart out with a very dull table knife with great glee. I mean it's way south, this condition where the E-Meter doesn't register. You see?

Some of you who have tiny reads on a list watching an E-Meter, some of you have very tiny reads of that character, very scratchy sort of tiny needle reads, needn't really think that its command value over the E-Meter that you're registering. Yes, the rudiments are not in very well before you get this sort of thing, but they're probably in as well as you can get them in. It is just the list itself is not much charged, and it is reading over the top of a very heavily stuck item, which is continuing to read, which is giving you this scratchy needle effect.

In other words, you can take somebody with a flow stuck wrong-end-to and get a scratchy read, see? But it'll still read for you. See? It's microscopic, but it's still reading for you. That isn't what I mean by command value, see?

Frankly, if your command value over the pc were sufficiently great, you theoretically could overcome this sort of thing, but actually the pc is terribly introverted, paying attention to some very hostile terminal of some kind or another, you see, and the pc's attention is so much on the terminal he hasn't got any chance to pay any attention to you.

But you can still make the thing read. That's a different thing than an ARC break. That's a terrific introversion. You'll never ever see it anywhere else — or a terrific dispersion. And it's consequent to having a clearing process run. I mean it's ordinary. Don't consider this extraordinary. This isn't anything very weird.

Before you run a flows assessment on a pc, you could almost expect, well, some indifferent type of line. you just decide the pc is goofy, so you say, "Who or what would oppose goofiness?"

Well, you get that type of line, you're liable to get that type of read, you see? Just by the fate you occasionally find something that's out, and you start running a line on a pc and you're very sorry you ever had anything to do with it because you watch down the line and that needle is doing nothing but scratch and tick. It's a dirty needle, you can't read through it, and so forth. And you say, "Oh, God, why did I ever start this?" Do a flows assessment and it clears up.

But this is the needle registering against the bank more than the auditor registering on the pc because you'll find out that the auditor does have an effect on the pc even though you have a little scratchy needle. The needle is electronically, internally inhibited is what this scratchy needle situation is, see?

He's got some kind of a mass of a terminal or something that's very much in the road of everything It's constantly knocking. It's doing all kinds of things. Tiny little reads. Well, that is not your ARC break type of read. Your ARC break type of read is just blank. It's just blank.

You get the same thing, as I've just been telling you, of the pc was so introverted you couldn't get his attention. But where he overtly is not going to pay any attention whatsoever to the auditor, none, the auditor can have no command value on him of any kind whatsoever. And you can actually say, "Do you have an ARC break?" You get no read. "How's your havingness?" You get no read. "You withholding anything?" You get no read. "Do you have a present time problem?" You get no read. And all those rudiments are live as a cat. It has to be humanly detected. The pc won't talk to you, either.

Pc is sitting there with his eyes on the floor, the cans are over on that side, they've been thrown down sometime since. It's just "No!"

And finally the pc musters up enough energy out of this well of despond that he has been placed in to answer the question, "Well, do you want me to audit you or don't you?"

And he manages to say, "No, God damn it, no. Please go away. If I had enough energy to walk, I would, but I haven't."

You know that's the way that goes. Well, you aren't going to get an E-Meter registry at that time. The time to detect what's wrong with the pc is before the pc gets into this extreme condition.

So just to make a — keep auditors from making a mistake at this point of the beginning rudiments, you give them that reservation. Your E-Meter may not have command value because somebody may be so stupid as to never perceive this condition on the part of the pc. So you make it humanly. So if you're going to find out anything about running the session, you look up and look at the pc. This is a very, very, very good thing.

Now, the first test of this comes before Model Session opens and that is, "Is it all right with you if I begin this session now?"

And if the pc doesn't answer you, or if the pc says "No!" profanity, exclamation point, the probability is that the E-Meter will not read on the pc for the remaining rudiments. You see how extreme this is, see? So that is your test way up at the top of start of session. That is your basic test.

You ask him, "Has the session started for you?" and, you know, and you've got another test. Makes another test. That's to find out whether or not the pc's going to read on the meter. That's why you're making these tests, as well as put him into session.

And you say, "Well, has the session started for you? Has this session started for you?"

And the pc says, "Huh. What session?"

I don't think — I don't think you should go on monkeying with the E-Meter. Don't go on monkeying with the E-Meter. Pay attention to the pc. Ask the pc what's wrong Do anything you're going to do to patch this pc up and just skip the meter at that point because the probability is that the pc is not reading on it. So don't even take a chance that the pc is or is not reading on it. At that point use your skill to get the pc to talking to you.

Now, if you can get the pc to talking to you, you go on down the line here and you will find that the thing will read. So if the pc will talk to you easily, the E-Meter will read. And if the pc won't talk to you, the E-Meter won't read. you got that?

You should recognize this because the pc can be given an ARC break with the E-Meter as well as the auditor. And don't give him an ARC break with the E-Meter and the door and the floor and everything else. At least try to minimize the effect on this.

And how do you give him an ARC break with the E-Meter? Well, I'll give you a method of doing so. This is not recommended. You say, "Do you have an ARC break?"

And the pc says, "Yes."

And you say, "Well, it hasn't registered on the meter."

At that moment, the pc will question the meter and the probability is will never thereafter believe in a meter. And that is the exact test, by the way, that is the exact test that established this point — the E-Meter doesn't register on an ARC broken pc. See. I discovered this by inspection of the factors and actually saw it work.

The auditor says, "Doesn't read on the meter," and that was the end of the meter for the pc. Now, you had to patch up the meter and the auditor, but how could you patch up the meter because you didn't have the auditor patched up, and oh, God help us. What a rat race. Do you see that? Do you follow that? You're all looking at me like you might not think it's true.

All right. Now, let's take up Model Session here just step by step. I've given you some preliminary music on the operational function of this sort of thing we know now one of the reasons "Is it all right with you if I begin this session now?" is so that you could humanly detect an ARC break on the part of the pc.

And the reason you start the session is so that the pc knows that he's on a specialized section of track; that what goes from here on is not social relationship; that he is now a pc and you are now the auditor; that you are taking command of the situation as of this moment. And is a service of warning of the starting of a specialized section of track known as the session. And that the relationship between auditor and pc will obtain from here on out. It is the beginning of a contract.

And now, you want to know if the pc has agreed to this. Don't ask him after you've started session if he has now agreed to start the session. Because you've already taken the command of the situation. As close as you can come to finding out if the pc is in agreement with this specialized-section-of track situation is to ask the pc, "Has this session started for you?"

All right. Pc says, "Yes." You go on. If the pc says "No," you once more say "Start of session," and you say, "Now, has this session started for you?" And if he says, "No," you assume that it has started anyway and you say, "Well, we'll cover it in the rudiments."

In other words, you just bull on through, well recognizing at this particular time the pc is in possibly an ARC break. Not possibly. A pc is. Excuse me. It's an ARC break with life or existence or something of the sort.

Now, we get down to the beginning rudiments. Now, the beginning rudiments are designed for the order of logical progress of a session. But what do you have to take up before you can take up something You see?

Now, if you put a present time problem first, in the rudiments, you would be running a session without goals and very often having to run the present time problem, you would be running a session without having cleared the auditor or gotten any goals or remedied any havingness or anything else.

So the most complicated action you can take up is a present time problem which is the last one. Now, the one just before that, "Are you withholding anything?" is a little less complicated than a present time problem but it is most likely to clear the present time problem which may follow it. And above that, "Are you willing to talk to me about your difficulties?" and if the pc realizes that he or she is, you are much less likely to have a withhold, and then again much less likely to have a present time problem. And then going higher than this, "Look around here and tell me if it's all right to audit in this room." If the pc's havingness is down and you remedy the pc's havingness, he's much less likely to have difficulty with the auditor, withhold anything or have a present time problem. Do you see this?

And then the least innocuous thing that you can possibly run that is calculated, if you are clever — and very few auditors ever use this as a point of cleverness, so I'm bringing up something that is rather new to you right now — if you cleverly enough run goals, you can put the pc sweepingly into session. You'll get him interested in his own case and willing to talk to the auditor. Because the most likely piece of conversation that a pc can be embarked upon is what he means to do or what he hopes will happen in life. And that is the most likely piece of conversation.

Even if it is "I hope I will die soon," that's still a goal, you see? And a goal like that is better than a pc sitting there saying "hm" to any goal, is better than no goal. That's the easiest one to audit. That's very easy to audit unless you're going to get a goals list and find the goal on it and that sort of thing And that — people find that rather difficult.

But the easiest thing to audit then is, "What goals would you like to set for this session?" Now, that's, of course, your first rudiment then. "What goals would you like to set for this session? Are there any goals you would like to set for life or livingness?" both under the heading of goals in two sections followed by environment: "Look around here and tell me if it is all right to audit in this room." Followed by Auditor: "Are you willing to talk to me about your difficulties?" Followed by withholds: "Are you withholding anything?" Followed by present time problem: "Do you have a present time problem?"

Those are the beginning rudiments in proper order. But let's see how they are used.

All right. I said an auditor could be clever. You can always get a pc to talk about goals if your definition of goals is broad enough. And you can put a pc into session overtly with the subject of goals unless you have a specialized category of goals.

Now, I know of a case, not a pc, he's not been audited. I thought at one time I would ask somebody to audit this pc but the pc subsequently was electric shocked and given wet packs and, man, they got this pc from merely being apathetic to just being a frantic, sodden piece of catatonia, you see. So that's that. Let the psychiatrists have their meat. And we'll catch him next life. And if we catch the psychiatrist who did it, we'll know about that, too. We'll make sure that he has a withhold before we audit him.

Now, you can be very clever here. This pc, potential, at the time he was going to be audited, and even now, has got the same goal. And nobody will recognize it as a goal and it's stuck the pc with the goal because nobody okays this as a goal.

A goal is simply a hopeful postulate of future. That is all a goal is. The pc hopefully, not very positively, he just — it's whether by luck or it's going to happen because a roulette wheel turns up, or he wins a football pool or any other confounded thing, this is something that he hopes might happen in the future. And that's all a goal is. And when you take that broad definition and look at goals, you will stop shutting the pc up on the subject of goals because they don't fit your idea of your goals.

You're there to make him well. The pc says — this same goal this person has been giving now for a year and a half is "I want to die." It's a perfectly valid goal. Recognize it as such.

And nobody has cheerily said to him, "Well, I'll see what I can do to help you out with that goal." And you know, a pc will come right on up and out of that goal and give you another goal rather rapidly.

If you ever see a suicide hanging out the window about to plunge into the street and so forth, hand him an anvil so he'll fall faster or something. He isn't likely to go into the street — unless he thinks you're being sarcastic.

So, here is a wild tool if you care to use it. And honest, when I see a consistent or blank — well, you know, a consistently reiterated statement as the only goal the pc has, or a blank no statement of any kind whatsoever, all I recognize about it is, is well, there's probably a little bit of an ARC break here. Yes, probably so if it cared to be detected.

But certainly the auditor is operating with a paucity of inventiveness. The auditor — it's just merely a stamp of the nonoperating auditor. That's all. He hasn't any pat process by which to get the pc to give him goals and he just doesn't bother, and so forth.

But I wouldn't leave a pc in that situation. The pc that wouldn't give me a goal I think would park me right there in the rudiments. That rudiment, too. Not any further rudiment than that. I would explore possibilities of future. I'd explore them one way or the other.

I'd find out such things as, well, what would the pc was sure was going to happen in the session. And you find out that you're probably sitting on a certainty that he's going to feel worse.

You say, "Well, good. Is that a goal of yours?"

"No. Quite the contrary."

"Well, what goal do you have?"

"Well, to feel better."

"Thank you." And you write it down.

The well-oiled auditor can always get a chain of goals if he cares to apply a little bit of cleverness to the situation.

Now, when you go upwards to twenty goals for a session, you're overdoing it. There's moderation in all things as the fellow said when he put down the empty five-gallon jug.

And if you get too many goals, of course, what are you doing? You're doing some kind of a Routine 3 activity. Well, that has nothing to do with rudiments. Two, three, four, something like this. This is within the realm of reason or even seven or eight. That's fine. That's fine. But for God's sakes, get the pc to make some even though you sort of trick him into making some.

I don't know what aplomb one or would not use. It'd all depend on the situation. If the pc said goal for the session, "I want you to drop dead," you know? Well, I don't know whether one would really with aplomb write down "To have me drop dead." But if I really wanted to get the pc squared away and under control, I think I would write it down.

Now, flying in the pc's face and saying, "Oh, no. you really don't want that, do you?" and so forth, is a refusal of goals and you'll throw him out of session. After all, he gave you a goal. Whether it's feasible or polite or socially acceptable or agrees with your basic goals at the moment, it is nevertheless a goal, see? So the least you'd do is acknowledge it. But you actually can use goals in far more ways than you have ever dreamed of. But don't audit the pc in the middle of a "no goals" because there's an incipient ARC break there.

I don't have to read the meter that the auditor was running on the pc in an auditor report. I look up there and I find no goals of any kind whatsoever. Then one of two things was true. Either the pc came into session at a high roar, totally in-session, spilling every withhold on the track, laying his case in the auditor's lap, and the auditor had barely got time to say, "Start of session" into one of the haaa, as the pc gasped for more breath, you see? The session evidently started a half an hour before or some time like that, you see? Well, there'd be no goals in the thing.

Obviously the pc's goal is being expressed in the fact that he wants to lay his case in your lap, and so on. He's living his goal for the session, so you'd have that. But that would be accompanied over here by terrific successes in the session, see, if he really came into session, and so on. you could see all this stuff he got off and everything is squared around, and the auditor guided him over finally and got him onto the groove where he wanted him and kept him going on down that groove, a very expert method of handling it.

Or the pc is at the other opposite end of the spectrum, totally out of session and won't talk to the auditor, and at that time I'd like to see some work put in on the situation. See? And that's one of the best ways to get a pc into session is take it right at that rudiment. Of course, that rudiment's a sneaker.

Now, "Are there any goals you'd like to set for life or livingness?" sort of jumps up out of nowhere. But pC9, about their second or third session, begin to learn these rudiments, and this isn't for the first session that this has any bearing.

You want session goals. And this sort of disciplines the pc as he gets interested in it into having session goals. Possibly even it should be first, but it's a little bit too far out. It is one of these questionable rudiments. Is it vital? Is it necessary? But it's very useful and the pc seemed to like it, and you said it, but you never use it. you never check up on it. you never check up on it. This is as far as from the pc's viewpoint.

Now, I will tell you why it is there. It is to trap and locate present time problems of long duration. And the pc will set them right down like a little soldier if you spend a little time on this.

And you want to know the pc's present time problems of long duration, just ask him, "Now, are there any goals you'd like to set for life or livingness?"

And he says, "Well, to get over present time problem number one, and to recover from present time problem number two, and to recover from present time problem number three."

And this is a very interesting cross-auditing report check — is you can find out whether or not the pc was operating consistently on a present time problem by finding out if this same present time problem continues to recur session after session. And after one of these things has recurred about three sessions, you begin to wonder when somebody is going to take up this present time problem.

But they will. They'll state it beautifully. So it is a bit of a covert way to get some data on your pc. And he will, he'll give you his present time problems under that line.

Of course, it looks like it isn't important. There isn't anything much to this, and so forth. If these do not contain problems — and in the majority of the time they don't contain problems; it's just interesting and shows the pc that you're interested in him and so there is no motion wasted here particularly.

All right. Now, that step handled well can get the pc in-session, see? Your next step almost any pc can run some version of and benefit from it, even if temporarily, and any auditor can audit. One of the easiest things to audit, apparently, there is, is Havingness, environment. And apparently, apparently, auditors will run Havingness, can run Havingness, on anybody. I've had auditors who would ordinarily have a terrible stage fright auditing me, be able to sit there and just run Havingness just beautifully, you know, and not have any difficulties running Havingness or anything like this.

Then they have to run something else that takes a little bit of invested address to the pc and they just fall all over themselves, see, but they could run Havingness. So I just take it from a subjective reality on this fact and watching auditors audit, and that sort of thing, that they will and can run Havingness. This is an easy one. In other words, we've got our easiest process first.

Now, the other side of the thing, the pc for some reason or other will usually run Havingness. No matter what else the pc can run or refuses to run, the pc will run Havingness, so you of course got your easiest process first, right?

So the auditor's comfortable and the pc will run it and you could go on from there, and you get a little bit of a win.

Now, of course, there are Havingness and Havingness and Havingness Processes, and trying to find one of these Havingness Processes is a bit of a gymnastic activity, but everybody seems to be able to do that very easily.

You just take the 36 Havingness Processes and test them with can squeezes. Keep the pc squeezing the cans every now and then even though he has to lay them down and pick them up. Why, make him pick them up and squeeze the cans again. You saw me doing that the other day in a demonstration.

And keep testing your Havingness from time to time. Make sure it keeps working.

In other words, find your Havingness by the can squeeze test. If you've got the pc's Havingness, if that's his Havingness Process, you get more of a needle throw. And if that isn't his Havingness Process, you get less of a needle throw on the same sensitivity setting You just get that sensitivity good and low there and test.

And while you're testing and it's starting to tighten up the needle or it doesn't loosen it, get out of there, get out of there, man, get out of there quick. Give him five commands, didn't loosen the needle, you say, "Well, that's it, son."

I don't care what form of auditing you're going to use at that point, that's exit fast and get on the next process. Because a Havingness Process is something you should find with a minimum of mistakes.

Therefore, Havingness test processes are published in the 36 Havingness Processes in a frequency table. In other words, the most likely Havingness Process that will fit the case appears earliest on the list. And that's only done out of class averages. This is an empirical finding. Whether or not it's theoretically true or not or whether or not some of our more recent Havingness Processes which aren't even on that list would go higher on the scale or not, I don't know.

But you get that Havingness Process, and you get that early in auditing and you're probably going to get a change of process before you go too far with this case. So you're going to have to find the Havingness Process much more frequently if you find it early in auditing the pc. And it's a question of whether or not more time is saved by not finding it early and finding it later or something like this.

The safe thing to do in all such cases, is of course, find it early, even though it's going to change and then watch it like a hawk. See, early on in the case is the most complex and idiotic Havingness Processes will be found earliest on.

So you've got a pc that's liable to ARC break — well at any time when he is workable at all or even vaguely workable, find the Havingness Process, and you will have it here. But on a pc who apparently is auditing very well, it isn't so important. Got it? Early on it's not so important. That's a fact. It just isn't.

It's not whether I say it isn't or is, but you could audit 60 percent of the people you audit without ever running a breath of Havingness. You realize that? Providing you are a very skilled auditor.

Now, I would not be giving an HPA class the same advice. Because the havingness of the pc during the session is directly proportional to the smoothness of the auditor and inversely proportional to the roughness of the auditor. Direct, these are direct ratios. The rougher the auditor, the more the pc's havingness has to be remedied. The rougher the auditing, the more boobs the auditor makes, the more the pc's havingness has to be remedied.

If you have to remedy the havingness of your pc every three minutes during auditing, I would take a look at my auditing. It's probably rough. This is interesting to you, isn't it, and so on.

You can do a can squeeze test, find that the can squeeze has lessened — in other words the pc's havingness has dropped. This is negative testing The pc at the beginning of the session was dropping a third of a dial very nicely on the can squeeze test without your touching the sensitivity knob whatsoever. Ten minutes later, just out of nowhere in the middle of doing something else, ask him to squeeze the cans. If it has dropped a half or is only dropping now a sixth of a dial, you could ask him at once, "Have I done something wrong?" And if you keep the pc pushed to this and get him to look at the earlier part of the session, he will find something you have done wrong.

And the second he has found what this is and you've cleared it up — you see, it wasn't even evident in the session — you ask him to do a can squeeze test again, and you'll get a third-of-a-dial drop. Do you see that?

It is ARC breaks which reduce havingness. Now, whether or not they're introduced by the auditor or the environment or restimulated or — doesn't matter where they came from, your havingness drops in direct proportion to the number of fancied or actual ARC breaks the pc has during a session.

So the smoother the session, well, the less havingness you have to remedy. The smoother the auditor, the less havingness you have to remedy. The rougher the auditing, the more havingness you have to run. So if it's geewhiz, God almighty, rough auditing, we start in and say, "Let's see, now, I think it says here — let me see. Just a minute. Let me find this piece of paper here. I think I've got a Model Session. Let's see. Start of, ah, the light is very bad. Move aside a little bit so I can see that. Ah, let's see, it says ah, 'Start of session.' Yes, 'Start of session,' it says right there. Ah, is it all right, is it all right with you if I begin this session — now?"

If you were doing it this way, I think the can squeeze test just before the session started and just after the session, you see, would reduce in magnitude. You got the idea?

Auditor confidence may be very great, but if auditor blunder exceeds pc's expectancy of auditor confidence, you get a drop of havingness. You could probably draw up a lot of formulas about this.

But here is your criteria of Havingness is that it is the easiest process to run, it is the most likely to be run by the pc in any ARC break situation. He may not run "What weren't you able to tell me?" and "What haven't I done?" He may not be able to run that process. He may not be able to run any ARC break process. He may not be able to run anything except Havingness. And he will, however, point at the floor and the door and the ceiling and so forth, and he'll go on.

And the commonest mistake that an auditor makes is not flattening it. When this is being used for an ARC break, for God's sakes, heavens on earth, realize that if you're using Havingness to heal an ARC break, and if it is the only thing that the pc will run, you probably had better run it for the next half-hour or hour. The various uses of Havingness dictate this as a fact.

The commonest auditor error in utilizing Havingness particularly on an ARC broke or breaky pc is not to run enough of it. And therefore, that being the commonest auditor error, auditors do not get a high level of reality on Havingness healing ARC breaks. They quit. They knock off. They say, "Well, now we've got the pc running Havingness, let's get on to something now and clear up the ARC break."

Well, look, the ARC break is clearing up through the duplication and mechanics of the auditing session. They're clearing up the ARC break and they would be guilty of a breach of the Auditor's Code — they would cease to run a process which is working and which is producing change before that process was flat. That's something to think about, isn't it?

And listen, you can give a pc one God-awful jolt this way. The only liability of running Havingness is not running it. You've got this pc and he was down, just down on the lower rungs of nowhere. You dropped the bottom out from underneath him, inadvertently or accidentally. He had a hell of an ARC break and you couldn't get him back into session; this is a desperate situation. And you finally do manage to get him to point at the room object — his current Havingness Process, you know?

So he points at the ceiling, and he points at the floor. He's all ARC broken, but he can do this. And he will do it, oddly enough. And he can point at the window and the chair and the auditor and the ceiling and the floor and the chair and the window, and he can point at the floor, and then you say, well, he's operating fine now. So you say, "Well, all right. If it's all right with you, I'll give you two more commands and end this process."

Now, man, you've handed him an ARC break on the process which is handling ARC breaks because he had just gotten to the point where he could have the end of his nose.

He was starting to come out of the ARC break. And now you've given him a new one on a Havingness Process.

So let me tell you something just as a general rule in the use of Havingness Processes. For God's sakes, don't cause an ARC break with a Havingness Process! I don't care what you cause ARC breaks with, do it with anything else. Do it with lists or do it with running present time problems or evaluate for the pc on how he ought to — not to beat his wife. Suddenly look up in the middle of his running a PT problem and say, "Well, I should — don't blame your wife at all for treating you that way," you know.

I'm not kidding you. This has happened, you know. I mean this is not a — not even necessarily a rare occurrence. All of a sudden some kid auditor without very much experience behind him will all of a sudden get totally overwhelmed by all of this horrible social conduct on the part of his pc, you see? And he all of a sudden goes into the stern, puritanical lines of life in which he's been educated. And he steps out of the role of auditor into one of his minister valences or something like that, and says, "We must bring order here for the church," or something of the sort and makes some kind of an offball comment.

But even that isn't anywhere near as bad as ARC breaking a pc during a Havingness run. That is cruel. Because when you end the Havingness Process, before you even announce that you are going to run two more commands, before anything else going to do, and so that this announcement then doesn't serve as a pattern that when you ask this, you are then going to end the process, you got that as a training pattern?

You know, you can ask, "How are you doing" and if the pc says they're doing all right or says mm-hmm or something, the fact that you have said "How are you doing?" is now a trained pattern. Because you're going to say, "How are you doing?" then you're going to run another command. Then you're going to say "I'm going to give you two more commands and end this process," and so you've signaled the end of the process by an inquiry to the pc.

Well, look, unfortunately, whether you want to know it or not, you had better salt down all of your Havingness Process with questions about how the pc is doing every now and then rather than to have this thing become established as a signal. You get the trick?

So don't let that inquiry as to how he's doing become an established signal that you're going to end the process or you're going to hang the pc — this is particularly applicable to Havingness Process — you're going to hang the pc with a new phrase that operates just like a Model Session phrase to him.

You're going to say "How are you doing?" and he's liable to blast right straight in your face, "Well, damn you, I was doing all right, but now you're going to end the process." See?

You said "How are you doing" and he knows that this is an end of process, see? He knows that's the signal because you've always — you said, "How are you?" he says, "Fine," you say, "Good," and sometimes this crudely, "I'll give you two more commands and end this process," see? Inevitable pattern.

Well, you just start that pattern, and you ARC break the pc. you can't then find out how the pc is doing unless you have frequently inquired how the pc is doing and gone on running the process.

So part of every Havingness Process that is being run for any purpose whatsoever should be to inquire after what the pc is doing and how he is doing it. How is he doing? "What are you doing" "Did you do the command?" Anything you want to ask the pc. And that should be part and parcel of Havingness Process.

Run a few commands and you say, "Well, how is it going?"

You know he says, "All right."

And you say, "Well, did you have the wall," and so forth.

And "Yeah. Oh, yeah. Yeah. I'm doing pretty good on the thing."

You see, that's making the pc talk to you a little more and actually wipes out some of the possible little, tiny unseen ARC breaks. You're not even using it to handle an ARC break, you see? But just by making the pc talk to you a little bit during Havingness Process, of course, uses this as a benefit to get the pc more into session. Those are the skillful ways of Havingness.

So it's the easiest thing to run, and run with an understanding of what you're doing is the most successful of the ARC break processes.

Havingness Process well administered by the auditor and actually run by the pc, if it's the right Havingness Process, will get your pc over some mighty tough ARC breaks and rough spots of the trail that you otherwise would find it very difficult to get over, and I personally believe that some of them you wouldn't get over at all. You'd just have to let it drop that day and skip it.

A very intelligent use of Havingness, an extremely intelligent use of Havingness would be, when the pc starts to look kind of walleyed and so on and he's talking to you a lot less and doesn't seem to be interested in what you're doing, and so forth, and any shadow of any of these things, just run Havingness.

And then inquire often enough and find that the pc brightens up and then follow it through because Havingness is marvelous stuff.

The proper use of Havingness is to patch up what you're doing. That's a very intelligent use of Havingness. But not to use Havingness to interrupt the pc's in-sessionness. That's also an intelligent use of Havingness.

The pc's going down the line, the pc said, "Wog, wog, wog, a — a frog, a weasel, a dog, I think, ah, let's see, what else would inhibit the inflow on another? Let's see — a dog, a weasel, a ooooo oooooh. You know, God, I get groggy on this, a dog, ah, whewf! Ah, ah, let's see now. Ah, any, any small farm animal. A wog Any small farm animal. Let's see now, anything else would inhibit uuuuuu. A sign. A sign. That would, and so forth."

Well, there's some point there where you would find it necessary to run Havingness, but there's some point there where if you ran Havingness, you would throw him out of session.

The rule for Havingness is not "every time the pc dopes off, run Havingness." That is not a good, stable rule for Havingness. You understand? It's when the pc is incapable of going smoothly on with the session that you'll run Havingness.

Now, as far as nulling lists are concerned, you get the same read on the list whether the pc is conscious or unconscious, so who cares? Did you know that?

Male voice: Uh-huh.

Doesn't matter what you do. I mean you get the same read. The pc can be out like a light, and you'll get the same read on the meter.

All right. There's more to this. There's more to this, and I want to go on with this and give you — cover this Model Session with you rather thoroughly, so we're going to have another lecture. But right now we're going to take a break. Okay?

Audience: Yes.