The 
Prometheus
Reports

Warning: These materials are only to be read and used by students ready for the Level. To qualify you have to have attested Clear and done Advanced Level 3, Pre-OT Three. The student should also be a trained Advanced Level Four Auditor.

Link to Date/Locate Procedure

 

Handling Clusters
with Date/Locate

 

In the previous chapter on basic Pre-OT III procedure (see Advanced Level III) we mentioned that Clusters can be formed by other incidents than Incident Two. The text stated:

"Severe incidents, usually with impact, can produce Clusters in their own right. Incident Two is of course an incident that produced Clusters but a variety of other Engrams can as well. If a Cluster does not respond to running Incident Two, suspect it was another type of engramic experience and handle with the D/L Cluster Handling process. Again, when a break-up has been accomplished with Date/Locate individual BTs from that Cluster that are still there should be handled with running Incident Two and One as needed."

This chapter gives more theory on Clusters and how to handle them in Solo if they don't respond to the basic procedure.

A Cluster that does not break up or respond properly should first of all be checked for "Wrong area?" and "Wong Volcano?" and "Other date than Incident Two?". If wrong area or volcano, correct it and proceed with Incident Two. It it isn't an Incident Two it is stuck in you handle with Date/Locate. The question "Was this Cluster formed by a mutual incident of another date?" can also be used to find this out.

If you have established that the Cluster was formed by another incident than Incident Two you go onto Cluster Handling with Date/Locate.

Before we go into the formal steps of the D/L Cluster Handling procedure, that is designed to take such a Cluster apart, the Pre-OT needs to know a little more about Clusters.

Cumulative Clusters
In auditing Clusters the Solo-auditor will find that many Clusters are made up of several Clusters formed at different times and then, on a later point in time, were crushed into one larger Cluster. This type of Cluster is called a Cumulative Cluster.

Definition: A Cluster is a group of Body Thetans crushed or held together by some mutual bad experience. We illustrated it this way:

A Cluster consists of 
individual BTs that think 
they are one. They are
held together by an Engram
they have in common.

 

Definition: A Cumulative Cluster is a group of two or more Clusters crushed or held together by some mutual bad experience.

A Cumulative Cluster can be illustrated this way:

Cumulative Cluster consisting
of three smaller Clusters.

 

Each little circle or square represents one BT. There are three Clusters (red, blue, brown) making up the Cumulative Cluster. 

The Cumulative Cluster was formed in 1887 in a horse and buggy accident with impact, let's say.

This incident will be the first one contacted. The type of incident is first established. It's usually done by just asking the the Cluster. The answer must read. Assess if you have to. To find by Assessment use the prepared list (given below). We establish it was an impact. The Cluster may tell us it was a horse and buggy accident by briefly flashing the engramic picture or by giving details by telepathic means.

Using the technique of Dating and Locating the incident is now narrowed down in time and place. Finding the correct date for the incident will result in a good Meter read and a blow.
Then finding the correct location for the incident will result in an additional Meter read and blow.

Part of the Cumulative Cluster is now blown off, the part that got formed in 1887 - illustrated with the red squares flying off.

What is left consists of 2 Clusters. They are held together by an earlier mutual (Cluster making) incident.

Again, we establish what type of incident it was. Ask Cluster  or use Assessment. Let's say we find it was a lightening.

We do the Date/Locate steps on the incident; it turns out it was 56 million years ago on 'The Blue Planet'. The second part (blue) of the Cumulative Cluster blows.

Only the Cluster consisting of brown BTs in the figure now remains.

Again, we establish the type of mutual incident. This time we find it was an Implant.

The Date/Locate determines the incident took place 98 trillion years ago on 'The Brown Planet'.
As a result of finding this the brown Cluster breaks up and blows occur.

Each action of dating and locating should result in an F/N, as well as a blow or blows. There are thus many F/Ns during the whole procedure. Make sure you get it all and carry on doing the steps through to the full EP.

Once the whole Chain of mutual incidents is run this way the Solo-auditor has to make sure that all individual BTs left behind are also taken care of. The Solo-auditor spots them one by one with his focused attention and by Meter read. The handling consists of running their Incident Two and Incident One, one BT at the time. As one of the incidents in the example took place well before Incident Two these BTs may or may not have a record of Incident Two. The most important incident to run, the one you will find in all cases, is Incident One. You take each BT to a blow F/N per basic procedure. You keep checking for BTs that remain from that Cluster until they are all handled.

When all single BTs from that Cluster are handled you can check for 'Copies?' and indicate with "spot the fact that someone copied it".

 

Date/Locate Cluster Handling by Steps
You should already have the Cluster's relative position to the body when you tried to run it on the normal procedure. Since it didn't run you switch to Date/Locate.

Clusters could have formed at any time, including Incident Two and Incident One. You will just have to take the Cluster's answer that reads. By the way, a heavy pressure or somatic comes from a Cluster, rather than a single BT.

0. Cluster-forming Incident. First you check for read:  "Was this Cluster formed by a mutual incident of another date?"
Note down any approximate date volunteered.

1. Get the type of incident. Ask Cluster first of all. If no clear answer, use the following Assessment list; the Solo-auditor has to focus his attention narrowly on the Cluster and ask,

Was the Cluster-forming incident an incident of:

"Accident, Impact, shooting, Injury, Illness, a drug,  shock,  Implant, heat, freezing, electrical, explosion, implosion, psychiatric incident, electrical, lightning, crash, burning, vacuum, radiation."

Note: this is not a rote list. You may take the first one that reads well or an origination that reads, but it has to read.

Indicate to Cluster what you find. You may sometimes get the Cluster's own wording and that is what you then take and indicate. Sometimes the incident will flash its content at the Solo-auditor.

2. Date/Locate the point when and where the Cluster was formed.

In the case of a Cumulative Cluster you date/locate the later mutual incident first, before proceeding to the earlier mutual incident(s). When the basic incident is date/located it will all blow apart.

Each incident on the Cluster-forming Chain is dated to blow, located to blow. Dating must be accurate. It may have to be taken down to the seconds and fractions of a second before you get the blow/FN. Locating must be precise. Both Date and Locate steps must be taken to a blow. 

Single BTs are then looked for and handled with Incident Two and One.

Note on Locate: The general procedure has a method where the PC points to the place of the accident and then gives the distance. Your PC is a BT/CL so you have to make sure the BT/CL gives the direction and distance, not you. Same goes for the Dating step.

3. Handle any Copies. It is essential to check for and handle copies. This is done by checking "Copies?" and "Spot the fact that someone else copied it" and it usually goes away and destimulates. If not, the Solo-auditor could find the BT or Cluster who is copying what was just run and blow it off by running basic procedure on it. But this should only be used in extreme cases as you are on shaky ground and want to complete what you started first of all.


Note that you can get a wrong date if other BTs are stirred up. A correct date or location for one BT or Cluster can be a wrong date or wrong location for another BT or Cluster because it doesn't apply to them. This will cause mass and pressure to build up. The mass and pressure will relieve on checking and indicating what you find with, "Did this serve as a wrong date for other incidents and masses?"  and "Did this serve as a wrong location on any other incidents and masses?" The two questions would be used, when needed, after completing respectively a Date and a Locate procedure. You simply indicate what you find. Do that indication lightly as you don't want to steer up new BTs and Clusters.

Implant Dates
False dates given in an Implant can be confused with the actual date of the Incident. It is necessary to be able to tell the difference between Implant dates and actual dates. Implant dates won't read or won't read much on the Meter. Actual dates, in comparison, read well and consistently. You can Meter check for "false date given in an Implant?", and the read will tell, and the Implant dates will no longer read.

Date/Locating can be a little dicey on Pre-OT III. This is due to the fact that you are addressing a case that consists of many, many entities - BTs and Clusters. That is why it is important to do it precisely and with the Pre-OTs attention focused narrowly on one particular Cluster or Cumulative Cluster and regularly check with 'wrong D/L for other BT/CLs?' as explained above. Run cleanly this procedure is however a very powerful tool to handle Accumulative Clusters with.

Link to Date/Locate Procedure

 

 

Prometheus International, 2004. Plus fair use quotes from Ron Hubbard's published notes and works.