State MachinesA cue can become a transition; mapping those transitions reveals where a routine starts, stalls or drifts.
What It Is
When you arrive home, what happens next? You might put on gym clothes, open your laptop, or sit on the couch and reach for your phone. A state-machine description names the situation you are in, the situations you can enter from there, and the triggers that move you between them.
A state machine occupies exactly one state at a time and has defined transitions between states. Any behavior can be described as happening within one. While you read this page, you are in reading_state. A phone notification can move you to distraction_state, hunger to eating_state, and fatigue to rest_state. Reaching the end of a book can lead to reflection_state or next_activity_state.
The Mechanism
A transition's probability depends on four things. External triggers include a buzzing phone or someone calling your name. Internal signals include hunger, fatigue, and emotion. Activation energy is the effort required to switch. Current momentum is the stability of the state you already occupy.
Engineering these conditions makes desired transitions easy and undesired ones hard, which from outside looks like better self-control. The configuration changes which action is likely to follow the current one.
Example: Wake State → Work State
In the original configuration, a visible phone makes lounging the likely next step:
stateDiagram-v2
wake_state --> lounge_state: Phone visible (likely)
wake_state --> work_state: Phone absent (rare)
lounge_state --> lounge_state: Default loop
The engineered configuration locks the phone away and provides a morning sequence that leads into work:
stateDiagram-v2
wake_state --> work_state: Phone locked (likely)
wake_state --> morning_routine: Default path
morning_routine --> work_state: Sequence complete
The change removes a transition instead of asking you to resist it. lounge_state no longer exists as an option in the decision tree.
With the phone within reach, picking it up is the easiest move out of waking, and being on the phone leads back to itself.
Why This Matters
When procrastination occurs, work_launch_script has failed to load and default_script runs instead. The system is doing what its current configuration produces. The failure is in a configuration that produces the wrong transitions, so diagnosing that configuration provides a way to change what happens.
Prevention vs Resistance
Prevention removes the trigger and leaves nothing for willpower to do. The phone is locked away, Netflix is blocked, or DoorDash is deleted. If the trigger does not exist, the transition cannot occur.
Resistance leaves the trigger present and requires you to inhibit the response. You keep the phone on the desk but resist checking it, leave Netflix open but resist clicking, or keep delivery apps installed but resist ordering. Each instance is another act of resistance.
That difference makes prevention much cheaper: one change to the environment against an act of resistance every time the trigger appears. The saving comes from changing what the environment can trigger, rather than repeatedly paying to suppress a transition it still offers.
Default Scripts
If 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
A typical lounge_script includes the phone, YouTube, and lying around. Another default, distraction_script, produces compulsive task-switching, email checking, or “research” that goes nowhere. These routines start at near-zero activation cost, provide immediate rewards, and require no threshold crossing. Unless another program is loaded, they are the available low-cost sequence.
Engineering State Transitions
Changing the state machine begins with the transitions that actually occur. The following steps separate observation, removal, installation, and the preparation needed for an expensive transition.
1. Identify Current States
The first questions concern ordinary points in the day: “When you come home, what state do you enter?” and “When you wake up, what's the default transition?” Identifying what triggers work_state and what triggers lounge_state gives you a map of the system you have, rather than the schedule you intended.
2. Remove Undesired Transitions
Removing a trigger cuts its transition. Moving the phone to a drawer prevents the move into distraction; deleting food apps prevents ordering; blocking Netflix prevents a binge. The intervention changes availability before the moment when you would otherwise need to resist.
3. Install Desired Transitions
A desired transition needs a trigger of its own. Waking and receiving morning light leads to alert_state. Entering a library supplies a location-based trigger for work_state. Completing a 10-minute braindump supplies a ritual-based trigger for the same state.
4. Build Bridge Sequences
A cold start is expensive because the system is not yet prepared for the destination. A bridge supplies intermediate steps that make work progressively more accessible.
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]
In this morning example, the aim is for waking at 5:40 AM to become automatic. Five minutes of Luminettes and the morning mantra establish the state. A 10-minute braindump removes task ambiguity. The pre-work checklist then locks the phone, limits the browser to 3 tabs, and sets the timer. By the end of the sequence, work_state is the lowest-energy option.
Hysteresis and Path Dependence
The current state includes effects of the path that produced it. This dependence on history is hysteresis. Accumulated momentum changes what is accessible now, so you cannot plan a transition as though the route to the present state had no effect.
Continuing work when you are already working takes little willpower. Starting the same work from lounge_state takes a threshold crossing. The task is the same; the starting conditions differ. The cost difference reflects path dependence rather than a change in personal strength.
Waking late, skipping the gym, and accumulating boredom leave an expensive route from lounging to work. Waking on time, completing the mantra, and finishing the braindump leave a cheap route from alertness to work. Each history creates a different present energy landscape.
“Just start” ignores this difference. The command names a destination without accounting for the cost of reaching it from here. Nature-aligned design instead arranges the morning so that a sequence of low-cost transitions reaches work without an expensive threshold crossing from an unfavorable state.
The Detraining Path
History also affects capacity over longer periods. After 90 days without work, the ability to do it has faded through disuse, and the first week of reactivation runs well below the previous capacity. The loss is real and path-dependent.
A 30-day path of consistent execution keeps capacity where it was. A 90-day dormancy path lowers it and requires progressive reactivation. The person is the same, but the execution history has changed what the person can currently do.
Reactivation therefore starts low and builds through consistent execution, with the aim of reaching the old level over several weeks rather than on the first day. Demanding the previous capacity immediately produces failure and invites shame-based explanations for a limit that follows from the system's history. Gradual rebuilding works with that limit.
State Stability
In physics, an equilibrium state has no gradient, flow, or change. lounge_state—watching TV, scrolling, or lying on the couch—resembles one: it is stable but useless, the configuration the system relaxes into when nothing pushes it elsewhere, and nothing develops there.
work_state, growth_state, and learning_state resemble systems held far from equilibrium. Attention is focused, and the states last only while effort keeps going into them; when that input stops, they decay back toward the couch.
Productive states therefore degrade when you stop executing them. Regular timing and circadian alignment supply that input on a schedule, allowing the system to keep supporting the state instead of repeatedly rebuilding it after it decays.
Diagnostic Questions for State Machines
Diagnostic questions determine what kind of explanation you search for. “Why am I lazy?” accepts a character label and produces guilt. “What script is running instead of work script?” requires you to compare the observed behavior with known defaults and identify the actual state.
“What state am I in right now?” performs a binary check against state definitions. It has O(1) cost and provides a reality check. “Am I in lounge state?” can be answered by observing that you are on the couch browsing, rather than relying on a general impression of how productive you feel.
“What's the transition trigger to work state?” works backward from the destination. Work requires the sequence script to be loaded; loading it requires the mantra and braindump to be complete. Each answer identifies a predecessor that can be implemented.
“What prevents this transition?” follows a failed transition backward through its immediate cause toward the root cause. A depth-first causal search can reveal “Phone visible → lounge_script more salient → work_script doesn't load.” That explanation specifies an intervention—remove the phone—where “I lack discipline” ends the search without one.
The Markov Property
State machines satisfy the Markov property: once the current state is fully known, earlier history contributes no further information about the next transition. The effects of that history are encoded in the state itself.
P(next_state | current_state, history) = P(next_state | current_state)
History is irrelevant once current state is known.
This differs from saying that history had no effect. A bad morning can leave you with less energy, and that energy level belongs to the current state. What becomes irrelevant is the particular story of how you acquired it, beyond the state it produced.
The comparison stops at the states themselves. A designed machine's states are fixed in advance; a person's states are labels chosen for the question at hand, so the property holds only as far as the label carries what matters, such as the energy a bad morning left.
Consider two routes into work. In Scenario A, you wake on time, complete the mantra and braindump, and enter work smoothly. In Scenario B, you wake late, struggle for an hour, and eventually cross the threshold. Once both are in work_state with the same energy, the chance of continuing to work is the same. Established momentum makes the next work action likely regardless of the entry route.
“I had a bad morning, so the whole day is ruined” violates this property by treating the earlier event as a continuing constraint after the relevant state has changed. A rough start does not doom the day. Once you reach the desired state, transition probabilities are determined by the present position.
The useful questions are therefore where you are now and which transitions are available from here. The path matters insofar as it shaped that state; dwelling on it beyond that supplies no additional information for choosing the next transition.
Measuring Transition Probabilities Through Tracking
You cannot directly see how likely each next state is. Tracking makes these hidden probabilities visible by accumulating examples of what followed each state.
How Tracking Reveals State Machines
“Sometimes I go to the gym after work” and “I work better in the morning” describe impressions without quantifying the transitions. Recording states and outcomes over 30 days produces a different kind of account, such as this one:
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
In records like these, energy state dominates the chance of going to the gym. Protecting energy throughout the day preserves the energized starting state, from which the gym followed on 24 days in 30, instead of the depleted one, from which it followed on 5. The intervention follows from a difference between states that the records show.
Tracking Makes State-Conditional Probabilities Debuggable
Recording more of the starting conditions can expose further differences, as in this example:
| Current State | Tracked Transitions (30 days) | Share to productive work | Architectural Insight |
|---|---|---|---|
| Morning, fasted, phone off | 27/30 → work | 0.90 | The best of these four |
| Morning, fed, phone on | 12/30 → work | 0.40 | Food and phone together go with less work |
| Afternoon, post-lunch | 6/30 → work | 0.20 | An afternoon dip |
| Evening, depleted | 2/30 → work | 0.067 | Work rarely starts from here |
The vague impression that mornings are better becomes a set of conditional probabilities. Food, phone availability, time of day, and depletion are now variables in a configuration you can change and measure.
Default Scripts = High-Probability Transitions
A default is a transition that occurs with high probability from a recurring state, as in this example:
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)
In this example the couch leads to the phone on 28 evenings in 30. Calling it a bad habit does not add to that count. The result instead suggests two interventions: avoid entering the couch state, or change its environment by locking away the phone. Either creates new transition probabilities to observe.
Tracking Validates Architectural Changes
Consider a home-from-work state that produced this result before any change:
State: "Home from work"
P(gym) = 0.18 (tracked 90 days)
An intervention then added a bridge from car to gym bag to driving, together with Julius as an accountability forcing function. The following 30 days produced:
State: "Home from work" (same state, new architecture)
P(gym) = 0.87 (tracked 30 days post-intervention)
The share of gym days went from 0.18 to 0.87. Tracking shows the change as a number that can be compared, rather than leaving it as a subjective impression.
Why Measurement Matters for State Machines
Each state has a probability distribution over next states, but you cannot observe that distribution directly. Tracking supplies samples from which it becomes visible.
That changes the model into an empirical practice. Instead of “I think X leads to Y,” you can say how often Y followed X over 30 days of records. After modifying the environment or sequence, you can count again and determine whether the change produced the intended transition.
Related Concepts
- Procrastination — failure to load the work-launch script
- Activation Energy — the cost of changing states
- Willpower — the resource spent on transitions
- Superconsciousness — kernel mode for forcing a transition during installation
- Prevention Architecture — removing transitions entirely
- Discipline — the appearance of automatic desired transitions
- Zeitgebers — external synchronizers that trigger transitions
- The Braindump — a bridge into work
- Question Theory — diagnosing states and transitions
- Nature Alignment — working with path dependence and momentum
- Statistical Mechanics — order parameters and phase transitions
Key Principle
Behavior follows the state machine's current configuration. Removing an unwanted trigger, supplying a desired cue, or adding a bridge changes that configuration, and with it which behavior is likely to follow. Tracking then shows how the next-state distribution changed and where another adjustment is needed.