Demons

What It Is

A demon, in this framework, is a self-sustaining computational pattern running on neural substrate — a persistent, autonomous-feeling behavior that competes with conscious intent like an external force. You did not choose the craving, the spiral, or the avoidance. Something is executing, and it does not feel like you.

The Core Insight: Some Patterns Feel Like External Forces

Certain behavioral patterns don't feel like you choosing — they feel like competing forces executing despite your intent. Addiction feels like something taking over; the craving "possesses" you. Anxiety feels autonomous: intrusive thoughts arrive uninvited and spiral without permission. Procrastination feels like resistance pushing back from outside. Intrusive thoughts recur without ever being summoned. In every case the phenomenology is the same — a process is running, and the conscious you is not the one running it.

The traditional framing is moralistic: "I have a problem." Self-blame, character flaw, no debugging path. The demon framing is mechanistic: "a program is executing." A program can be analyzed, interrupted, terminated, contained. The metaphor earns its keep four ways. It depersonalizes — the pattern is separate from your identity, so "a demon competing for control" replaces "I'm broken." It makes the pattern debuggable: you terminate a process and seal its invocation paths instead of trying to fix yourself. It respects the pattern's autonomy — demons have momentum, self-sustain, and fight back, and an enemy you respect is one you plan against. And it suggests strategies with handles on them: seal, banish, exorcise.

From Will's note: persistent patterns "feel like another competing force." The demon metaphor takes that phenomenology seriously and translates it into the language of debuggable systems.

Demons as Executing Programs

The metaphor maps onto computational patterns point for point, which is why the old vocabulary of demonology reads today like a systems manual:

Ancient demon lore, read this way, describes patterns that self-execute and resist termination. Nothing supernatural is required — just persistent programs running on neural substrate.

Observable "Demon-Like" Patterns

Addiction as Demon

Addiction is the metaphor's home case — the vocabulary of possession has always attached to it. The pattern self-triggers in an automatic loop: cue, craving, seeking, consumption, repeat. It feels autonomous ("it takes over," "that wasn't me"), and it keeps executing despite every conscious intent to stop.

while context_contains_trigger:
    invoke_craving()
    if willpower < activation_cost:
        execute_seeking_behavior()
        consume()
        # Pattern persists, self-reinforcing
    # Demon wins resource allocation

The framing shift matters here more than anywhere: "a demon competing for control" rather than "I'm weak, I'm an addict." And each classical anti-demon move has a mechanistic reading. Sealing the triggers — no alcohol in the house — removes the invocation path, so the demon cannot be summoned at all. Creating an incompatible state makes execution structurally impossible: you cannot consume from inside a gym session. Overwriting the pattern for thirty days installs a new demon that displaces the old one. And starvation works on its own schedule — with the triggers gone and no invocations landing, the craving weakens over time.

Anxiety as Runaway Demon

Anxiety is a demon of a different shape: a runaway positive feedback loop. A thought triggers anxiety, the anxiety amplifies related thoughts, and the amplified thoughts produce more anxiety. Activation is involuntary — the thoughts arrive unwanted — and the pattern competes directly with the state you were trying to hold: you ask for calm and get the spiral.

initial_thought triggers anxiety
anxiety amplifies related_thoughts
amplified_thoughts increase anxiety
# Runaway positive feedback loop
# Anxiety demon executing, spiraling

Saying "the anxiety demon is active" rather than "I am anxious" separates the pattern from the self, and it points at the loop's structure, which is where the interventions live. Discretizing work into short chunks with forced breaks leaves the spiral no time to build. Externalizing the thoughts onto paper starves the feedback — a thought that is out of your head stops amplifying. An incompatible program like exercise captures the resources the spiral needs. And when the demon cannot be terminated, it can be contained: five minutes of sanctioned worry time, then sealed.

Procrastination as Competing Demon

Procrastination is the demon as resource competitor. The moment work should begin, a competing program activates instead, and it runs the same predictable repertoire every time — distraction, excuse-making, task-switching. What it wins is routing: attention and time flow to the avoidance program, and the work program never loads.

if task.activation_cost > available_willpower:
    procrastination_demon.invoke()  # Competing program
    # Wins resource allocation (attention, time)
    execute_avoidance_behaviors()
    # Work program never loads
else:
    work_program.execute()

"A competing demon is winning" is a debuggable statement; "I'm lazy" is not. The pseudo-code exposes the levers. Lower the task's activation cost by discretizing — "write one sentence," not "write the chapter," gives the demon no threshold to trigger against. Remove its execution environment: a library with no phone seals the avoidance demon outright. Block the escape routes — delete the games, block the sites — and the demon has nothing to execute. Or install a work pattern whose activation cost is lower than the cost of resisting it.

Intrusive Thoughts as Background Demons

Intrusive thoughts are background processes: not consciously chosen, recurring, and competing with the thoughts you actually want to think. You want to think about X and keep getting Y. The demon keeps invoking whether or not the foreground process consents.

# Background process keeps spawning
while system_running:
    if random_trigger or idle_state:
        invoke_intrusive_thought()
        # User consciously dismisses
        # But pattern persists unless terminated

Here the metaphor's main gift is recognizing involuntariness — "a demon invoking a pattern," not "I'm thinking bad thoughts." The debugging follows the same arc as the other demons. Identify what invokes the background process; it is usually idle time, particular contexts, or stress. Deny it the idle state it exploits by keeping a foreground process running. Overwrite it with a replacement thought-pattern over thirty days. Or accept that it exists and contain it: a few minutes of allotted thinking time, then sealed.

"Sealing" as Computational Containment

The word "seal" (封印) in Chinese and Japanese covers both the mundane and the mystical — wax seals on letters, closed containers, locked doors; bound spirits, contained forces, trapped demons. The same word serves both because the underlying concept is identical: closing something securely so it cannot escape or be tampered with. Whether the object is a letter or a demon, sealing is preventing unwanted causal flow. The computational renderings are familiar — sandboxed code, quarantined programs, access controls, encryption — and the behavioral renderings are this framework's containment strategies.

There are four ways to seal a behavioral demon.

Seal the invocation path. Remove the triggers that summon it. Alcohol out of the house and the addiction demon has no summoning ritual; the trigger photos and objects removed and the anxiety demon has nothing to invoke from; the apps deleted and the doom-scroll demon has no door. A demon that cannot be invoked cannot execute — prevention is sealing.

Seal through incompatibility. Create states in which the demon cannot exist. The gym and the doom-scroll are physically mutually exclusive; deep work and social media cannot both hold attention; a library with no phone leaves the procrastination demon nothing to run on. Design the system so the demon-incompatible state dominates, and the demon is sealed by architecture rather than by effort.

Seal in a bounded container. Some demons cannot be eliminated, only granted limited territory. Five minutes of daily worry time and anxiety is time-boxed; social media allowed on Sunday and sealed the rest of the week; procrastination permitted after 5pm and sealed during work hours. Containment concedes the demon's existence while denying it free run.

Seal through pattern replacement. Install a competing pattern that takes over the old pattern's territory. The gym demon that comes to own the after-work state seals the couch demon; the guitar demon that owns idle hands seals the phone demon. After thirty days the new pattern holds the resources, and the old one has nothing left to run on.

Ancient Descriptions of Computation

A speculation, held lightly: ancient peoples experienced computational phenomena but lacked the technological framework to describe them. What they called "spirits" and "demons" may have been early observations of computational patterns running on human neural and social substrates.

Read the old vocabulary this way and each term finds a modern referent. "Spirits" were self-propagating information patterns in human networks: ideas spreading person to person (the meme, in Dawkins's original sense), collective behaviors no single individual controls, patterns persisting across generations, cascades of panic and euphoria. The modern parallel is exact — "going viral" is an information demon propagating through a network, computation at network scale on a substrate of human minds.

"Demon possession" was a dominant pattern controlling behavior: addiction executing despite conscious intent, mania and obsession dominating consciousness, collective hysteria spreading through a group, compulsions running autonomously. In the modern frame, a persistent self-executing pattern capturing resource allocation — attention, behavior, decision-making.

"Exorcism" was a toolkit of pattern-termination techniques: rituals that interrupt execution through context switches, environment changes that prevent invocation, replacement patterns displacing old ones, social intervention supporting the termination. These are recognizably the modern debugging protocols, including replacement through sustained practice. And "sealing and binding" was pattern containment — blocked triggers, removed invocation methods, incompatible states, bounded territory — which is to say prevention architecture in pre-technological language.

The lore maps onto computational pattern dynamics because that is plausibly what it was describing: computation at a scale and on a substrate not usually recognized as computational. Nothing supernatural is needed at any point.

The Competing Forces Frame

From Will: persistent patterns "feel like another competing force." The same pattern can be narrated in three registers, and the register determines what you can do about it:

The moralistic register is a dead end. "I can't stop" reads as personal failure, "I'm broken" as unfixable identity, "I lack willpower" as a judgment with no debugging path attached. The demon register converts each of these into an engineering statement: an external pattern competing for control, a terminable and replaceable program, a resource-allocation problem solvable through architecture.

The practical gains are concrete. It is easier to fight a demon than to fight yourself — less shame, more strategy. Containment gives clearer instructions than self-improvement: "seal the demon's triggers" is an action, "fix myself" is a mood. Battling a demon is noble combat, where failing at willpower is moral failure, so the shame spiral never starts. And an externalized pattern is observable — you can map when it invokes, what triggers it, and how it executes.

Practical Applications

Naming Your Demons

The first move is a census. Name the persistent patterns that feel autonomous — the specific thought-feeling spiral you recognize as your anxiety demon, the avoidance choreography that runs when work appears, the automatic phone loop of the doom-scroll demon, the craving cycle of the sugar demon. Naming makes a pattern discrete: you can refer to a specific demon rather than a vague "problem," analyze it as something other than yourself, and test interventions against it.

Then map each one the way you would analyze an external program. When does it invoke — what triggers summon it? What does it do while executing? What resources does it capture: attention, time, physical action? How does it resist termination, and in what contexts can it not execute at all? The answers are the demon's specification, and the specification is where the seals go. Throughout, hold the third recognition: this is a separate program running on your substrate, not you.

Exorcism: Terminating the Pattern

Four strategies banish demons, in rough order of preference.

Starve the invocation. Map every trigger that summons the demon, then remove them from the environment and block the causal paths to invocation. Phone in a drawer in a different room, no cookies in the house, the trigger photo gone, the games deleted and the sites blocked. This is prevention as sealing, and its economics are why it comes first: one removal cost up front, then almost nothing forever. You are not fighting the demon; you have made it unsummonable.

Interrupt the execution. When a demon does get invoked, deny it a complete run. Discretize its territory: a five-minute worry timer that ends in externalizing to paper breaks the anxiety spiral before it can sustain itself; a 25-minute work timer with a forced break denies procrastination a full capture of attention; a ten-minute alarm cuts the scroll before the time distortion sets in. Each interruption costs some resistance, but far less than a completed execution would.

Create incompatibility. Install states in which the demon structurally cannot run — the gym for the doom-scroll demon, where no phone is present; the library for procrastination, where the triggers are absent; running for the sugar demon, since the actions are mutually exclusive; deep-work flow for anxiety, since flow captures all the attention the spiral would need. One setup cost, and then the state itself does the sealing.

Overwrite the pattern. Choose a replacement demon and execute it consistently for thirty days. The couch demon's after-work slot goes to the gym demon; the phone's ownership of the morning goes to coffee and a journal; idle hands get a guitar instead of a feed. The first two weeks are expensive, because you are forcing the new pattern against the old default — but the cost falls toward zero as the replacement becomes automatic, and by day thirty the old demon has no resources left to invoke with.

Containment: When Exorcism Fails

Some demons are chronic — too strong to eliminate, or attached to appetites that are not going anywhere. For these, containment beats a constant losing battle, and it comes in three grades.

Seal the demon in bounded space or time: five minutes of daily worry time, social media in a single evening window, "Sunday is procrastination day" with Monday through Friday sealed. The demon still exists, but contained is far cheaper than daily resistance.

Or go further and negotiate territory explicitly. Accept that the phone will be used — but only after 6pm. Accept that sugar will be eaten — but as dessert twice a week. Accept that anxiety exists — but inside its allotted worry time, not all day. Negotiation eliminates the shame of failed banishment and redirects the energy toward a boundary that can actually be held.

The third grade is competitive: feed a beneficial demon and let it win the resource war. A gym demon fed daily grows stronger until it owns the after-work state the couch demon used to hold; a deep-work demon that owns the morning starves the doom-scroll demon of its routing; an exercise demon simply crowds anxiety out. Installation costs the usual thirty days of consistent feeding — after that, the beneficial demon does the sealing for you, and the harmful one weakens from starvation.

Framework Integration

Connection to State Machines

Demons are states with default transitions. "Possessed by the X demon" is being in state X while its pattern executes; invocation and banishment are the transitions; and designing your states means choosing which demons the architecture allows. The default script decides which demon loads automatically — walk in the door after work and either the couch demon or the gym demon claims the state, depending on which default was engineered.

Connection to Attention Routing

Demons compete for routing. The winning demon captures attention, time, and behavior; exorcism removes a demon from the routing table entirely, and sealing is the architectural block that keeps it from winning the route in the first place. The doom-scroll demon and the deep-work demon are, concretely, two patterns contesting the morning's routing.

Connection to Addiction

Addiction is the classic demon — self-triggering, autonomous-feeling, persistent, the pattern for which the possession vocabulary was practically invented. The craving-seeking-consumption loop keeps invoking itself, and recovery is pattern termination plus replacement-demon installation.

Connection to Prevention Architecture

Prevention is the sealing of invocation paths. Fighting a demon daily is expensive resistance; sealing its triggers is a one-time cost that contains it permanently. Deleting the apps once versus resisting the check fifty times a day.

Connection to 30x30 Pattern

Thirty days is the overwrite period — the time a replacement demon needs to dominate and seal the old one. The cost curve falls from expensive forcing on day one to near-automatic by day thirty, at which point the old pattern is sealed by ownership rather than willpower.

Common Misunderstandings

"Demons are literal supernatural entities." No — this is poetic framing for self-sustaining patterns, chosen for its debugging utility. The metaphor should depersonalize, externalize, and suggest strategies; the moment it introduces mysticism instead, it is being misread. Mechanistic framework in demon language, not occultism.

"I'm possessed, therefore helpless." Backwards. The pattern has momentum, but you have the containment toolkit — seal, banish, contain. The framing exists to make patterns more debuggable, not less: external, analyzable, terminable. If the metaphor makes you feel like the victim of something unstoppable, it is being used wrong.

"One exorcism fixes it forever." Some demons seal easily — remove the sugar triggers and the pattern fades. Others are chronic: an anxiety demon may need its daily sealing indefinitely, and a couch demon stays sealed only as long as the gym demon keeps getting fed. Expecting permanence produces shame on every return. Expecting containment architecture produces maintenance, which is what chronic demons actually require.

Related Concepts

• state-machines - Demons as states with default transitions
• attention-routing - Demons competing for attention routing
• addiction - Classic demon pattern (self-triggering, autonomous)
• anxiety - Runaway demon (positive feedback spiral)
• procrastination - Competing demon (resource allocation battle)
• prevention-architecture - Sealing strategies (block triggers architecturally)
• 30x30-pattern - Overwriting demons through pattern replacement
• the-braindump - Externalizing thoughts (interrupting demon execution)
• discretization - Breaking demon execution (can't complete full run)
• computation-physical - Computation running on physical substrate (not just digital)

Key Principle

Model persistent patterns as demons — self-sustaining programs competing for control — and they become debuggable instead of shameful. Addiction, anxiety, procrastination, and intrusive thoughts share the phenomenology: autonomous-feeling, self-triggering, resistant to termination. The old vocabulary maps onto the computational one — demons are invoked by triggers, follow rules, and can be exorcised (terminated, interrupted mid-run, overwritten over thirty days) or sealed (invocation paths removed, incompatible states installed, territory bounded). It is easier to fight a demon than to fight yourself, and when banishment fails, containment and a well-fed competing demon still win the resource war. A metaphor for debugging, not a supernatural claim.

You're not possessed — you're running programs that need terminating. Name them, map their triggers, seal their doors. Exorcism is debugging; containment is architecture.