      HUBBARD COMMUNICATIONS OFFICE

Saint Hill Manor, East Grinstead, Sussex



       HCO BULLETIN OF 23 MAY 1971R

                 Issue IV

         REVISED 4 DECEMBER 1974



Remimeo

Auditors

Supervisors

Students

Tech/Qual



        Basic Auditing Series 4R



     COMMUNICATION CYCLES WITHIN THE

             AUDITING CYCLE



     (Taken from the LRH tape, "Comm

     Cycles in Auditing," 25 July 63)





The difficulty that an auditor gets into is normally found in his 

own auditing cycle.



There are basically two communication cycles between the auditor 

and the pc that make up the auditing cycle.



They are cause, distance, effect with the auditor at cause and 

the pc at effect, and cause, distance, effect with the pc at 

cause and the auditor at effect.





         Cause -------- Distance -------> Effect

Auditor                                           Pc

         Effect <------ Distance -------- Cause





These are completely distinct one from the other. The only thing 

that connects them and makes an auditing cycle is the fact that 

the auditor, on his communication cycle, has calculatingly 

restimulated something in the pc which is then discharged by the 

pc's communication cycle.



What the auditor has said has caused a restimulation and then the 

pc needs to answer the question to get rid of the restimulation.



If the pc does not answer the question, he doesn't get rid of the 

restimulation. That is the game that is being played in an 

auditing cycle and that is the entirety of the game. (Some 

auditing breaks down because the auditor is unwilling to 

restimulate the pc.)



There is a little extra communication cycle on here. The auditor 

says "Thank you" and you have this as the acknowledgment cycle.





         C --------- Command ---------> E



Auditor  E <--------- Answer ---------- C  Pc



         C ------ Acknowledgment ------>E





Now, there are some little inner cycles that can throw you off 

and make you think that there are some other things to the 

auditing cycle. There is another little shadow cycle: It is the 

observation of "Has the pc received the auditing command?" This 

is such a tiny "cause" that nearly all auditors who are having 

any trouble finding out what's going on with the pc are missing 

this one. "Does he receive it?" Actually, there is another cause 

in here and you're missing that one when you're not perceiving 

the pc.



You can tell by looking at the pc that he didn't hear or 

understand what you'd said or that he was doing something 

peculiar with the command he was receiving. Whatever that message 

is in response, it rides on this line.





                    Did pc receive,

         e <------- understand and ------- c

                    answer command?



Auditor  C ----------- Command ----------> E  Pc



         E <----------- Answer ----------- C



         C -------- Acknowledgment ------> E





An auditor who isn't watching a pc at all never notices a pc who 

isn't receiving or understanding the auditing command. Then all 

of a sudden somewhere along the line there is an ARC break and 

then we do assessments and we patch up the session and all kinds 

of things go wrong.



Well, they actually needn't ever have gone wrong in the first 

place if this line had been in. What is the pc doing completely 

aside from answering? Well, what he is doing is this other little 

subcause, distance, effect line.



Another of these tiny lines is the cause, distance, effect line 

of "Is the pc ready to receive an auditing command?"



This is the pc causing and it rides up the line across distance, 

is received at the auditor and the auditor perceives that the pc 

is doing something else.



It is an important one and you find that auditors goof that one 

very often -- the pc's attention is still on a prior action.



Now, here's another one -- "Has the pc received the 

acknowledgment?" Sometimes you violate this one. You have been 

acknowledging but you've never seen that he didn't receive the 

acknowledgment. That perception has another little tiny one in 

it that actually comes on this line; it is, "Has the pc answered 

everything?"



The auditor is watching the pc, and the auditor sees that the pc 

has not said all that the pc is going to say. You sometimes get 

into trouble with pcs that way. Everything at "cause" hasn't 

moved on down the line to effect and you haven't perceived all of 

the "effect" and you go into the acknowledgment one before this 

line has completed itself.



That's chopping the pc's communication. You didn't let the 

communication cycle flow to its complete end. The acknowledgment 

takes place and of course it can't go through as it's an 

inflowing line and it jams right there on the pc's incomplete 

outflowing answer line.





         e <------- Is the pc ready ------- c

                    for the command?



                    Did pc receive,

         e <------- understand and -------- c

                  answer the command?



Auditor  C ---------- Command ------------> E   Pc



         E <---------- Answer ------------- C



         C -------- Acknowledgment -------> E



                   Did pc complete the

         e <------ answer and receive ----- c

                    acknowledgment?





So, if you want to break it all down, there are six communication 

cycles which make up one auditing cycle. Six, not more than six 

unless you start running into trouble. If you violate one of 

these six communication lines, you of course are going to get 

into trouble, which causes a mish-mash of one kind or another.



There is another communication cycle inside the auditing cycle 

and that is at the point of the pc. It's a little additional one 

and it's between the pc and himself. This is him talking to him. 

You're listening to the inside of his skull when you're examining 

it. It actually can be multiple as it depends upon the 

complications of the mind.



This happens to be the least important of all the actions except 

when it isn't being done. And of course it's the hardest to 

detect when it isn't being done. Pc says, "Yes." Now, what has 

the pc said "yes" to? And sometimes you are insufficiently 

curious. And that, in essence, is this internal perception of 

line. It includes this cause, distance, effect backflash here --

"Is the pc answering the command I gave him?"



So with this, there are seven communication cycles involved in an 

auditing cycle. It is a multiple cycle.



A communication cycle consists of just cause, distance, effect 

with intention, attention, duplication and understanding. How 

many of these are there in one auditing cycle? You'd have to 

answer that with how many principal ones there are because some 

auditing cycles contain a few more. If a pc indicates that he 

didn't get the command (cause, distance, effect), the auditor 

would give a repeat of it (cause, distance, effect) and that 

would add two more communication cycles to the auditing cycle, so 

you've got nine -- because there was a flub. So anything unusual 

that happens in a session adds to the number of communication 

cycles in the auditing cycle, but they are still all part of the 

auditing cycle.



Repetitive commands as an auditing cycle is doing the same cycle 

over and over again.



Now, there is a completely different cycle inside the same 

pattern. The pc is going to originate and it's got nothing to 

do with the auditing cycle. The only thing they have in common 

is that they both use communication cycles. But this is brand 

new. The pc says something that is not germane to what the 

auditor is saying or doing and you actually have to be alert for 

this happening at any time, and the way to prepare for it is just 

to realize that it can happen at any time and just go into the 

drill that handles it. Don't get it confused with the drill that 

you have as an auditing cycle. Consider it its own drill. You 

shift gears into this drill when the pc does something 

unexpected.



And, by the way, this handles such a thing as the pc originates 

by throwing down the cans. That's still an origin. It has nothing 

to do with the auditing cycle. Maybe the auditing cycle went to 

pieces and this origination cycle came in. Well, the auditing 

cycle can't complete because this origin cycle is now here. That 

doesn't mean that this origin has precedence or dominance but it 

can start and take place and have to be finished off before the 

auditing cycle can resume.



So this is an interruptive cycle and it is cause, distance, 

effect. The pc causes something. The auditor now has to 

originate, as the auditor has to understand what the pc is 

talking about -- and then acknowledge. And to the degree that it 

is hard to understand, you have the cause, distance, effect of 

the auditor trying to clarify this thing; and every time he asks 

a question, he's got a new communication cycle.



You can't put a machine action at that point because the thing 

has to be understood. And this must be done in such a way that 

the pc isn't merely repeating his same origination or the pc will 

go frantic. He'll go frantic because he can't get off that line

-- he's stuck in time and it really upsets him. So the auditor

has to be able to understand what the devil the pc is talking

about. And there's really no substitute for simply trying to

understand it.



There is a little line where the pc indicates he is going to say 

something. This is a line (cause, distance, effect) that comes 

before the origination takes place so you don't run into a jam 

and you don't give the auditing command. The effect at the 

auditor's point is to shut up and let him. There can be another 

little line (cause, distance, effect) where the auditor indicates 

he is listening. Then there is the origination, the auditor's 

acknowledgment of it and then there is the perception of the fact 

that the pc received the acknowledgment.



That's your origination cycle.



An auditor should draw all these communication cycles out on a 

scrap of paper. Just take a look at all these things; mock up a 

session and all of a sudden it will become very straight how 

these things are and you won't have a couple of them jammed up. 

What's mainly wrong with your auditing cycle is that you have 

confused a couple of communication cycles to such a degree that 

you don't differentiate that they exist. That's why you sometimes 

chop a pc who is trying to answer the question.



You know whether the pc has answered the question or not. How 

did you know? Even if it's telepathy, it's cause, distance, 

effect. It doesn't matter how that communication took place, you 

know whether he's answered the command by a communication cycle. 

I don't care how you sense this.



If you are nervy on the subject of handling the basic tool of 

auditing and if that's giving you trouble (and if you get into 

trouble by suddenly breaking it down and analyzing it) then it 

should be broken down and analyzed at a time when you're auditing 

something nice and simple.



I've given you a general pattern for an auditing cycle; maybe in 

working it over you can find a couple of extra communication 

cycles in the thing. But they are all there and if you made 

someone go through each one painstakingly, you would find out 

where his auditing cycle is jammed up. It isn't necessarily 

jammed up on his ability to say "Thank you." It may very well be 

jammed up in another quarter.





L. RON HUBBARD

Founder



LRH:nt.jh.gm



