# Order of Determination

URL: https://mechanisticmindset.com/wiki/order-of-determination
Tags: core-framework, system-design

# Order of Determination

#core-framework #system-design

## What It Is

“The system routes attention” could accompany thousands of different screens. Writing that sentence has not decided what the viewer will see, how the scene will move or which visual change should coincide with a word. If the narration is recorded first, all those decisions still have to be made against timing that was chosen without them.

**Order of determination** sequences work by deciding the representation with the most degrees of freedom first. A representation's degrees of freedom are the ways it can still vary. Once that representation is fixed, the more constrained ones can be derived from it: concept before visuals, visuals before narration, specification before code, product before pitch deck.

A creative process is a constraint-satisfaction problem across representations. A high-dimensional assignment constrains a lower-dimensional one toward a nearly unique answer. The reverse leaves most of the high-dimensional choices unresolved. Constraint propagation works downhill. Trying to make a low-dimensional artifact determine a high-dimensional one makes convergence structurally impossible, rather than merely more difficult.

The resulting instability is recognizable. Each edit creates several more, versions multiply and none feels right. **Anxiety about downstream work signals that a determining representation upstream remains open.** The problem is almost never in the artifact currently being polished. Its requirements are still changing because something it depends on has not been decided.

This ordering applies causality to representations. The work that determines other work has to be settled first.

## The Canonical Case: Visuals Before Narration

Will derived the principle while making videos. An explainer's visual track has layout, motion, timing, composition and a changing focus of attention. Narration is a linear sequence of sentences. The visual track has many more ways to vary.

Writing the narration first feels natural because producing words feels like thinking through the piece. But “adding visuals” afterward always produces the same failure: animation attached to prose without the important visual changes landing on the important words. The two tracks feel disconnected.

> "Why visuals-first is mechanically correct: constraint ordering. Specify representations in decreasing order of degrees of freedom. ... Pin down the artifact with the most freedom first so it constrains the derived one instead of being vaguely implied by it."

The difficulty follows through four steps:

1. **Words leave the visual choice open.** “The system routes attention” does not determine which of its thousands of compatible screens to use. Choosing one is a guess beyond what the sentence specified.
2. **That guess must still synchronize.** A key visual needs to land on a key word, but the words were timed before any visual beat existed.
3. **Repairs disturb both tracks.** Recutting the animation detaches the words from its timing. Rewriting the words leaves the animation timed to sentences that no longer exist. Neither track determines the other, so each repair creates another negotiation.
4. **A fixed sequence resolves the dependency.** Decide the concept, author the visuals, write narration to what is on screen and then synthesize audio. Each stage becomes cheap because the previous stage has determined its requirements.

The complete refinement chain adds beats between concept and scenes:

| Stage | Artifact | Degrees of freedom | What it determines |
|-------|----------|-------------------|-------------------|
| 1 | Concept flow | Highest: what the piece is about | The [macrostate](/wiki/macrostate-engineering) of the stages below |
| 2 | Beats | High: atomic meanings and their order | The intermediate representation |
| 3 | Scenes / visuals | Medium: what appears on screen | The code-generation target |
| 4 | Narration | Low: words describing those visuals | Annotation of the executable |
| 5 | Audio | Lowest: synthesis of fixed words | The rendered speech |

> "The full refinement chain is concept -> beats -> scenes -> voiceover, where each level is the macrostate of the one below it. ... Compiler analogy: beats are the IR, scenes are the codegen target, and the voiceover is the comments. The visual track is the executable — it is what actually runs in the viewer's head."

The compiler relationship is exact. The visual track is the executable; the voiceover comments on what it does. Writing the comments first and trying to derive the program from them reverses the dependency.

The executable is whatever runs in the receiver's head. In an explainer, that is the visual track. In conversation, it is the mental model induced by the words. The words annotate that model, so the model needs to be designed first. Sentence-first explanations can transmit nothing because they determine the annotation while leaving the higher-freedom mental model vaguely implied. The [communication framework](/wiki/communication-framework) follows the same ordering.

## Case Study: From Bug to Law in Three Weeks

The idea developed through a sequence of observations and tests across domains.

**June 8.** While examining advice, Will noticed: "the thing people tell me to do is often the symptom. There is no point in fixing something downstream if the upstream object is wrong — fix the upstream first." The upstream/downstream distinction was present, but the constraint mechanism had not yet been named.

**June 10, morning.** The video problem made the mechanism explicit: "specify representations in decreasing order of degrees of freedom." Will derived constraint ordering, the refinement chain, the compiler analogy and the type-confusion problem in the same sitting.

**June 10, later that day.** He tested the mechanism against months of fundraising anxiety. The deck, valuation and cap were committed while “who is this for” remained open. The anxiety had tracked the unresolved freedom above those commitments. The same mechanism explained failures in two different domains, rather than only a video-production problem.

**June 23.** The observation became a prioritization rule: "Focus on the things that determine other things. That decides the order. ... Felt like such a universal principle."

**June 30.** It extended to scheduling: "get it in early. Earlier decisions determine later ones — they either close or expand the possibility space." The ordering now applied to decisions within a life as well as artifacts within a project.

The move from a local failure to a mechanism that explained an earlier, unrelated problem supports the claim that the principle was discovered. Its rapid generalization showed how much work the same dependency structure could explain.

## Type Confusion: Same Surface Form, Different Degrees of Freedom

Two representations can look alike while playing different roles. As Will put it, "the bug is a type confusion where two different artifacts share the same surface form."

A beat script and a voiceover are both written in inner-voice English. The beat script specifies meanings that the visuals must satisfy. The voiceover annotates finished visuals. If they are treated as the same type of artifact, writing the annotation can feel like writing the specification even though the determining choices remain open.

| Confused pair | Shared surface | Different roles | Result of confusing them |
|---------------|--------------------|--------------|----------------------|
| Beat script and voiceover | Inner-voice English | Specification and annotation | Video that cannot synchronize |
| Fundraising narrative and product | Inner-voice language | Annotation and executable | A polished pitch around an undetermined product |
| Specification and code comments | Prose about the system | Determining and derived | Code that implements no decision |
| Plan and commitment | A list of intentions | Recomputable and binding | A plan mistaken for fixed state; see [macrostate engineering](/wiki/macrostate-engineering) |

The fundraising case exposed this confusion directly:

> "The anxiety was always proportional to the unconstrained degrees of freedom left upstream of what was already committed downstream — deck/valuation/cap specified precisely while 'who is this for' stayed open. Same type confusion as the video bug: fundraising narrative and product are both rendered in inner-voice language, so the annotation felt like the executable."

The product and the story about it were both represented as inner-voice sentences. Polishing the narrative therefore felt like developing the product. But the product was still unresolved, so each version of the deck was being judged against requirements that could change. No amount of deck editing could settle whom the product served.

## Anxiety as the Instrument

In creative work, this gives [anxiety](/wiki/anxiety) a dependency-based explanation. A derived artifact has been committed while its source remains in several possible states. Each possible source state implies a different correct version of the artifact. The work cannot feel settled while the answer against which it is judged keeps moving.

The repair is to inspect the dependencies:

1. Name the unstable artifact: the deck, scene, paragraph or function.
2. List the representations that determine whether it is correct.
3. Check whether each dependency exists in a dated, locked artifact. A feeling of knowing, chat log or promise to decide later does not fix it.
4. Stop at the first open dependency. Decide it, even roughly, before editing the dependent artifact again. The downstream versions then stop multiplying.

This is the earlier debugging observation in practice: "The thing people tell me to do is often the symptom. There is no point in fixing something downstream if the upstream object is wrong — fix the upstream first."

Priority follows from determination rather than size:

> "Focus on the things that determine other things. That decides the order. Not 'focus on the big stuff' but 'focus on the upstream stuff that decide the rest.' Felt like such a universal principle."

A decision's leverage is the number of downstream choices it resolves. Earlier decisions "either close or expand the possibility space." The best attention therefore belongs where it determines the most other work, usually earlier and at a higher level of abstraction than the place where discomfort appears.

## Generalization: Every Creation Is a Determination Chain

| Domain | Decide first | Derive afterward | Failure from reversing the order |
|-------|--------------|------------------|----------------------------------|
| Video | Concept flow and visuals | Narration and audio | Words timed without visuals, animation attached afterward |
| Software | Specification and architecture | Code, tests and comments | Rewrites of code that encodes no decision |
| Fundraising | Product and intended user | Deck, valuation and cap table | A polished pitch for an undetermined product |
| AI fan-out | Taste lockfile; see [selection over design](/wiki/selection-over-design) | Generated candidates | Many outputs without a way to select among them |
| Writing | Argument structure | Sentences and style | Polished paragraphs around an unresolved claim |
| A day | The day's [macrostate](/wiki/macrostate-engineering) | Hour-by-hour actions | Schedule optimization while the mission remains open |

**Specifications precede code.** LLMs make a specification directly testable: "I don't need to turn my theory into code — I can just test it." That strengthens the ordering. The determining representation can now run as a prototype before code is produced. Complex specifications appreciate as models improve; complex code depreciates.

**Taste precedes fan-out.** Before generating a hundred candidates, fix the selector: "skill + golden set + mechanical verifier + rejection ledger, versioned as one unit — a lockfile for taste." Without it, generated variance has no criterion for convergence. "the system is my taste made executable" requires taste to have been serialized first.

**Determination order is merge order.** Parallel work can merge only if the common target existed before the branches diverged. In Will's parallel video work, "the real determinant is whether the thing can be MERGED from parallel results". A shared upstream decision makes each result derivable into the same destination. [Branching and convergence](/wiki/branching-and-convergence) permits free branching below a fixed layer, never above an unresolved one.

## The Temporal Form: Early Choices Produce the Path

A day's early choices determine the inputs available to later choices. Choice A produces the state in which choice B occurs. A different A creates different options and a different person choosing among them. Early actions close some branches and instantiate others, as the first moves of a game determine which later games remain reachable.

This is a structural claim rather than a probability claim:

> "what's so not obvious about 'choices made early on determine later ones'? — obvious version is good choices lead to good choices later but that's not really what i'm getting at — i dont think im talking about probability... choices DETERMINE — as in they produce a path."

Protein at 10am removes the 9pm state in which 80g remains uneaten and only a bad resolving option is available. Will describes the effect of the gym at 8am this way: "it constructs a day in which the person deciding about food is a gym person." The early action changes the later decision's inputs instead of merely making a good decision more likely.

Resources also diminish as the day proceeds. Time, energy, [willpower](/wiki/willpower) and stomach capacity are consumed. A late action must survive every earlier demand on them. An action scheduled first faces none of those competing claims.

| Slot | Downstream reach | What belongs there |
|------|------------------|--------------------|
| Morning | High: its output becomes input to the rest of the day | State-producing choices such as protein, gym contact and the day's [macrostate](/wiki/macrostate-engineering) |
| Late day | Low: nothing remains downstream to determine | Terminal choices such as entertainment and administration |

The morning is the **high-fan-out register**. Schedule definite priorities early, when they determine the most subsequent states. "Priority without early placement is just sentiment."

“Start your day right” treats the effect as momentum that improves later odds. Determination concerns which later decision points exist at all. The observation can seem obvious while remaining unused: "they're obvious once u mention it but nobody ever acts about their consequences." Its value comes from rebuilding the schedule around those consequences, rather than merely recognizing them.

## Mode-Locking: Letting a Determination Bind

A decision constrains later work only if it stays fixed during that work. **Visionary mode** questions the mission and quality standard while both remain open. **Executor mode** derives work against the chosen mission and standard. Doubt helps the first mode but disrupts the second by reopening its premises.

> "As a solo founder I really need visionary mode and then executor mode… I need to pre-orchestrate and pre-define the mission and pre-define the quality FOR MYSELF, cuz I can't flip between visionary and executor modes I will keep doubting myself."

The modes need separation in time and an authoritative artifact at the boundary. A journal, chat or rolling document keeps each decision beside newer thoughts that can renegotiate it. Moving the decision into a locked specification gives execution a fixed reference: "ok so it should be enshrined."

| Property | Stream: journal, chat, rolling document | Shrine: enshrined specification |
|----------|--------------------------------------|-------------------------|
| Mutability | Always editable | Locked at a dated version |
| Authority | Competes with each new thought | Holds until deliberate re-determination |
| Mode | Visionary; doubt is welcome | Executor reads it and defers doubt |
| Downstream effect | Each entry can change the requirements | Work derives from a fixed answer key |

Closing a specification issue, dating a document or cutting a version creates a **lock event**. Tools such as Linear matter beyond bookkeeping because they make that transition explicit. A thought becomes a binding determination.

Perfectionism is a validation loop without exit criteria. Every result reopens the decision it was derived from, so no determination binds long enough to propagate. More polishing cannot repair that loop. Define the exit criteria in visionary mode before execution begins: "the reality is anything existing is far better than cogitating and not outputting."

[Container design](/wiki/container-design) maintains this boundary through the environment, keeping a person in one mode. [Commitment](/wiki/commitment) concerns the cost of allowing the decision to bind.

## Atoms vs Chemistry: The Mis-Ordering You Feel as Being Stuck

The opposite mistake is continuing to improve something already settled. Will calls this working at the level of atoms:

> "You get lost when you're stuck at the level of atoms — iterating on the 'best and most elegant' version of a thing that's already a settled primitive. ... Beating the atom to death. The real value is one level up: the CHEMISTRY. Atoms are boring and settled. Chemistry is emergent, combinatorial, where novelty lives."

A settled primitive has already resolved the choices other work depended on. Further polishing extracts nothing from those closed degrees of freedom. The open decisions concern how the primitives combine, one level up in [composition](/wiki/composition) and [systems emergence](/wiki/systems-emergence).

This produces a particular stuckness: design paralysis with a depressive tint. The response is to check the level at which the work is happening:

> "Engineering at the atom level is a bet that cleverness scales; engineering at the chemistry level (ensembles, compositions, macrostates) is a bet that variance + compute scales. Bitter lesson says the second wins. When stuck/depressed on a design problem, check: am I designing an atom or designing chemistry? If atom — stop, let it emerge, work one level up."

Anxiety and atom-grinding identify different mistakes. Anxiety signals an open layer above the one being edited. Atom-grinding signals that the current layer is already closed. Both require moving to the layer where consequential choices remain, which is a question of [execution resolution](/wiki/execution-resolution).

## Why the Wrong Order Feels Right

Three energetic incentives favor the reversed order.

First, derived artifacts are cheaper to begin. Narration can be written in an evening; choosing the concept requires confronting what the piece should be. The [activation-energy](/wiki/activation-energy) gradient points backward through the dependency chain. Left to that gradient, the annotation is always produced first because it is the easiest start.

Second, words create the sensation of thinking. A concept, product or argument may still be pre-verbal. Serializing it requires resolving something amorphous. The derived layer already consists of language, so sentences can accumulate pleasantly while the determining variable remains untouched. This supplies the incentive behind type confusion.

Third, deciding excludes alternatives. Leaving the concept open preserves optionality and feels prudent. Once dependent work has been committed, however, that optionality keeps the work unstable. Refusing to choose is comfortable at the moment and costly during every subsequent hour.

Correct ordering therefore has to be installed as a protocol. It will not be selected by feel, which favors cheap starts and preserved options. [Prevention architecture](/wiki/prevention-architecture) makes the same design move: do not leave a recurring decision to immediate judgment when the gradient opposes the intended action.

### The Quick Diagnostic

- If versions multiply and edits generate more edits, inspect upstream dependencies and fix the first open one.
- If a primitive is being polished and nothing is waiting on that improvement, move up to its combinations.
- If the specification exists only in a conversation or a feeling, create a dated lock event so it can bind.
- If a delegate finishes the task but misses the intended result, add verified checkpoints at the places where the specification still permits divergent interpretations.

## Specification Entropy: Determination Under Delegation

Delegating to a person or agent hands over detailed exploration while retaining control of the intended result. Will describes work as "it's usually a computation with exploratory depth, i almost see it as branching in little operations in state/action space, but at a certain level it is opaque to us or we can design it as opaque to us." What matters is "fundamentally it's about delivering what you want (read ur mind, make progress that u can easily verify and that accumulates)."

A specification is a lossy encoding of intent. Whatever it leaves unresolved is filled by the recipient's priors, and those assumptions compound through subsequent work. **Specification entropy** is the ambiguity remaining after transmission.

Checkpoints should follow that remaining ambiguity rather than the calendar or task size:

| Remaining ambiguity | Checkpoint cadence | Reason |
|---------------------|-------------------|-----|
| High: intent is barely encoded | Frequent, small verified gates | Each gate fixes ground truth for the work that follows |
| Medium: shape is agreed, details remain open | Structural milestones | The agreed shape bounds drift |
| Low: specification is nearly executable | End-to-end acceptance | Detailed checking adds work after the determining choices have propagated |

Each verified checkpoint reduces the remaining freedom and constrains the next stage. This is the video's refinement chain applied to people or agents: verify each level before deriving the next so error cannot propagate upward. It is the transmission-side counterpart of [information architecture](/wiki/information-architecture). A task can be technically complete and substantively wrong when checkpoints follow elapsed time rather than unresolved meaning.

There is also a cognitive prerequisite. A vague thought is a pointer to content, not the content itself: "understanding = successful serialization of a compressed thought into explicit manipulable symbols." A large determination must first be divided into pieces that fit [working memory](/wiki/working-memory) through [discretization](/wiki/discretization). A feeling of knowing binds nothing. If the thought cannot survive being written down, it was recognized but not determined.

## Failure Modes

| Failure mode | Mechanism | Signature | Repair |
|--------------|-----------|-----------|-----|
| Narration-first | A constrained artifact is asked to determine a freer one | Drift and failed synchronization | Re-author from the highest open layer |
| Type confusion | Similar surfaces conceal different determining roles | Annotation feels like the executable | Ask what each artifact determines and what determines it |
| Perfectionism | Validation lacks exit criteria | Every result reopens its premise | Lock the specification and define exit criteria before execution |
| Atom-grinding | Work continues on a settled layer | Paralysis over a primitive's elegance | Move to its combinations |
| Premature downstream commitment | Derived artifacts are fixed while their source remains open | [Anxiety](/wiki/anxiety) proportional to the unresolved upstream choices | Fix the source of the requirements |
| Lossy delegation | The recipient fills specification gaps with prior assumptions | “That's not what I meant” at completion | Verify at a cadence set by remaining ambiguity |
| Fan-out before selector | Branches lack a fixed common criterion | Candidates accumulate without a way to merge them | Fix the taste lockfile before generating |

## The Protocol

1. **List the representations.** Include every artifact the process will produce: concept, specification, structure, surface and annotation.
2. **Rank their freedom to vary.** The artifact with the most possibilities is upstream, regardless of what feels easiest or what material it uses. Two pieces of prose may sit at opposite ends of the chain.
3. **Determine each layer before deriving the next.** Each supplies the macrostate for the one below.
4. **Lock decisions at mode boundaries.** Date the artifact or create another explicit lock event. Executor mode reads that version without editing its premises.
5. **Trace anxiety upward.** Stop revising an unstable artifact and find the first open dependency that determines it.
6. **Check stuckness for a closed layer.** If polishing a primitive no longer determines other work, move up to composition.
7. **Set delegation checkpoints by ambiguity.** Each verified gate becomes ground truth for the work that follows.

## Integration with the Mechanistic Framework

### Connection to [Branching and Convergence](/wiki/branching-and-convergence)

A common upstream decision makes parallel branches mergeable. It must exist before they diverge. With that target fixed, convergence becomes a mechanical collapse; without it, fan-out produces incompatible variance.

### Connection to [Macrostate Engineering](/wiki/macrostate-engineering)

The macrostate is the determining representation with the most freedom. "Each level is the macrostate of the one below it" applies macrostate engineering recursively. Committing to a macrostate rather than a recomputable plan applies the same ordering to time.

### Connection to [Selection over Design](/wiki/selection-over-design)

The taste lockfile fixes the selector before sampling begins. Otherwise, the generator produces candidates for which no settled judgment exists.

### Connection to [Container Design](/wiki/container-design)

A container maintains the visionary/executor boundary through its environment. It holds execution to the fixed specification instead of allowing every result to reopen it.

### Connection to [Anxiety](/wiki/anxiety)

In work with multiple representations, anxiety is a sensor reading proportional to the upstream choices left open above committed work. The response is to settle those choices rather than manage the feeling independently of its cause.

## See Also

- [Branching and Convergence](/wiki/branching-and-convergence) explains why a shared determination makes branches mergeable.
- [Macrostate Engineering](/wiki/macrostate-engineering) fixes the governing state rather than a revisable plan.
- [Selection over Design](/wiki/selection-over-design) places the taste lockfile before generation.
- [Container Design](/wiki/container-design) maintains the boundary between deciding and executing.
- [Anxiety](/wiki/anxiety) supplies the general sensor applied here to dependencies.
- [Information Architecture](/wiki/information-architecture) structures determinations for transmission without loss.
- [Execution Resolution](/wiki/execution-resolution) identifies the appropriate level for work.
- [Composition](/wiki/composition) combines settled primitives where choices remain open.
- [Working Memory](/wiki/working-memory) limits the size of what can be held and determined.
- [Discretization](/wiki/discretization) divides large determinations into manageable pieces.
- [Commitment](/wiki/commitment) explains what allowing a decision to bind costs.
- [Activation Energy](/wiki/activation-energy) explains why the reversed order is easier to begin.
- [Communication Framework](/wiki/communication-framework) treats the induced mental model as executable and words as annotation.
- [Prevention Architecture](/wiki/prevention-architecture) installs the protocol against the immediate gradient.
- [Systems Emergence](/wiki/systems-emergence) describes the combinations that settled primitives make possible.