Having determined that you are going to do the End of Endless Int Rundown from the table above, you proceed as follows:

1. The auditor has the pc demonstrate the various flows. Remember that this must not be arduous because it is actually almost auditing to do this and the person’s Int is out. If the pc is a Triple pc, have him demonstrate Flows 1, 2, 3. If the pc is a Quad pc, have him demonstrate Flows 1, 2, 3, 0.

(Do not engage in flying ruds, Word Clearing, Touch Assists, Havingness or any other auditing over out-Int.)

2. Assess the End of Endless Int Rundown buttons. Take the largest read.

3. You then proceed to run this button with the End of Endless Int Rundown. This is done by assessing the flows. Take the flow that reads the largest and using the Recall Process that applies to that flow, run it until an F/N is achieved.

4. Then reassess all flows. You’ll find the one you ran will be F/Ning. Another flow will be reading. Run the best reading flow by the Recall Process until it F/Ns. You repeat this procedure until all flows F/N.

If during the period you are running these flows on that button, the pc has a large cog, F/N, GIs, remember that you may have blown all flows. At that moment without interrupting the pc’s cognition you realize that you are finished with assessing the flows of this button. For caution’s sake, you check the button to see if it now reads. Of course it will F/N.

5. You now reassess the whole End of Endless Int Rundown button list. The whole list might F/N at this point. On the other hand it might not. If you get a read on this assessment, you treat it exactly the same as you did priorly, (steps 3, 4, 5). You keep this up until you get an F/Ning assessment of the Int buttons.

6. You then wait a week and reassess the Int buttons list again. If you get a read, check for false read, check for protest. Make sure it is a valid read that you have and if it is, you treat that button exactly the same as above and proceed (per steps 3, 4, 5).

When you get an F/Ning assessment of the Int buttons after the one week wait, the End of Endless Int Rundown is complete, and the pc is sent to declare.

• GO IN
• WENT IN
• PUT IN
• INTERIORIZED INTO SOMETHING
• WANT TO GO IN
• CAN’T GET IN
• KICKED OUT OF SPACES
• CAN’T GO IN
• BEING TRAPPED
• FORCED IN
• PULLED IN
• PUSHED IN

....

EXAMPLE:

Int button assessed: PUT IN

Assess the four flows with the wordings for that button but without using the word ”Recall”:

• F1:... you were put in something x
• F2:... you put another in something LF
• F3:... others put others in something x
• F0:... you put yourself in something sf

Flow 2 reads best, so run Flow 2 to F/N, using the entire Recall command (i.e.”Recall a time when you put another in something”). Reassess all four flows, as above, using the same Int button....

....

Examples of the running commands for”PUT IN” would be:

• If F1 reads: ”Recall a time when you were put in something.” (to F/N.)
• If F2 reads: ”Recall a time when you put another in something.” (to F/N.)
• If F3 reads: ”Recall a time when others put others in something.” (to F/N.)
• If F0 reads: ”Recall a time when you put yourself in something.” (to F/N.)

The only time you check the button again while assessing flows is when the pc has had a cog, F/N, GIs, at which time you must suspect that the whole button has blown. This by the way happens in Int Rundowns and is the commonest cause of overrun Int.

There is another way of addressing this if the pc isn’t getting cognitions to amount to anything. When you get all flows on a button F/Ning, you can end off the session and check the next day to see if the flows are still F/Ning. It some times happens where you have a not very responsive pc, that it takes several days of assessment of the flows which F/Ned yesterday to carry the F/N through a whole day. These flows often read again the next day. This is because you are running Recall Processes, and Recall Processes are simply key-outs. Therefore you are getting something keying in and keying out and keying in and keying out. This is eventually overcome. Where you are doing this day-to-day handling of the same button, it would be vital to check the button for read before you assessed the flows on it the next day.

The one-week wait is a compromise for the 3 to 10 day key-out period; you can’t say wait for 3 to 10 days, so it is set at one week. During the rundown there may have been a momentary stir-up of some kind, such as a tiny ripple on an auditor’s TRs rendition, or a badly mishandled origin that could cause an ARC break needle, or something like this could happen, so if you wait a week such trouble will key out, before you assess the buttons list again. Or you may have been riding a win, a persistent F/N on one button, when the whole subject of Int is not handled, and you will get environmental restimulation. Remember you are only handling Recalls, and a little more Recalls run will probably blow it for good. So you are waiting a week to see if the environment keys him in again. You reassess a week later and if the buttons are all clean, fine. But if something reads on the week later assessment that must mean an engram or something is pretty close to the surface still. You then handle it again and this time the little point that was missed will turn up and that will be the end of that. You handle the buttons to F/Ning assessment and then that is the end of that. The End of Endless Int Repair. (There is no second wait for another week.)

Now of course if during the one-week wait the pc gets keyed-in again or originates or by reason of BIs or manifestation that Int is still out, you would not robotically wait out the whole week before giving the next session, as you now know he is not on a persistent F/N, and you know there is more to handle.

And on the reassessment of the buttons after the week wait, the auditor must again be sure that it is a valid read on Int and not a false or protest read before he launches off into running anything again. False reads on the assessment, protest reads, or the pc suffering from something else entirely besides out-Int can cause a false read on assessment of the Int buttons. Hence the necessity to be sure you have a valid read before you proceed. And if the pc is caved in or BIs about it there is a little checklist that tells a C/S what to do about that too.

The things that could go wrong are rather simple and are few in number. These are:

a) Int wasn’t out in the first place,

b) The pc has been run on false reads,

c) The pc was suffering from something else entirely other than out-Int,

d) The auditor’s TRs are bad, or broke the Auditor’s Code,

e) The auditor’s metering was bad, giving wrong assessments,

f) The auditor overran F/Ns, or reran a flow that just F/Ned invalidating the F/N just gotten,

g) Pc had a Mis-U on the word ‘Recall’ and was trying to run through engrams on the Recall Process,

h) The pc had a major cog on the subject of Int, blowing the whole thing and the auditor went on, overrunning the Int Rundown or End of Endless Int Rundown,

i) Pc was audited on some other action other than Int while Int was out – such as rudiments, Touch Assists, Word Clearing or any other auditing or assist action, including illegal 2-way comms about his case or auditing, coffee shop or eval or inval by his ‘friends’ or others between sessions,

j) Errors on the original Int RD weren’t repaired before starting the End of Endless Int Rundown.

If a C/S can’t tell by folder inspection which of these it is he can have the pc interviewed by a D of P to find out, or even get the above assessed to find out which it is.

Exteriorization is not the EP of the Int Rundown. If it happens that the pc goes exterior during the RD, you end off gently as in any other auditing. But that is not the EP, and you may have to pick him up again later and complete the Int RD or handle it with the End of Endless Int Repair Rundown.

The EP of the Int Rundown is no more concern or trouble with exteriorization or interiorization.

This is generally accomplished by auditing the pc to an F/Ning Int button list.

But there is another phenomenon that can occur while running Int. It is vital that an auditor does not miss this should it happen.

It goes like this: You’re auditing along and suddenly some mass discharges, down comes the TA, you suddenly have a floating TA, and that’s it. The pc has hit the EP.

If you proceed past that point you’re in trouble. You don’t then reassess the Int button list and you don’t continue running Quad Flows, even if all the flows have not yet been run on one reading button.

You do nothing but take your paws off the meter and gently end the session. If you do otherwise you can mess up a case.

It isn’t exteriorization. Exteriorization could occur at the same time; however we could not care less because exteriorization is not the EP of the process.

But at ANY point at which the above phenomenon occurs on the Int RD – mass moves off, the TA comes crashing down and you can’t keep the needle on the dial because the TA itself is floating – you end off the rundown because you have the EP.

What has happened here is that you’ve blown the stuck flow of”going in.”

Int sends the TA up because the person has plowed deeper into more and more mass and come out of less and less mass. You have been auditing the pc on what has been, for eons, a stuck flow of obsessively going in. At any point in the auditing that stuck flow can suddenly give way. It heaves in the opposite direction, and the stuck flow of”going in” vanishes.

When that happens it’s the end of the process, as that is all you want to accomplish with the Int Rundown.

If you were then to check the Int button list (which you do not do at this point) you would find the Int buttons all F/Ning.

Over the years Int auditing has tended to be flubby. Int repair has been far too frequent and even repetitive on some pcs. Some auditors and C/Ses have decided Int RDs were”delicate” or”difficult” or very special. Well, Int is special and sometimes delicate, but it’s not difficult.

If an auditor is going to audit the Int Rundown successfully he must be skilled at metering, he must be flubless on R3RA and the commands of the process, and understand the theory of Int. He must know what an F/N is and what a Dianetic EP is and be able to recognize these when they occur.

Much of the Int repair needed stems from errors made by auditors (or C/Ses): running Int when it was not needed, running it with the idea it would exteriorize the pc, auditing the RD over misunderstoods, overrunning the RD. These are all violations of the Auditor’s Code, many of them then further complicated by Dianetic errors in running or repairing Int.

There is another factor regarding the original Int Rundown which must not be overlooked. Although it comes under the heading of”overrunning the Int Rundown,” it is sometimes neither seen nor understood. In doing the original Int Rundown it can occur that it completes before all flows are run.

Example: The auditor runs Flow 1 on engrams on the revised Int RD, then Flow 2, and suddenly gets a wide, persistent F/N and a dramatic resurge of the pc. The TA goes into lower range and the pc is bright and smiling. Then the auditor, if he’s an idiot, proceeds to robotically run Flow 3 and Flow 0. The TA goes back up, the pc’s chronic headache turns back on and the pc is set up for an endless repair of Int.

I have seen this happen several times. The Int Rundown finished itself and nobody noticed except the pc. This is probably the most flagrant cause of Int repair and is peculiar to this rundown.

The way to handle this is to rehab the point of completion as best you can and then run the recall version as given above and you will find that it usually comes out straight. The best way to handle, of course, is to do it right in the first place.

But if, added to any or all of the above, you get an Int Correction List misassessed so that what’s really wrong is missed and a falsely reading item taken up, you wind up with a mess.

There is no excuse for overrunning the rundown, for Auditor’s Code breaks, poor metering or flubby Dianetic auditing.

On the other hand, interiorization, like any other condition connected with engrams, may have many chains connected with it. Thus, the process of day-to-day living can restimulate those chains and throw Int out.

A C/S, faced with the possibility of any or all of the above being wrong could find himself staring into a maze. And he could err and order correction list after correction list, ad infinitum.

The rule is:

The correct action to take first, if someone is having trouble with Int, is to always get a thorough FES done on the original Int RD itself and any Int Repairs that have been done – before another Correction List is ordered.

Very often the answer to the puzzle then leaps out.

Get the errors corrected correctly. Any misassessed lists, misrun Dianetic chains, code breaks – get it all cleaned up by an auditor who can read a meter and run and repair Dianetics flublessly. Don’t let any auditor who isn’t flubless on these points near an Int pc.

With the errors truly and standardly handled and out of the way, if Int then continues to kick in, it’s not another Int RD or another Int Correction List, it’s the End Of Endless Int Repair Rundown you use.

Run it to its EP and that will be the end of the trail of endless Int repair.

If the C/S is in doubt about all this and gets into a mess trying to repair chains, he can cut directly onto this repair rundown as above with simply the Recall Processes, and he will get someplace.

After an Int RD or End Of Endless Int Rundown has been completed on a case and declared, the next action must be a C/S 53, assessed and handled to F/Ning list. this must be done as the next action and may not be left not done. (The reason for this is that there are other things that can be wrong with a case, all of which are covered on the C/S 53, and these too must be handled.)

There is no reason now for any pc (or C/S) to continue to be plagued with Int troubles.

We have here a rundown which is easily and simply done, which can be run on a Dianetic Clear, or a pre-OT who is not on OT III or anywhere between R6 Solo and OT III attest, on fragile pcs or weak or ill pcs, and is a rescue from overrepair.

Yes No

A. Is the read on Int a valid read? ____ ____

Is there any evidence of the pc having been run on Int due to a false or protest read? ____ ____

Any evidence of the read being caused by a Mis-U word? ____ ____

(If ‘yes’ on above get ‘False read?’ and ‘Protest?’ cleaned up or the Mis-U cleared and recheck the buttons on Section A of C/S 53 to find out if Int is charged.)

B. Has the pc had a full Int Rundown? ____ ____

(If ‘no’ or incomplete, it would have to be repaired and completed. NOTE: The Int RD would NOT be run on a Dianetic Clear, Clear or OT as they are not to be run on Dianetics in any form.)

C. Has the pc had an Int Rundown correction list? ____ ____

(If not, and there is any evidence of errors or lack of expected result, this should be done before continuing the Int RD or doing End of Endless Int Rundown. And if the pc has had several Int Rundown Correction Lists, realize that either the auditor can’t make a list read, or is only getting false reads.)

D. Have any R3R or R3RA Dianetic errors on the Int Rundown been corrected with an L3RF? ____ ____

(If not, get these repaired, as continuing the RD, or doing End of Endless Int Rundown won’t solve R3R or R3RA errors.)

E. Is the pc a Dianetic clear or above? ____ ____

Was the pc a Dianetic Clear when the Int RD was run on him by R3R or R3RA? ____ ____

(If ‘yes’ to either above, you must not run any Dianetics but if Int is still out after repairing any errors the End of Endless Int Rundown can be done on a Dianetic Clear. It can NOT be done between R6 Solo and OT III attest.

If the pc was run on Dianetics on the Int RD after Dn C/ear, the first action is to indicate the error of running Dianetics after Clear, and then repair any reading Dianetic Int chain with an L3RF, taking care to handle the reading lines by indication only, and not get into any running of Dianetics. This action alone will often cure any Int trouble on a Dn Clear, but if Int is still reading you can now handle it with the End of Endless Int Rundown.)