Mind Control Programming Basics VI: Internal Programmers

Many dissociative systems which have been subjected to purposeful mind control techniques will have at least one, and possibly more, internal programmers in their system. They might be called something different, and they can appear in many different guises, but they will share a purpose.

Their purpose is to protect the programming in an individual system. This includes preventing other members of the system from analyzing or understanding the programming that was done to them ( or even realizing that there is any programming controlling them in the first place), and it also includes blocking the system and/or any therapist from examining or undoing the programming. Additionally, internal programmers might possess the power to activate or deactivate a programmed effect in the system or other similar tasks.

To a limited extent, internal programmers are also able to maintain the programming and to repair any damage – caused, for example, by an inadvertent glimpse caught of memories or events that should not be part of a particular self’s awareness, or by the efforts of a therapist to help the individual. If the damage extends beyond the capability of the internal programmers, their instructions will often include some means by which the system will be shut down and any existing internal communication broken off. This measure was originally intended to contain the damage until the individual returned to their external programmer for more a comprehensive repair.

The internal programmer of the system might be represented by a computer technician who maintains the central operating system, or a ranger walking the perimeter of his preserve, or a guard behind a particularly formidable gate, or a sentient shadow, or the image of the programmer who created it, or any one of a number of other metaphoric representations. They are likely to be well-hidden, and likely to want to stay that way – but as you begin to make more concerted efforts toward reaching and undoing the programming in your system, their presence will become more and more apparent, and eventually obvious.

Even when located, however, they will not make themselves easy to work with. They tend to be heavily programmed themselves, and they can and will make it very difficult for you to connect with them. They will know all your vulnerable spots and emotional hot buttons, all the places left raw and sensitive, and they will not hesitate to use those against you to drive you away from them and make you more vulnerable to them. (Remember that fear, shame, and guilt are the emotional base upon which programming is founded – if you are afraid of the internal programmers in your system, then you are giving strength to the very thing you are hoping to undo.)

Working with internal programmers can be further complicated because they often hold some very disturbing memories. For example, organized groups make it a practice with each and every system under their control to involve them to some extent in harming animals and/or harming other children. They do this for a number of reasons, the most commonly understood of which is to establish the guilt and shame of being a perpetrator in the minds of their victims. Internal programmers often also have the experience of harming others, but in their case it will be slanted more toward the creation of an identification with the programmers. It will be presented to them as a loyalty-increasing and bonding experience.

These types of memories are exceedingly difficult for most survivors to accept or process, and they can create a large (or, as the programmers hope, insurmountable) obstacle to working with these system members. In addition, the shame and guilt can mushroom to epic proportions upon realizing what some members of the system were forced to do, and further that they might very honestly profess to need, or even enjoy, these activities. These emotional reactions drive a wedge between one side of the system and the other, deepening the core conflict that already divides them and making it that much harder to reconcile the conflict or form connections.

As difficult as they make it and as repugnant as it may feel, however, it is important to reach this member (or these members) of your group. Your internal programmers can become strong and incredibly useful allies in healing, if you can get past the first impression and do the necessary work with them. They will know what kind of programming was done with your system, what sets the programs off, and how they can be deactivated if triggered, and their knowledge can help your system more safely deconstruct what is there.

They should not be ignored or passed over or left until a later time – when you make contact with them, it is a good idea to focus your time and attention on them until you are able to reach some accord with them, no matter how long that takes – not least because it is nearly impossible to effectively undo programming if the internal programmer is following behind you and repairing anything you manage to touch.

If you are truly free from the abusive group of your past, then these system members will be more vulnerable than they expect (and certainly more vulnerable than they will admit) simply through the natural decay of the programming. As I will address in more depth in a later post, programming does not last forever without external maintenance – the internal programmer can do some maintenance, but since the internal programmer will also be contained by programming, someone external also needs to be performing maintenance. When was the last time the external programmer contacted the internal programmer? How is the programming being maintained now? Is anyone doing this? When was the last time anyone did?

Do what needs to be done to remove any objects that are keeping your internal programmers focused on their programming, and then help them to begin the process of relearning. Rather than pushing them into defensiveness by directly challenging their perceived identity or their belief system, get your internal programmers thinking and help them to reach the necessary conclusions for themselves. It will be more meaningful to them overall if it’s a result of their own thought process.

You may never completely eradicate the effects of their one-time identification with the real-life programmers, but once they are able to identify themselves as part of your group instead of as part of the abusive group, then they can start to find new ways to redefine themselves. They can experiment with the options available in the wider world, and they can use the skills they were forced to learn or the characteristics they were forced to adopt in new ways that give them a different meaning.

It will feel horribly awkward at first, and they may resist or say it’s pointless and be inclined to give up, but they need to keep with it, and your entire group needs to be committed to seeing it through with them. New learning never feels comfortable or natural or like a good fit; it never has the broken-in ease of the things they have already been doing for years or for decades. New learning will never really feel natural until they have done it enough for it to become old and familiar and commonplace – but it will never reach that point, either, if you as a whole don’t stick with it through the awkward early days.

Internal programmers can become strong and valuable members of your system team. They can help you progress in ways that, from your current vantage point, might seem impossible. Please don’t neglect them or pass them over as being too difficult or complicated – they are not beyond help – they are part of you and part of your group, and they are worth the time and effort it takes to reach them.