Toward a Methodology for Reality Hacking

"Superstition is the tribute paid by ignorance to knowledge of which it recognises the value but does not understand the significance."

Dion Fortune, Sane Occultism

If you have read my previous post on magic as hacking, you may find yourself persuaded by the similarities between the two activities, but asking yourself where exactly that leaves you as far as putting the information into action.  A set of techniques or processes gets us only so far as the use cases they were developed for:  continuing to slavishly rely on them in circumstances they were not intended to address seems superstitious at best (using Dion Fortune's definition above), and potentially ineffectual or counterproductive at worst.  Nor does it help to understand what the tactics are unless you can also have some insight into where (and why) these can and should be applied.  With that in mind, I've been spending my time lately considering what a methodology would look like if we are to approach magic together in this way.

Why methodology?  Because without it, you're sunk.  As a fledgling hacker, you don't have the real-world experience to know what the paths of least resistance are likely to be, to know what techniques are likely to work, or what threads are worth pulling on and which are more trouble than they're worth and likely to bear little in the way of fruit.  That wisdom is gained only with time and experience, and no matter how experienced one becomes there's always more to learn.  There's also more to forget, which is why methodologies help experienced professionals just as much as they do inexperienced novices.  It isn't sufficient to bang blindly on the door when the person behind the door is expecting a password and a secret handshake.  You need a method, or what you're left with is just madness.  Techniques and procedures give you tools to open the door, but in order to know how to open that door effectively you need a way of determining which tool to use in a given situation.  You need a methodology.

In order to apply that methodology, however, it all begins with intent.  This is step zero.  In the real world, criminal hackers don't just break into systems for the thrill of it:  they have motivations and operational goals.  And while a computer's attack surface may be finite, when you're talking about an infinite playing field the arena is equally unbounded.  Like a threat actor, you need to be clear about what your goals are when it comes to doing a particular magical working.  While the playing field may be infinite, our human time and energy and attention is not; so this clarity of intention is necessary to provide the focus you need to start scoping out the problem you're attempting to solve--even if that problem is messing around with some variable (e.g. astrological timing) simply for the sake of determining what you can get away with.

After you're clear on your goals and intentions, the first phase of the work is recon.  In order to leverage a particular attack path, hackers will generally look at what tools or techniques are out there in order to achieve the goals they have in mind.  The first part of this process is surveying the field to find preexisting tools and to better understand the problem at hand.  Research may or may not be your favorite thing, but proper research can greatly enhance your understanding and thereby the efficacy of your practice.  With this in mind, research your topic.  How have others historically approached this or similar problems?  Gather together your sources of data and compare them.  What commonalities stand out?  If different people across different periods of time, and especially across diverse cultures, have used similar methods this can generally be used as a heuristic to infer that the methods have proven effective.  That said, today's world is very different from that in previous centuries, and we cannot take this assumption for granted.

The second phase of the methodology is reverse engineering.  Assuming you have found relevant tools and techniques in your research, dive into them to better understand what makes them work.  Examine the methods and approaches, looking less at the particular forms (which are like the raw source code of a program) and instead paying attention to how they are intended to function in order to achieve the desired results.  This part of the process is what transforms the raw data of history into information, and finally into insight.  But don't mistake this insight for understanding:  insight can be had in the realm of theory, but understanding can only come from experience.

The third phase is execution.  Now that you possess some insight into the subject matter, and have a menu of techniques to choose from, take one of those procedures and try it.  Alternatively, adapt pieces of different procedures to assemble a set of functional "code blocks" which work together in a cohesive manner to serve the intention you have in mind.

Fourth comes debrief.  Observe the results of your working.  Did you get results?  Did you find anything about the outcome surprising?  By examining your outcomes, especially with respect to anything unexpected that comes up, you can begin to identify assumptions that may be worth testing and identify threads to pull on in the future.

Finally, experiment.  Adjust your methods and/or your hypotheses, and try again.  There's no substitute for experience, and practice makes perfect.  Consider your failures as valuable as your successes, because they provide you with opportunities for learning and growth.  Challenge your assumptions.  If your workings get results, see how far you can bend the procedures and methods without breaking the efficacy of the working itself.  Be persistent and keep trying, until you can determine with some degree of confidence that you've found something which works for you, or until you've determined that the approach you're trying is simply not viable enough to bear further experiment.

Just like an exploit program, you can't necessarily guarantee that everything will run smoothly the first time, even if you do everything right.  You may be looking for results, but you're also looking for data.  And should all else fail, you still have a data point.  Again, be persistent in trying to obtain results.

Finally, this should go without saying--but once you do find something that works, let it work.  That doesn't mean you stop experimenting, but turn your focus to a different problem.  Relegate the solved problems to the realm of play, where you can continue to make discoveries but are spending the majority of your attention on the areas that are going to gain you the most beneficial experience.

Reality Hacking Methodology

    0.  Clarify Goals & Intentions
    1.  Reconnaisance
    2.  Reverse Engineering
    3.  Execution
    4.  Debrief
    5.  Experimentation