State Machines

#core-framework #computational-lens

What It Is

A state machine is a system that can be in exactly one state at a time, with defined transitions between states.

Every behavior exists in a state machine. Right now, as you read this, you're in reading_state. Possible transitions include:

  • Phone notification → distraction_state
  • Hunger signal → eating_state
  • Fatigue → rest_state
  • Book ending → reflection_state or next_activity_state

The Mechanism

Each transition has a probability based on:

  1. External triggers - Phone buzzing, someone calling your name
  2. Internal signals - Hunger, fatigue, emotional states
  3. Activation energy - How hard it is to switch states
  4. Current momentum - How stable the current state is

High-agency people don't have better self-control. They've engineered their state machine to make desired transitions easy and undesired transitions hard.

Example: Wake State → Work State

Old state machine:

stateDiagram-v2
    wake_state --> lounge_state: Phone visible (90%)
    wake_state --> work_state: Phone absent (10%)
    lounge_state --> lounge_state: Default loop

Engineered state machine:

stateDiagram-v2
    wake_state --> work_state: Phone locked (80%)
    wake_state --> morning_routine: Default path
    morning_routine --> work_state: Sequence complete

The difference isn't discipline. It's removing the state transition. The lounge_state option literally doesn't exist in the decision tree anymore.

Why This Matters

When procrastination happens, it's not a moral failure. It's work_launch_script failing to load, so default_script runs instead.

Your system is executing exactly as programmed. The state machine is working perfectly - it's just configured to produce the wrong transitions.

Prevention vs Resistance

Prevention means remove trigger = zero willpower cost

  • Phone is locked away
  • Netflix is blocked
  • DoorDash is deleted
  • You can't transition to a state if the trigger doesn't exist

Resistance means trigger exists and you must actively inhibit it = 2-3 willpower units per instance

  • Phone is on desk, you resist checking it
  • Netflix tab is open, you resist clicking it
  • Food delivery apps installed, you resist ordering

Prevention beats resistance by orders of magnitude. Not moral superiority. Architecture.

Default Scripts

When no explicit program is loaded, default_script runs automatically.

stateDiagram-v2
    [*] --> wake_state
    wake_state --> lounge_script: No explicit program
    lounge_script --> phone
    phone --> youtube
    youtube --> phone

    wake_state --> work_script: Explicit trigger loaded
    work_script --> focused_work
    focused_work --> work_script

For most people:

  • lounge_script - Phone, YouTube, lying around
  • distraction_script - Compulsive task-switching, email checking, "research" that goes nowhere

These scripts run because they have:

  • Near-zero activation cost
  • Immediate dopamine hits
  • No threshold to breach

Engineering State Transitions

To change behavior, don't fight the state machine. Redesign it.

1. Identify Current States

Map what actually happens:

  • When you come home, what state do you enter?
  • When you wake up, what's the default transition?
  • What triggers work_state? What triggers lounge_state?

2. Remove Undesired Transitions

Cut the triggers:

  • Phone → drawer (can't transition to distraction)
  • Food apps → deleted (can't transition to ordering)
  • Netflix → blocked (can't transition to binge)

3. Install Desired Transitions

Create automatic triggers:

  • Wake up → morning light → alert_state
  • Enter library → work_state (location-based)
  • 10-minute braindump completes → work_state (ritual-based)

4. Build Bridge Sequences

Cold starts are expensive. Build sequences that heat up the system:

graph TD
    Start([Wake State]) --> Light[Morning Light<br/>5:40 AM]
    Light --> Mantra[Mantra<br/>Luminettes 5min]
    Mantra --> Dump[Braindump<br/>10min externalize]
    Dump --> Check[Checklist<br/>Phone locked]
    Check --> Work[Work State]
    Work --> Focus[Focused Work]

Example morning bridge:

  1. Wake at 5:40 AM (automatic after day 15)
  2. Luminettes + morning mantra (5 min) - state-setting ritual
  3. 10-minute braindump - eliminates task ambiguity
  4. Pre-work checklist - phone locked, 3 tabs only, timer set
  5. work_state is now lowest-energy option

Hysteresis and Path Dependence

Current state depends not just on current conditions, but on the path you took to get here. This is hysteresis—the system exhibits memory of its history. Path dependency means you cannot simply jump to desired state while ignoring accumulated momentum. History constrains what is accessible now.

Starting work when already working costs approximately 0.5 willpower units due to existing momentum. Starting work from lounge_state costs 4-6 units due to cold start. Same task, different starting state, massively different energy cost. This is not variability in personal strength—it is path dependency in state machines.

The computational implication: you cannot ignore how you arrived at current state when planning next transition. If you are in lounge_state after waking late, skipping gym, and accumulating boredom, the path to work_state is expensive. If you are in alert_state after waking on time, completing morning mantra, and finishing braindump, the path to work_state is cheap. Different histories create different current energy landscapes.

This is why "just start" advice fails—it ignores path dependence. The same command "start working" has radically different costs depending on path taken to current state. Nature-aligned design means engineering your morning sequence so work_state is reached through natural low-cost transitions, not heroic threshold breach from unfavorable starting position.

The Detraining Path

Path dependency operates on longer timescales through detraining. After 90 days of work dormancy, neural pathways atrophy from disuse. Week 1 of reactivation operates at approximately 20% of previous capacity. This is not moral failure—it is path-dependent physical degradation.

The path taken matters. If you maintained consistent execution (30-day path), capacity remains at 100%. If you stopped for 90 days (dormancy path), capacity drops to 20% and requires progressive reactivation. Same person, different paths, different current capabilities. The system exhibits memory of its execution history.

Accepting path dependency means starting reactivation at 20%, building gradually through consistent execution, and reaching 80%+ by week 4. Fighting path dependency means demanding immediate return to previous capacity, encountering failure, and generating shame-based explanations. The first approach aligns with physical reality. The second fights it.

State Stability

Equilibrium states are dead - no gradients, no flow, no change:

  • lounge_state - Watching TV, scrolling, lying on couch
  • Stable but useless
  • System relaxed to minimum energy configuration

Far-from-equilibrium states require continuous energy input:

  • work_state, growth_state, learning_state
  • Prefrontal cortex active, attention focused
  • Inherently unstable, decay back to equilibrium unless energy supplied

Productive states degrade if you stop executing them. Not "losing discipline" - the system is returning to equilibrium when energy input stops.

Solution: Build systems that supply energy automatically through regular timing and circadian alignment.

Diagnostic Questions for State Machines

Diagnostic questions make state machines debuggable by forcing mechanistic analysis instead of moral judgment. When behavior doesn't match intention, asking "Why am I lazy?" accepts character-trait answers and produces guilt. Asking "What script is running instead of work script?" forces pattern matching against known default scripts and reveals actual system state versus intended state.

"What state am I in right now?" triggers binary introspection—check current behavior against state definitions and return match. This is O(1) cost and provides reality check that prevents delusion. "Am I in lounge state?" observes actual behavior (sitting on couch, browsing) and verifies against lounge_state definition rather than relying on subjective self-assessment.

"What's the transition trigger to work state?" identifies the mechanism that enables desired state changes. This is backward chaining from goal state: work_state requires what? Sequence script loaded. That requires what? Morning mantra and braindump completed. The question structure forces causal analysis that reveals the implementation path.

"What prevents this transition?" reveals intervention points. This depth-first causal search traverses backward from failed transition through immediate cause to root cause. Not "I lack discipline" (moralistic dead-end) but "Phone visible → lounge_script more salient → work_script doesn't load" (debuggable mechanism with clear intervention: remove phone from environment).

The Markov Property

State machines satisfy the Markov property: future evolution depends only on current state, not on how you arrived there. The history is encoded in the current state itself—what matters for predicting next transition is where you are now, not the path you took to get here.

The principle:

P(next_state | current_state, history) = P(next_state | current_state)

History is irrelevant once current state is known.

Behavioral implication:

Your past doesn't constrain your next action except through the current state it created. If you are currently in work_state with established momentum, the transition to next work action has high probability—regardless of whether you got to work_state through smooth morning sequence or struggled for an hour to breach threshold.

Example:

  • Scenario A: Woke on time → mantra → braindump → entered work_state smoothly
  • Scenario B: Woke late → struggled → eventually forced into work_state
  • Current state: Both are now in work_state
  • Next transition: P(continue working) is identical in both scenarios

The painful entry path (Scenario B) does not constrain current transition probabilities. Current state (work_state) is sufficient. This is liberating—rough starts don't doom the day. Once you reach desired state, transition probabilities reset based on current position.

Anti-pattern:

"I had a bad morning, so the whole day is ruined" violates Markov property. You're letting history (bad morning) determine future (rest of day) instead of recognizing that current state (now at work) is sufficient. The morning is encoded in current energy level (part of state), but the specific history is irrelevant.

Application:

Stop dwelling on how you got to current state. Current state determines available transitions. Focus on: where am I now? What transitions are available from here? Execute optimal transition. The path that brought you here matters only insofar as it shaped current state—beyond that, it's noise.

Measuring Transition Probabilities Through Tracking

You cannot directly see P(next_state | current_state). These transition probabilities are hidden. Tracking reveals them through measurement.

How Tracking Reveals State Machines

Without tracking:

  • "Sometimes I go to gym after work, sometimes I don't" (vague pattern)
  • "I work better in the morning" (subjective sense)
  • No quantified transition probabilities

With tracking:

Track 30 days correlating states and transitions:

State: "Home from work, energized"
  Next state tracked over 30 days:
    24x gym, 6x couch
  → P(gym | home_energized) = 24/30 = 0.8

State: "Home from work, depleted"
  Next state tracked over 30 days:
    5x gym, 25x couch
  → P(gym | home_depleted) = 5/30 = 0.17

Architectural insight: Energy state dominates P(gym). Not "motivation" or "willpower"—measurable transition probability conditioned on state.

Intervention: Protect energy through day → stay in "energized" state → P(gym) = 0.8 vs 0.17

Tracking Makes State-Conditional Probabilities Debuggable

State-dependent patterns become visible:

Current State Tracked Transitions (30 days) P(productive work) Architectural Insight
Morning, fasted, phone off 27/30 → work 0.90 Optimal configuration
Morning, fed, phone on 12/30 → work 0.40 Food + phone reduce P(work)
Afternoon, post-lunch 6/30 → work 0.20 Afternoon dip is real (measured)
Evening, depleted 2/30 → work 0.067 Nearly impossible state for work

Without tracking: Vague sense that "mornings are better" With tracking: Concrete P(work | state) quantified, architectural variables identified

Default Scripts = High-Probability Transitions

Tracking shows which transitions are "defaults":

State: "Couch after dinner"
  Tracked 30 days:
    28x → phone → YouTube
    2x → book

  P(phone | couch_evening) = 0.93 (this is the default script)
  P(book | couch_evening) = 0.067 (override required)

Mechanistic understanding: The "couch → phone" transition has P = 0.93. This isn't "bad habit"—it's measured transition probability revealing the default script.

Intervention: Change state entirely (don't sit on couch) OR modify environment (phone locked away) → new transition probabilities

Tracking Validates Architectural Changes

Before intervention:

State: "Home from work"
  P(gym) = 0.18 (tracked 90 days)

After architectural modification:

  • Installed bridge sequence (car → gym bag → drive)
  • Julius forcing function (accountability)

Validation through tracking:

State: "Home from work" (same state, new architecture)
  P(gym) = 0.87 (tracked 30 days post-intervention)

Distribution shift measured: 0.18 → 0.87

The tracking shows the intervention worked—not subjective impression but measured probability change.

Why Measurement Matters for State Machines

State machines model: Each state has probability distribution over next states

The problem: Consciousness cannot directly observe these distributions

The solution: Tracking accumulates transition samples → reveals P(next | current)

This makes state machines operational:

  • Not theoretical model but empirical measurement
  • Not "I think X state leads to Y" but "P(Y|X) = 0.75 measured over 30 days"
  • Enables architectural debugging: modify architecture → measure new P(Y|X) → validate change

Tracking converts state machine theory into behavioral engineering practice.

Key Principle

Engineer the state machine, don't fight it - Remove undesired transitions by eliminating triggers, create desired transitions through automatic cues, build bridge sequences to reduce cold-start costs.

This is computational thinking applied to behavior. Your state machine is executing perfectly according to its current configuration. Change the configuration and behavior changes automatically.