DEV Community

Cover image for Your Relationship Status Is Hardcoded — Here's How to Rewrite the Runtime
course to action
course to action

Posted on

Your Relationship Status Is Hardcoded — Here's How to Rewrite the Runtime

Your Relationship Status Is Hardcoded — Here's How to Rewrite the Runtime

You have tried everything at the behavior layer.

You optimized your dating profile. You went to the events. You read the attachment theory books. You did the "put yourself out there" thing that everyone recommends, the way a junior dev cargo-cults Stack Overflow answers without understanding the underlying architecture. You executed every strategy that operates on the surface — the HTTP requests, the API calls, the carefully constructed payloads — and the server keeps returning the same response:

HTTP 403 Forbidden
{ "error": "identity_mismatch", "detail": "request does not match internal state" }
Enter fullscreen mode Exit fullscreen mode

You are not bad at relationships. You are not broken. You are not running out of time.

You are running the wrong process at the wrong layer.


The Reframe: Configuration vs. Runtime

Here is the assumption buried inside every piece of dating advice you have ever received: if you change what you do, you change what you get. More effort. Better strategy. Different venues. Clearer communication. All of it operates at runtime — the execution layer.

Shelly Bullard's I Do Course makes a different claim entirely. The claim is that your relationship status is not a runtime problem. It is a configuration problem. Specifically: your self-concept — the deep, persistent store of who you believe yourself to be — is the config file that every external circumstance reads from. Your partner's behavior, your recurring patterns, the way situations keep resolving into the same outcome — all of it is derived state. Rendered views. Components pulling from a single source of truth that you never thought to inspect.

The analogy is exact. You have been debugging the UI when the bug is in the data layer. You have been patching components when the state store is corrupted. Every behavioral intervention you have tried is the equivalent of editing the DOM directly and wondering why the changes do not persist after re-render.

The I Do Course is a $997, 52-lesson, 22.8-hour program that teaches one thing: how to rewrite the config. Not what you do. Who you are. According to the full breakdown on Course To Action, the course contains six named frameworks built around this single architectural insight.

That premise will either click immediately or sound absurd. This post is for people in the first group — specifically for people who think in systems, and who have noticed that their relationship patterns have the consistency of a deterministic function.


One Framework Deep: The Three-Phase Daily Protocol

Most manifestation content gives you principles and leaves you stranded at the implementation layer. You understand the theory. You have no CI pipeline. You have no idea what to actually run on a Tuesday.

The Three-Phase Daily Protocol is Shelly Bullard's answer to the implementation problem. It is a structured daily process for installing a new identity — the way you would deploy a new configuration across an environment, methodically, in phases, with each phase targeting a different write window.

Here is the full protocol.

Phase 1 — Morning Scripting (Initialize)

Every morning, before the day's inputs start overwriting your state, you run a scripting session. This is literal writing — pen, paper, first-person present tense — where you describe your life from inside the target identity. Not "I want to be married." Not "I hope this works." The scripting is written from the perspective of someone who is already there.

// morning_init.js
const session = Identity.initialize({
  state: "married",
  tense: "present",
  perspective: "first_person"
});
Enter fullscreen mode Exit fullscreen mode

The function of morning scripting is environment variable injection. You are setting the values that every downstream process will read from for the rest of the day. If you skip this phase, your system boots with the legacy defaults — the old self-concept, the old identity, the old "single and waiting" configuration that has been producing the same output for years.

The course is specific about the mechanics. You write in detail. You write with sensory texture. You write about the mundane Tuesday-morning version of being married, not the highlight reel. The goal is not to generate emotion on demand — it is to make the target state feel ordinary. Familiar. Default. Because a new identity does not install through excitement. It installs through repetition until it feels like the baseline.

Phase 2 — Afternoon Saturation (Cache Warming)

By midday, your morning initialization is under siege. Reality sends contradictory inputs. Your phone is quiet. Your friend announces an engagement. A date cancels. The old state is trying to reclaim the cache.

Afternoon saturation is the countermeasure. Shelly prescribes sensory visualization and audio reinforcement — tools designed to keep the new identity hot in working memory so it does not get evicted by incoming evidence that contradicts it.

Think of this as cache warming. Your new self-concept is a recently-written value that has not yet been promoted to long-term storage. It is vulnerable to eviction. Every contradictory data point from the outside world is a cache invalidation attempt. Saturation keeps the new value in L1 — active, accessible, and resistant to replacement.

The course provides specific audio tools and visualization exercises for this phase. The key discipline is not intensity but consistency. You are not trying to force a feeling. You are maintaining a signal. The way a background service keeps a connection alive with periodic heartbeats, you are keeping the new identity alive against the ambient noise of your current circumstances.

Phase 3 — Night Imaginal Acts (Commit to Long-Term Storage)

This is the core technique borrowed from Neville Goddard, and the course treats it as the most important phase of the three. The protocol: as you fall asleep, you enter a specific imagined scene — not a movie, not a fantasy, but a single short scene that implies your desired state is already realized. A scene from inside the marriage, not of the wedding day. The ring on the counter. A conversation about weekend plans. The mundane, not the cinematic.

The hypnagogic state — that threshold between waking and sleep — is treated as a privileged execution context. Your conscious mind's type-checking is relaxed. The subconscious accepts new values with lower resistance. This is the write window where the new identity commits to the deep store, the way a database flush moves data from the write-ahead log to permanent storage.

// night_commit.js
async function commitIdentity(scene) {
  await consciousness.enterHypnagogicState();
  // Type-checking relaxed in this context
  deepStore.write({
    identity: "married",
    scene: scene,
    tense: "present_realized"
  });
  // Commit persists through sleep cycle
}
Enter fullscreen mode Exit fullscreen mode

You loop the scene. You feel it as real. You fall asleep inside it. And you do this every single night, the way a nightly batch job runs the same migration until the schema matches the target.

The Compound Effect

Run all three phases daily for six weeks and here is what the course claims happens: the old self-concept — "single," "unchosen," "still waiting" — gets overwritten at the identity layer. Not suppressed. Not argued with. Replaced. The same way you do not argue with a deprecated config file. You deploy the new one and the old one stops being read.

The structural specificity is what separates this from vague "just visualize" advice. Morning scripting initializes. Afternoon saturation maintains. Night imaginal acts commit. Three write operations targeting the same store, three times a day, each leveraging a different access window. It is a deployment pipeline for identity.


Where This Article Stops — And Why

I have given you the full daily protocol. You could start running it tonight. But here is what I have deliberately not given you: the theoretical foundation that explains why this protocol targets identity rather than behavior, why your external reality is derived state, and why other people's behavior toward you reflects your own internal store.

That foundation is called the Three Manifesting Principles — and without it, the daily protocol is a CI pipeline with no architecture document. You will run it. You will not understand why it works. And when it stops producing results — or when contradictory evidence shakes your consistency — you will have no foundation to debug from.

The protocol is the implementation. The principles are the specification. One without the other is incomplete by design.


The Question That Actually Matters

The question is not "how do I find the right person" or "how do I make them commit." Those are runtime questions. Behavioral-layer questions. The kind of questions that produce the same 403 response no matter how many times you retry with different parameters.

The question that actually matters is: what identity is your system currently configured to express — and is it the one that produces the output you want?

If the config says "single," every process downstream will render "single." No amount of behavioral optimization changes that. The daily protocol rewrites the config. But the config only makes sense inside the full architecture.


What the Full Architecture Contains

The I Do Course teaches six named frameworks. I have taught you one — the Three-Phase Daily Protocol. Here is what the remaining five cover, by name only:

  • Three Manifesting Principles — The theoretical foundation (Self-Concept, EIYPO, Living in the End) that explains why identity is the primary variable and external reality is derived state
  • Two-Factor Model — The framework for understanding that manifesting a specific person involves two independent running instances, not one, and why you have limited write access to your partner's process
  • Certainty Percentage Framework — The diagnostic and observability layer: how to measure your actual identity installation progress and calibrate practice intensity to your real signal, not a one-size prescription
  • Bridge of Incidents — The eventual consistency model: why you do not need to engineer the path from current state to target state, and how circumstances self-organize once the identity shift commits
  • Two-Step Affirmation Method — The bridge pattern for handling the gap between your current identity and your target identity without triggering rejection from your own type-checking system
  • Nine Common Challenges Framework — The incident response runbook: nine documented failure modes (doubt, impatience, evidence of absence, third-party interference) with structured debugging procedures

Six frameworks. 52 lessons. 22.8 hours. One architectural claim: you do not manifest what you want. You manifest who you are.


What This Costs — And What It Does Not Have to Cost

The I Do Course is $997. For 52 lessons and six frameworks targeting marriage-specific identity work, that is a serious investment in a single-domain system.

Here is the alternative path.

Course To Action publishes the full independent breakdown of the I Do Course — every framework, every limitation, the complete architecture — starting free. The full library is $49/year for 110+ course breakdowns across every category. No subscription trap. One payment, one year, every course they publish.

That is $997 for one course versus $49 for 110+. Both have their place. But if you want to understand the full architecture before committing $997 — or if you want to see how the same identity-shift principles apply across domains beyond marriage — the $49 path gives you test coverage across the entire catalog.

The breakdowns include AI-powered tools, audio versions for commute listening, and the kind of framework-level depth that lets you evaluate before you invest.

Start free at Course To Action — the full I Do Course breakdown, every framework, every honest limitation. Then decide what your system actually needs.

Top comments (0)