Have you ever wondered why, when an Auditor gets a read on a question such as, “Onhas anything been suppressed?” that you are not actually allowed to answer that question, i.e. “What was suppressed”? Instead, the Auditor takes up the original question. That doesn’t really make sense, right? Yet, that is exactly what every Auditor in the Church currently does. It is also what all new Auditors are instructed to do by the Golden Age of Tech drills on “Getting a Read.” However, is there a good reason for this practice that is backed by LRH?
One of the references that is used to justify this method of using buttons is HCOB 11 AUG 78 I – RUDIMENTS DEFINITIONS AND PATTER. This reference gives the following datum:
If a rudiment doesn’t read and is not F/Ning, put in the Suppress button, using: “On the question ‘Do you have an ARC break?’ has anything been suppressed?
If it reads, take it and ask ARCU, CDEINR, earlier similar, etc.
However, this quote should be compared to the exact same procedure in HCOB 15 AUG 69 – FLYING RUDS:
If a rud doesn’t read, put in Suppress and recheck. If it gets any comment, natter or protest or bewilderment, put in False and clean it.
To fly all ruds you ask for an ARC Brk, if no read, put in Suppress. If it reads, take it, do ARCU CDEI Earlier ARCU CDEI Earlier until you get an F/N.
Obviously, the procedure in the previous reference was taken from this earlier one. However, note that in the later issue the sentence beginning “If a rudiment doesn’t read…” leaves out the part that says “and recheck.” The next sentence which says “If it reads, take it and ask ARCU CDEINR…”could then lead one to believe that the “it” is referring to the Suppress button. However, you can see from the earlier reference that “it” is actually referring to the ARC Break question. Interpreting “it” otherwise would give one the idea that:
IF A BUTTON READS, IT MEANS THE ITEM OR QUESTION ITSELF HAS READ AND SHOULD BE TAKEN UP (WITHOUT RECHECKING IT.)
However, to assume that a question or item has read just because a button is reading would introduce an “arbitrary” into the session, as described by LRH here:
When the needle on an E-Meter read in the response to an auditor’s question, all you know is that the needle on the E-Meter read. That’s all you know. Now in the next few seconds you will prove out, as to whether the read was to the question or to something else like a protest. To assume anything else in regard to meter reads is an arbitrary and will close up that pc with a bang. [HCOB 23 AUG 68 – ARBITRARIES]
The reason that this is important is that if an Auditor assumes that something is reading when in fact it may not be, then it could result in running an unreading item or question. This is not a minor auditing error. And if it is being done by every Auditor in the Church right now, then it is indeed a BIG problem that could be reducing every preclear’s auditing gains.
In order to clear this up, it will be necessary to first take a look at where the misunderstanding may have come from, and then make a comprehensive study of what the stable data are on the subject. This should then lead to a clear understanding of how to apply this Tech in such a way that actually makes sense and does not introduce any arbitraries.
Consider the following example given by LRH in the lecture “What Standard Tech Does” given on 25 Sept. 68:
“Well, do you have a present time problem? Well that’s clean.”
“Well, I was sitting here worrying about my wife.”
“Alright, on that question has anything been suppressed?”
“Oh yeah, well I’ve always had to suppress this problem, and so forth, it’s always been a terrific worry to me. I’ve been suppressing it for years.”
“Well good enough. Alright, anything been suppressed? That’s clean. Alright. Do you have a present time problem?”
There is no doubt here that an Auditor should not take up the question just because there is charge on Suppress. He instead cleans the button, and then rechecks the question. This aligns with HCOB 15 AUG 69 – FLYING RUDS, and would seem to clear up any confusion caused by a misinterpretation of the later reference.
So, why is it then that this method of using buttons is no longer being done? Could there have been a change in this technical procedure that is actually substantiated by anything written or spoken by LRH?
A key reference that has been used to do just that is HCOB 30 Nov. 78RB – CONFESSIONAL PROCEDURE (Revised 13 October 2000). It states the following regarding the use of buttons:
If Suppress or Invalidate or one of the other buttons reads, it means the read has transferred exactly from the Confessional question to the button. (Ref: HCOB 1 Aug 68, THE LAWS OF LISTING & NULLING.) Take up the Confessional question.
Similar to HCOB 11 AUG 78, II – RUDIMENTS, DEFINITIONS AND PATTER this reference seems to imply that the Auditor should simply take up the question when the button reads without rechecking it. However, it is significant to compare this quote with that which was originally written by LRH when this HCOB was released on 30 November 1978 (and which still appears in the current Tech Vols.):
If Suppress or Invalidate reads, it means the read has transferred exactly from the Confessional question to the button. (Ref: HCOB 1 Aug 68, THE LAWS OF LISTING & NULLING.) Put in the button (simply get what the pc has to say and acknowledge), then take up the question.
Notice that the procedure here includes “putting in the button”, or getting what the pc has to say about what was “suppressed” or “invalidated.” This is a major difference to consider. Even though it still seems to imply that the Auditor should take up the question without rechecking it for a read, this procedure doesn’t necessarily open the door to arbitrarily running an unreading question. Because, in this case the Auditor must first clean the button, and could find out at that point that the charge was on something other than the question (such as in the example given above.)
[NOTE: The current version of this HCOB and all previous revisions were not revised by LRH. They were “assisted by” LRH Technical Research and Compilations (RTRC). However, there are no indications as to what LRH instructions where utilized or why exactly any of the revisions were made.]
For some unknown reason “putting in the button” was edited out of the October 2000 version. However, this omitted data could lead one to an interpretation that would contradict all previous LRH data regarding the use of buttons.
Indeed, HCOB 1 Aug. 68 – THE LAWS OF LISTING AND NULLING, which is referred to in the above quote, says:
On an item that is suppressed or invalidated the read will transfer exactly from the item to the button and when the button is gotten in the item will again read.
Notice that the step of the button being “gotten in” is included here. It also says that the item will read again. In other words, it will read “once more” or “another time.” It does not say that the item has read, or that it should not be re-checked. It fact, the implication is that one would need to re-check the item.
Another reference that could be easily mis-interpreted is HCOB 27 May 70R – UNREADING QUESTIONS AND ITEMS:
The auditor, when a Question or Item doesn’t read, can and should always put in “Suppress” and “Invalidate”. “On this (Question) (Item), has anything been Suppressed?” “On this (Question) (Item), has anything been Invalidated?” If either one read, the question or item will also read.
Again, note that it specifically states that the button should be “put in.” It also says that the question or item will read. It does not say that it has read. In other words, LRH is saying that it will read in the future (should it be checked again.) And it certainly does not say that the question or item should be taken up at that point without re-checking it for a read.
Now, compare this line of reasoning with the following quote from a lecture given on 30 March 1972, entitled Expanded Dianetics:
Now to get something to read again you often have to say, “On this item has anything been suppressed? On this item has anything been invalidated?” Voom, voom. If you get a read on either suppressed or invalidated, the item is valid. You don’t have to go back and ask the item itself because invalidated transfers the read from the item to invalidated. You can be…. If you ask it again you would now get a read on what the item was. But the read transfers.
This is probably the most definitive reference that could be used to substantiate the practice of not rechecking questions when a button reads. LRH does say here that “you don’t have to go back and ask the item itself.” However, one would have to completely understand the context given here.
Notice that this is referring to a method of getting something to read again. In other words, the item has already read before. This is what is called a “transference of read” as explained by LRH in HCOB 7 Mar. 96 – HANDLING A READ, which was excerpted from a lecture given on 12 November 1975:
But the thing reads the way it read. That’s uniform. It’s also a transference of read. So let us say the pc read half-a-dial drop at a certain speed, half-a-dial drop, and then says, ‘No, I can’t think of an answer.’ If you say, ‘Well, did you invalidate it?’ and you get the same read back, the read is transferred over to invalidate. ‘Well, what did you invalidate?’ ‘Well, er, rah, rah, bluh, bluh, blah, blah…’ F/N.
In other words, the read has “transferred” from the original item (whose read was false because it was due to the right-hand button) to Invalidate, which when gotten in produces the F/N. This now makes complete sense if one keeps in mind all previous data, including the definition of “putting in a button.”
A key point to make is that buttons can be used in many different ways, and that not all uses are the same. For example:
1) Buttons can be put in when nulling a list of items (as opposed to checking a question or flow.) In this case, there could be multiple reads on a single button and not every one would be cleaned.
Example: [from HCOB 15 Mar. 64, II – METER EVERYTHING READING]
“Has Growl been Suppressed or Wronged?” Small read. “Has Woof been Suppressed or Wronged?” Small read. “Has Bark been Suppressed or Wronged?” Big reads. Clean up “Bark” by getting pc to get off the Suppress etc, and “Bark” now reads and “Woof” “Growl” and “Arf” do not. So “Bark” is the Item.
2) Buttons can be used to further explore a question that is not reading and not F/Ning, such as on a rudiment or prepared list item. In this case, the question would be taken up only after the button itself was cleaned. [See the previous example from the lecture “What Standard Tech Does”.]
3) Buttons can be used to handle a question or item that has already read, like the example given above in HCOB 7 Mar. 96 – HANDLING A READ. In this case, the Auditor would be utilizing the duplicate read to find out and handle the actual charge whose read will transfer to the button.
4) Buttons can be used to take charge off a subject, such as when prepckecking an item.
Example: [from: HCOB 7 Sep. 78R – MODERN REPETITIVE PREPCHECKING]
A question is formed around each of the buttons, and each question is run repetitively to F/N Cog VGIs. The button is prefaced with the subject (“On going to school,” “On auditing,” etc.) or with a time limiter (“Since last August,” “Since your last session,” etc.). Both subject and time limiter can be used. Thorough use of the Prepcheck buttons will blow the charge from that item.
Therefore, in the full context of all LRH research, the correct datum that would encompass all uses of buttons would be:
A BUTTON IS “PUT IN” BY GETTING WHAT THE PC HAS TO SAY ABOUT IT, AND THEN THE ITEM OR QUESTION IS RECHECKED. IF IT READS, THEN IT IS TAKEN UP.
This would make the most sense, and would not contradict any LRH references. Of course, the Auditor would still need to apply judgment in certain applications. However, using this datum would completely avoid arbitrarily running unreading questions and items. It would also allow the pc to voice whatever by-passed charge was attached to a reading button, and keep the pc in-session more effectively. This gives one a clear understanding of how to use buttons in such a way that would guarantee results and does not introduce any arbitraries.