To Frontload or not to Frontload

Are there, as both Joe and Lyn say, those times when frontloading is useful instead of harmful? If so, what are the deciding points as to when to use frontloading and when not to?

RULE 4: If you cannot frontload without polluting, then don't frontload.

RULE 5: If the viewer wants/needs frontloading, then give it. But make sure it is properly done.

There are times when a viewer is feeling insecure and actively wants frontloading. In this respect, frontloading is not used to guide the viewer, but to give the viewer a mental security blanket. In such a case, frontloading, if it doesn't pollute, actually helps the viewer by putting him/her at ease to work the session better. An excellent example of this is the case where the viewer wants frontloading, but the session is being conducted double-blind. The proper frontloading for this situation is:

Example 5.1: "The target is unknown. Describe the target."

RULE 6: If the viewer does not want frontloading, then don't give it.

It doesn't matter whether the monitor or project manager likes frontloading. If the viewer does not want it, then it should not be given. The viewer will know whether frontloading of any kind will be disruptive to his/her session or not. The viewer will also know whether the monitor can be trusted to give frontloading properly or not. If the viewer does not trust the monitor to give proper frontloading, then even if the frontloading is given in squeeky-clean purity, the viewer will still be suspicious of being polluted, and that worry will, by itself, pollute the session.

RULE 7: If the viewer wants frontloading, but is totally incapable of receiving it without causing pollution, give frontloading as though it were a double-blind session.

There are many viewers who want the frontloading either for security, or because they think they can handle it. But in fact, it throws tons of pollution into their session - sometimes without them evening knowing it. If that is the case, then follow Rule 5 and give them frontloading, but do it in such a way that 1) absolutely no target information is provided, and 2) absolutely no information is provided as to where they should put their efforts.

Example 7.1: "This is your first target of the day. Describe it."

Example 7.2: "This is a practice target. Describe it."

Example 7.3: "I won't tell you anything about this target. Describe it."

You would be amazed at the nondescript frontloading someone who only wants it as a security blanket will take and be happy with.

RULE 8: If you are doing a session for research, don't give frontloading.

It is totally possible to use the results of real-world operations for research and use the results of research for real-world operations. But to be honest about it, that is rarely done. In actual practice, research and operational applications exist in separate worlds, and probably never will be the best of bosom buddies.

In research, you need pristine controls, pristine environment, no unknown variables, and absolutely no pollution. Frontloading, even at its best and purest, is a type of pollution. Therefore, if you are working a remote viewing session for the lab guys, frontloading is neither recommended nor should it be permitted. The object of a research-oriented session is to test the viewer, a new protocol, or the field of remote viewing, itself.

If you are doing a session for real-world applications, though, the object of the session is usually to get in, get the necessary information, and get out with the greatest possible efficiency. In that respect, frontloading - vile pollution though it may be - is sometimes a very useful tool to get the job done more efficiently.

In fact, if you look around the remote viewing community, you will see that it is generally the researchers who are adamantly against frontloading of any kind, and the applications-oriented people who say that there are times when it is needed and useful. In both cases, you have people seeing only their own aspect of the field, and not being able to see that there is any other.

RULE 9: In all other cases, don't give frontloading unless you need to.

There is nothing magical about frontloading, in and of itself. It is a tool for real-world applications sessions, and nothing more. It should be used wisely and only when needed. It isn't the hammer that fixes everything, nor should it be used as the first tool out of the box. Just like the hammer, don't use it unless the job calls for it.

RULE 10: If you do give frontloading, make a written record of it.

In CRV, the viewer writes down, word-for-word, any frontloading which is given. Thereafter, there is no question as to the purity of the frontloading. It is there for all to see.

CONCLUSION

So, is frontloading good or bad? Well, I would say that it is simply one of two evils. The other evil is having a viewer exhaust him/herself because there was no clear direction on where to put his/her efforts. So, let's recap:

---If you are doing research, don't use frontloading.
---If you are doing applications, use it, but only when needed.
---If the viewer wants or needs frontloading, provide it.
---If the viewer doesn't want it, don't provide it, whether he/she needs it or not.
---If you don't know how to provide it without pollution, then don't provide it. In fact, if you can't, then you probably shouldn't be a participant in the session, anyway, as you will wind up polluting other parts of the session, as well. So let us change that to read:. . . .
---If you don't know how to provide frontloading without pollution, excuse yourself from the session.
---If the frontloading helps the session/viewer, it is good. If it hurts the session/viewer, it is bad.
---If you give frontloading at all, make a record of it.

Here's hoping this helps establish something of a common understanding about the definition and use of this often controversial subject.  



 PRINT THIS ARTICLE