Recall Int Rundown - Procedure
(End of Endless Int Repair Rundown)

When to do an Int Handling 
When an auditor or C/S suspects Out-Int on a case the first thing to determine is whether or not Int is actually charged. You cannot audit a person on anything else besides Int, if Int is out. You also cannot run anything which is not charged (reading), as to do so hangs the pc with a wrong/uncharged item. An auditor getting a read on the Int section of the C/S 53 must be careful to verify that this is a valid read and not a false read or protest read. This is very important as you must not audit a pc on Int if it is not charged, and you must not audit a pc on anything else if Int is out.
You determine whether the pc has already had an Int Rundown (Engram Style), and whether it was correctly done or messed up. 

Applies only to mis-audited Int RD, Engram style: If it was mis-audited, were errors in Engram running repaired? Has the pc had an Int Rundown Correction List? Any such errors must be determined by folder study and FES of the Int Rundown and any repairs of Engrams Int Rundown.
If the pc has had an Int Rundown and it was going well, you would do an Int Rundown Correction List and handle all of the various actions necessary, providing this is within the normal time span of the Rundown. Don't try this months or years later. The Recall Int Rundown will not repair flagrant Dianetic errors. If the pc is having or was recently given an Int Rundown which has bogged or failed, then an Int Rundown Correction List including repair of any errors in running Engrams is to be done. If the pc still has Out-Int despite having had the Engrams Int Rundown and it has been repaired and all that is usual and ordinary has been done, then you would do the Recall Int Rundown.
You must determine whether the pc is Clear, or whether he has become so somewhere along the line. If the pc has had Clear rehabbed since the original Engrams Int RD, check the dates to determine whether the pc was run on the Int RD by R3R or R3RA after he went Clear. If so, this can be repaired by indicating to the pc that he was run on the Int RD on R3R or R3RA after Clear. If these Int Engram Chains are now reading, repair them by assessing an L3RH and indicating. (Do not get into running or continuing any R3R or R3RA on a Clear.) If the person is Clear and Int is still out for some peculiar reason best known to Man or beast, the only choice we have is the Recall Int Rundown.

The way to find out whether Int is out or not is normally done by Assessment of the C/S 53 buttons; it is on this prepared list that Out-Int is most often detected. You don't flatten the button, or try to handle the button that was found on the C/S 53. This is the one exception on the C/S 53 where you do not just F/N it and go on. It has to be checked out carefully in order to decide which way to go. Therefore you stop right there with a C/S 53 after carefully making sure that you actually have a valid read on Int, and not a false read or protest read. Some pc's, especially when Int has been run or repaired when it wasn't charged, can get so protesty on the subject that Int will now give a false read whenever it is mentioned due to protest. Having determined that you do have a valid read on Int, you would not go any further with the C/S 53, but end off the session.

This table applies mainly to pc's previously audited on Engrams Int RD:

INT RUNDOWN TABLE
The following table tells the auditor and C/S which way to go when handling Out-Int. Once filled out this table should be kept with the pc Folder Summary in front inside of the pc folder beneath the program. And the table should be updated.
 
Simply fill in with 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 ENGRAMS INT RUNDOWN? ____ ____
 
(If ‘no' or incomplete, it would have to be repaired and completed. NOTE: The Engrams Int RD would NOT be run on a Clear or above as they are not to be run on Engrams.)
 
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 Engrams Int RD or doing Recall 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 ENGRAM ERRORS ON THE ENGRAMS INT RD BEEN CORRECTED WITH AN L3RH? ____ ____
 
(If not, get these repaired, as continuing the RD or doing Recall Int Rundown won't solve R3R or R3RA errors.)
 
 
E. IS THE PC CLEAR OR ABOVE? ____ ____
 
Was the pc Clear when the Engrams Int RD was run on him by R3R or R3RA ? ____ ____
 
(If ‘yes' to either above, you must not run any Engrams but if Int is still out after repairing any errors the Recall Int Rundown can be done on a Clear.
 
If the pc was run on Engrams on the Int RD after Clear, the first action is to indicate the error of running Engrams after Clear, and then repair any reading Engram Int Chain with an L3RH, taking care to handle the reading lines by indication only, and not get into any running of Engrams. This action alone will often cure any Int trouble on a Clear, but if Int is still reading you can now handle it with the Recall Int Rundown.)
 
 

The Recall Int Rundown By Steps
 
Having determined that you are going to do the Recall Int Rundown from the table above, you do the following:

0A. Intensive Schedule. Make sure you have enough time to either do the whole action in one session or can do daily sessions over a number of days. This is due to you must not fly ruds, so you want out ruds from life to interfere the least. Also, once started the pc should have all the Out-int charge handled quickly.

0B. Do not fly ruds or do any Word Clearing, Touch Assists, Havingness or any other auditing over Out-Int. 

1. PC demonstrates Flows. Have the pc demonstrate the various flows. Remember that this must be done lightly. You just do what is absolutely necessary due to the person's Out-Int.  Have him demonstrate Flows 1, 2, 3, 0.
 
2. Assess the Int buttons. Take the largest read. Clear it with the pc to ensure it didn't read on an MU. This is done lightly!
 
3. Assess the 4 Flows. You then go ahead and handle this button with the Recall Int RD. You assess the flows. Take the flow that reads the best and use the Recall command for that flow and run it to an F/N VGI's.
 
4. Reassess the 4 flows. The flow you just ran will probably be F/Ning. Another flow will have a read. Run the best reading flow by the Recall Process until it F/Ns. You repeat assess/run the flows 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, V 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. To make sure, you check the button to see if it now reads. It will probably F/N.
 
5. Reassess Buttons. You now reassess the whole Int  buttons list. The whole list could F/N at this point. More likely it will not. Take your best read from this Assessment and handle it the same way - steps 3, 4, 5. You keep doing this until you get an F/Ning Assessment of the Int buttons.
 
6. You then wait a week. This is to ensure to get it all. As you only run to key-out this 'cool-off' period can bring more charge to the forefront.

7. Reassess Buttons. After a week you reassess the Int buttons again. If you get a read, check for false read and/or for protest to make sure it is a valid read that you have.  If it is valid, you treat that button the same as above by doing steps 3, 4, 5.
 
When you get an F/Ning Assessment of the Int buttons after the one week wait, the Recall Int Rundown is complete, and the pc can attest. In other words, you don't have to introduce another week's wait if there are reads to handle. Simply take the handling to F/N buttons and the pc should be done.

                The Int Buttons

 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 of handling: Int button found on Assessment: 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 F
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 "Recall a time when you put another in something". Reassess the same four flows, as shown above, using the same Int button.
(The exact commands for all the buttons and their 4 flows is included in print-out.)

Some Tips
The only time the auditor would check the button again, before assessing the flows he is working on, is when the pc has had a cog, F/N, VGIs, as auditor must suspect that the whole button has blown. If he overlooks this point it can cause overrun of Int.
 
There is another way of addressing this if the pc isn't getting any cognitions or only insignificant ones. When you get all flows on a button to an F/Ning Assessment you can end off the session. The next day you check the same button-flows to see if they are still F/Ning. It can happen, if you don't have a 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. Recall Processes are simply key-outs. Therefore you are getting something keying in and keying out and keying in and so on. This will finally be handled. 
When you do this day-by-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 rule, that it takes 3 to 10 days for something to key-out; you can't say wait for 3 to 10 days, so it is set at one week. During the Rundown there could have been some small auditor mistake, such as a little fault in the auditor's TRs, or a mishandled origination which could cause an ARC break needle or something like this. If you wait a week such trouble will key out before you assess the buttons list again. Or the pc may have been on a big win, a persistent F/N basically, on one button. This could cover up unhandled buttons and flows. Remember you are only handling Recalls (to key-out), and running a little more Recalls 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 this Assessment it must mean an Engram or something is pretty close to the surface still. You then handle it again and this time the small points that were 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. EP of the Recall Int RD and Out-int handling. There is no second wait for another week.
 
Should it happen during the one-week wait that the pc gets keyed-in again or originates or by reason of indicators or manifestations that Int is still out, you would not have to wait the whole week before giving the next session. It tells you he is not on a persistent F/N and you know there is more to handle.
 
On the reassessment of the buttons after the week's wait the auditor must again be sure that it is a valid read on Int and not a false or protest read before he goes 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. So it is necessary to be sure you have a valid read before you go ahead. And if the pc is keyed in or has Bad Indicators 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:

 1) Int wasn't out in the first place,
 2) The pc has been run on false reads,
 3) The pc was suffering from something else entirely other than Out-Int,
 4) The auditor's TRs are bad, or he broke the Auditors Code,
 5) The auditor's metering was bad, giving wrong Assessments,
 6) The auditor overran F/Ns, or reran a flow that just F/Ned,
 7) Pc had a Mis-U on the word ‘Recall' and was trying to run Engrams on Recall Int RD.
 8) The pc had a major cog on the subject of Int, blowing the whole thing and the auditor went on, overrunning the Int handling,
 9) Pc was audited on some other action while Int was out - such as rudiments, Touch Assists, Word Clearing or any other auditing, including 2-way comms about his case or auditing, eval or inval by his friends or others between sessions,
 10) Errors on the original Engrams Int RD weren't repaired before starting the Recall Int RD.

If a C/S can't tell, by looking in the folder, which of these it is he can have the pc interviewed to find out, or even get the above assessed to find out which it is. (There is also an Int Correction List that covers this).
 

Int Handling EP
Exteriorization is not the EP of the Int handling. 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. You may have to pick it up again later and complete the Int handling. The EP of any Int handling is:
 
 No more attention on 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 EP that can happen while running Int. The auditor should be ready for this and recognize it if it happens. It goes like this: during the RD suddenly some mass can discharge, the TA blows down big, you suddenly have a floating TA, and that's it. That is a valid and desirable EP.
 
If you go past that point you're in trouble. You don't  reassess or run anything 'to make sure', even if all the flows have not yet been run on one reading button. You simply take your hands off the Meter and gently end the session. 

The EP isn't exteriorization. Exteriorization could happen at the same time; however we could not care less because exteriorization is not the EP of the process.
 
But at any point you see the above on the Int handling: mass moving off, the TA coming crashing down and you can't keep the needle on the dial because the TA itself is floating -you end off the Rundown because that's for sure is an EP. What happened was that the stuck flow of "going in" suddenly blew.
 
Int causes high TA 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 ages, a stuck flow of obsessively going in. At any point in the auditing that stuck flow can suddenly loosen up. It runs in the opposite direction and the stuck flow of "going in" dissolves. When that happens it's the end of the process as that is all you want to accomplish with the Int handling.
 

 Repairs
 Over the years Int auditing has tended to be problematic. Int repair has been far too frequent and even repetitive on some pc's. 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. By doing the Recall version rather than the Engram version things have been simplified and errors less liable to happen.
 
But if an auditor is going to audit the Recall Int RD successfully he must be skilled at metering, he must have flubless TRs and understand the theory of Int. He must know what an F/N is and what the different EP's are and be able to recognize these when they occur.
 
Interiorization, like any other condition connected with Engrams, may have many incidents and Chains connected with it. Thus, the process of day-to-day living can restimulate those Chains and throw Int out so it needs to be taken up again.
 
If the C/S suspects some trouble the pc has, is connected with Out-Int the rule is:
 
The first action to take, if someone has trouble with Int, is to do a thorough folder error study (FES). Any prior Int actions and repairs should especially be studied. Anything found should be corrected before doing an Int Correction List. This especially applies, but not only, to any Engram running done.

Very often the answer to the puzzle will become obvious. With this out of the way you know that there is additional charge restimulated by life and you simply handle it with the Correction List and any additional run of Recall Int RD. Run Int it to its EP and that will be the end of the trail of endless Int repairs.
 

Additional Step
After an Int handling has been completed and attested the next action must be a C/S 53 handled to an F/Ning list. 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 must be handled as well.

Print-out of Recall Int RD, including all commands

(See also the "Read-it-drill-it-do-it" version of the Recall Int)