order-of-determinationcore-frameworksystem-design

Order of Determination

What It Is

Order of determination is the rule for sequencing work in any process that involves multiple representations of the same thing: pin down the representation with the most degrees of freedom first, and let lower-freedom representations be determined against it. A film has a concept, a visual track, and a narration track. A software project has a spec and a codebase. A fundraise has a product and a pitch deck. In each pair, one artifact has vastly more ways it could be — more degrees of freedom — and one is comparatively cheap to derive once the other is fixed. If you author the constrained artifact first and try to derive the free one from it, the process does not merely become harder. It becomes structurally impossible to converge, because you are asking a low-dimensional object to determine a high-dimensional one.

In computational terms: every creative process is a constraint-satisfaction problem across a stack of representations. Each representation is a variable with some dimensionality. Constraint propagation only works downhill — a high-dimensional assignment constrains a low-dimensional one to near-uniqueness, but a low-dimensional assignment leaves a high-dimensional one almost entirely unconstrained, vaguely implied rather than determined. Determination order is therefore not a stylistic preference. It is the difference between a system that converges and a system that drifts.

The principle carries a diagnostic that makes it operationally valuable far beyond media production: anxiety about downstream work is a signal that an upstream representation was never pinned. When the work in front of you feels unstable — every version feels wrong, every edit spawns three more — the problem is almost never at the layer you are editing. Something upstream, with more degrees of freedom, is still open, and everything below it is fluttering in its wind.

Authoring order is not a workflow preference. It is causality, applied to representations.

The Canonical Case: Visuals Before Narration

Will derived the principle from video work, where the failure mode is unusually visible. A narrated explainer has two tracks: the visual track and the voiceover. The visual track has enormously more degrees of freedom — layout, motion, timing, composition, what appears when, what the eye is looking at during each word. The narration is a linear string of sentences. The naive workflow is to write the narration first (it is made of words, and words feel like thinking) and then "add visuals." The result is always the same: animation bolted onto prose, nothing landing on anything, a track that reads as floating and dead.

"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."

Why narration-first cannot be rescued by effort:

  1. The narration underdetermines the visuals. A sentence like "the system routes attention" is compatible with thousands of screens. Whichever one you pick is not implied by the words; it is guessed.
  2. The guess must sync anyway. The key visual has to land on the key word. But the words were timed to nothing — they were written in a vacuum, so there is no beat for the visual to land on.
  3. Every fix destabilizes the other track. Re-cut the animation and the words float; rewrite the words and the animation is now timed to different sentences. The two low-level artifacts negotiate with each other forever because neither is upstream of the other.
  4. The only stable configuration is top-down. Decide the concept flow, author the visuals to it, write narration to what is on screen, then synthesize audio. Each step is cheap because the previous step determined it.

The correct authoring order is a refinement chain, each level fully determined before the next begins:

StageArtifactDegrees of freedomRole in the chain
1Concept flowHighest — what the piece is even aboutThe macrostate of everything below
2BeatsHigh — atomic units of meaning, their orderIntermediate representation
3Scenes / visualsMedium — what is actually on screenThe codegen target
4NarrationLow — words describing what is on screenAnnotation of the executable
5AudioLowest — synthesis of fixed wordsRendering

"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 analogy is exact, not decorative. Nobody writes the comments first and derives the program from them. Yet narration-first video production is precisely that — and it feels natural because of a bug described in the next section.

The last clause of the compiler quote generalizes beyond video: the executable is whatever actually runs in the receiver's head. In an explainer, that is the visual track. In a conversation, it is the mental model your words induce, not the words themselves — the words are annotations on a model you must design first. This is why explanations authored sentence-first so often transmit nothing: the speaker determined the annotation and left the model, the high-freedom artifact, to be vaguely implied. The communication framework is downstream of the same law.

Case Study: From Bug to Law in Three Weeks

The principle has a datable derivation, and the speed of its generalization is itself evidence of how load-bearing it is.

June 8. A general observation surfaces while debugging advice: "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." Upstream/downstream exists as an intuition, not yet a law.

June 10, morning. The video pipeline forces the mechanism into the open. Working out why visuals-first is the only order that converges, Will derives constraint ordering explicitly — "specify representations in decreasing order of degrees of freedom" — along with the refinement chain, the compiler analogy, and the type-confusion bug, all in one sitting.

June 10, same day. The retroactive test. With the mechanism named, months of fundraising anxiety re-parse instantly: deck, valuation, and cap were committed downstream while "who is this for" floated upstream, and the anxiety had been proportional to that open freedom the entire time. One derivation, two domains, same bug — the signature of a real mechanism rather than a domain trick.

June 23. The compression lands: "Focus on the things that determine other things. That decides the order. ... Felt like such a universal principle." What began as a video-production workflow note is now a prioritization law.

June 30. The scheduling corollary: "get it in early. Earlier decisions determine later ones — they either close or expand the possibility space." The principle now orders not just artifacts within a project but decisions within a life.

The trajectory — local bug, mechanism, retroactive explanation of an unrelated anxiety, universal law — is what it looks like when a principle is discovered rather than invented.

Type Confusion: Same Surface Form, Different Degrees of Freedom

Why does anyone order determination wrong, when the ordering is this mechanical? Because artifacts at different layers can share a surface form while differing enormously in dimensionality — and the shared surface form makes the constrained artifact masquerade as the determining one. As Will logged it: "the bug is a type confusion where two different artifacts share the same surface form."

The beat script and the voiceover are both inner-voice English. They look like the same kind of object. But one is a high-freedom specification of meaning (which the visuals must then satisfy) and the other is a low-freedom annotation (which must be written to the finished visuals). Confuse the types and you will write the annotation while believing you are writing the specification — then wonder why nothing downstream will settle.

Confused pairSurface form sharedActual typesCost of the confusion
Beat script vs voiceoverInner-voice EnglishSpec vs annotationSync-impossible video
Fundraising narrative vs productInner-voice languageAnnotation vs executablePitch polished around an undetermined product
Spec vs code commentsProse about the systemDetermining vs derivedCode that implements no decision
Plan vs commitmentA list of intentionsRecomputable vs bindingPlans mistaken for pinned state (see macrostate engineering)

The fundraising row is a real case, and it is where the principle proved it generalizes. Days after deriving the video rule, Will ran it retroactively against months of fundraising anxiety and found the identical structure: deck, valuation, and cap table — all downstream, low-freedom artifacts — were specified precisely, while "who is this for," the highest-freedom upstream representation, stayed open.

"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 narrative felt like the product because both are made of the same inner-voice sentences. So the annotation got polished while the executable stayed in superposition — and every deck revision felt wrong for reasons no deck revision could fix.

Anxiety as the Instrument

This gives anxiety a mechanistic reading in creative work. Downstream instability is not a temperament problem or a confidence problem; it is a dependency problem. You committed something derived while the thing it derives from is still a superposition. Every microstate of the open upstream variable implies a different correct version of the thing you already built, so the built thing can never feel right — it is being graded against a moving answer key.

The debugging move is always the same and always feels like going backwards. "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 debugging walk:

  1. Name the artifact that feels unstable. The deck, the scene, the paragraph, the function.
  2. List what it is derived from. What upstream representations does its correctness depend on?
  3. Check each dependency's determination state. Is it pinned in a dated, locked artifact — or does it live as a feeling of knowing, a chat log, an "we'll figure that out"?
  4. The first open dependency is the bug. Stop editing downstream. Pin the open variable, even roughly. Watch the downstream versions stop multiplying.

And the prioritization heuristic falls out directly. Not "focus on the big stuff" — bigness is not the variable. The variable is determination:

"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."

Earlier decisions determine later ones — "they either close or expand the possibility space." So the leverage of a decision is measured by how many downstream degrees of freedom it removes, and the correct schedule is to spend your best attention where determination is highest, which is almost always earlier and more abstract than where the discomfort is felt.

Generalization: Every Creation Is a Determination Chain

DomainHigh-DOF representation (pin first)Low-DOF representation (derive)Narration-first failure mode
VideoConcept flow → visualsNarration → audioWords timed to nothing; visuals bolted on
SoftwareSpec / architectureCode, tests, commentsCode that encodes no decision; endless rewrites
FundraisingProduct and who it is forDeck, valuation, cap tablePolished pitch for an undetermined thing
AI fan-outThe taste lockfile (selection over design)Generated candidatesVolume of outputs with no selector; noise
WritingArgument structureSentences, styleBeautiful paragraphs about an unpinned claim
A dayThe day's macrostate (macrostate engineering)The hour-by-hour sequenceSchedule optimization while the mission floats

Three rows deserve emphasis.

Spec before code. With LLMs the spec has become the runnable prototype — "I don't need to turn my theory into code — I can just test it" — which strengthens the ordering rather than weakening it. The high-DOF artifact is now directly executable, so there is even less excuse to start downstream. Complex specs appreciate as models improve; complex code depreciates.

The taste lockfile before fan-out. Before you spawn a hundred parallel candidates, the selector must be pinned: "skill + golden set + mechanical verifier + rejection ledger, versioned as one unit — a lockfile for taste." Fan-out against an undetermined selector produces variance you have no way to collapse; "the system is my taste made executable" only works if taste was serialized first.

Determination order is merge order. Parallel work is only mergeable when the thing it merges into was determined before the branches diverged. Will's discovery from generating videos in parallel: "the real determinant is whether the thing can be MERGED from parallel results" — and mergeability is exactly downstream-derivability from a shared upstream pin. This is the load-bearing joint with branching and convergence: you may branch freely below any pinned layer, and you may never branch above it.

The Temporal Form: Early Choices Produce the Path

Apply the law to time and you get the scheduling theorem this article's June 30 entry compressed: a day is a determination chain, and the early slots are the upstream representations. An early choice does not improve the odds of later choices — it produces the path. Not probabilistically; structurally: the state after choice A is the input to choice B — different A, different B-decision entirely, different options on the table, different self doing the choosing. Early choices collapse some branches and instantiate others, so later decision points literally don't exist in the same form — the way the first moves of a game determine which games are still reachable.

Will stress-tested the claim against its own triviality:

"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."

Concretely: protein at 10am doesn't make a good dinner "more likely" — it removes the 9pm state where you are 80g short and the only resolving branch is a bad one. The gym at 8am doesn't inspire the day; "it constructs a day in which the person deciding about food is a gym person." Meanwhile the possibility space physically shrinks as the day runs: time, energy, willpower, and stomach capacity are consumed resources, so anything placed late must survive every earlier claim on them, while anything placed early faces no competition.

SlotFan-outWhat belongs there
MorningHigh — its output is input to everything downstreamThe state-producing, branch-collapsing choices: protein, gym contact, the day's macrostate
Late dayLow — nothing downstream left to determineTerminal choices: entertainment, admin

The morning is the high-fan-out register, and the rule falls out directly: sequence is leverage — schedule the options you definitely want as early as possible, because early slots have causal fan-out over everything downstream and late slots have none. "Priority without early placement is just sentiment." Distinguish this from its weak motivational cousin — "start your day right, momentum!" is the probabilistic version; ignore it and act on the branch-determination version. And the honest answer on obviousness: "they're obvious once u mention it but nobody ever acts about their consequences." Obvious ≠ priced-in; the alpha is in rebuilding the schedule around the consequences, not in knowing the fact. Early choices don't improve the day's odds — they decide which day exists.

Mode-Locking: Letting a Determination Bind

Pinning an upstream representation is only half the operation. The other half is letting the pin bind — treating the determination as fixed while you work downstream. This is hard because the mind that determines and the mind that derives are different modes with incompatible objective functions. In visionary mode, doubt is a feature: you are supposed to question everything, because everything is still free. In executor mode, the same doubt is catastrophic: it silently un-pins the upstream variable and returns you to the fluttering state.

"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 two modes need time separation and an enshrined artifact at the boundary. The spec cannot live in the stream — a journal, a chat, a rolling doc — because stream-resident determinations are perpetually renegotiable. It must be moved to a shrine: "ok so it should be enshrined."

PropertyStream (journal, chat, rolling doc)Shrine (enshrined spec)
MutabilityAlways editableLocked at a dated version
AuthorityCompetes with every newer thoughtAuthoritative until a deliberate re-determination
ModeVisionary — doubt welcomeRead by executor — doubt deferred
Effect on downstreamDownstream flutters with every entryDownstream derives against a fixed answer key

A lock event — closing the spec issue, dating the document, cutting the version — is what converts a thought into a determination. This is why tools like Linear matter beyond bookkeeping: they manufacture lock events.

This reframes perfectionism mechanically. Perfectionism is not high standards; it is a validation loop with no exit criteria — a refusal to let any determination bind. Every downstream result gets fed back as evidence against the upstream pin, the pin reopens, and the chain never propagates. The fix is not more effort at the layer being polished. It is defining exit criteria upstream, in visionary mode, before executor mode begins — because "the reality is anything existing is far better than cogitating and not outputting." See container design for the environmental version of the same move: containers hold you in one mode so the boundary between modes stays intact, and commitment for what a binding determination costs.

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

There is a second characteristic mis-ordering, and it runs in the opposite direction: continuing to iterate on a layer that is already determined. Will calls it 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."

In determination terms: a settled primitive has had its degrees of freedom spent. Polishing it further extracts nothing, because nothing downstream is waiting on it — the determination already propagated. Meanwhile the genuinely open degrees of freedom sit one level up, in how the settled pieces compose (composition, systems emergence). The subjective signature of this mis-ordering is a specific flavor of stuckness — design paralysis with a depressive tint — and it has a checklist response:

"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."

Both mis-orderings are failures of the same instrument: working at a layer whose determination state you have misread. Anxiety says a layer above you is still open. Atom-grinding stuckness says the layer you are on is already closed. In both cases the fix is vertical, not horizontal — move to the layer where degrees of freedom actually remain, which is a question of execution resolution.

Why the Wrong Order Feels Right

If the ordering is mechanical, why is the violation the default behavior — not just for Will, but for essentially everyone who has ever written a script before storyboarding it? Three forces conspire, and all three are energetic rather than logical:

  1. Low-DOF artifacts are cheap to produce, so they get produced first. Writing narration is an evening; deciding a concept flow is a confrontation. The activation energy gradient points exactly backwards along the determination chain — the artifacts that should come last are the easiest to start. Left to thermodynamics, you will always author the annotation first, because the annotation is downhill.

  2. Words feel like thinking. The high-DOF layers (concept, product, argument) are usually pre-verbal, and pinning them means dragging something amorphous through serialization. The low-DOF layers are already made of language. So producing them generates the sensation of intellectual progress — sentences accumulating — while the actual open variable sits untouched. This is the type confusion's energy source: the annotation is not just disguised as the executable, it is more pleasant to write.

  3. Pinning upstream means accepting a loss. A determined concept excludes every other concept. Keeping the upstream open preserves optionality, and the preservation feels prudent — but optionality upstream of committed work is precisely the anxiety generator. You are not keeping your options open; you are keeping your downstream unstable. The refusal to determine is comfortable at the moment of refusal and expensive every hour afterward.

The practical consequence: correct determination order must be installed as protocol, because it will never be selected by feel. The feel optimizes for cheap starts and preserved optionality; the protocol optimizes for convergence. This is the same structural argument as prevention architecture — do not rely on in-the-moment judgment where the gradient opposes you.

The Quick Diagnostic

When any project feels wrong, run four questions in order:

  • Is something downstream fluttering? (Versions multiplying, edits spawning edits, nothing feels right.) → An upstream variable is open. Walk up and pin it.
  • Is something being polished that nothing waits on? (Elegance-grinding, atom-level iteration.) → The layer is settled. Move up to chemistry.
  • Is a determination living in the stream? (The "spec" is a chat log or a feeling.) → It binds nothing. Enshrine it with a lock event.
  • Is a delegate drifting? (Output technically done, substantively wrong.) → Specification entropy was higher than the checkpoint cadence assumed. Add verified gates.

Specification Entropy: Determination Under Delegation

Order of determination governs delegation too — to people and to agents. Work itself is opaque computation. In Will's phrasing: "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." Delegation means handing the microstate exploration to another process while you hold the determination — "fundamentally it's about delivering what you want (read ur mind, make progress that u can easily verify and that accumulates)."

The failure mode is that a spec is a lossy encoding of intent. The prompt never contains the whole determination; the receiving process fills the gap with its own priors, and the gap compounds silently. Call the gap specification entropy: the ambiguity remaining after the spec is transmitted. The operational rule is to scale checkpoint frequency with remaining entropy, not with elapsed time or task size:

Remaining ambiguityCheckpoint cadenceWhy
High (intent barely encoded)Very frequent, small verified gatesEach verified gate becomes ground truth constraining downstream work
Medium (shape agreed, details open)At structural milestonesDrift is bounded by the agreed shape
Low (spec near-executable)End-to-end acceptance onlyThe determination already propagated; checking microstates is waste

Multi-agent and multi-person systems win through progressive entropy reduction — each checkpoint converts a stretch of open freedom into pinned ground truth, exactly the refinement chain from the video case, applied socially. Each level of the chain is verified before the next derives from it, so error cannot propagate upward. This is the transmission-side counterpart of information architecture, and it explains a common delegation mystery: the task was "done" and yet wrong, because verification cadence was set by the calendar instead of by the entropy remaining in the spec.

There is also a cognitive floor under all of this: you cannot pin a representation you cannot hold. A vague thought is a pointer, not dereferenced content — "understanding = successful serialization of a compressed thought into explicit manipulable symbols." Big determinations must first be decomposed into pieces that fit working memory (discretization), because a determination that only exists as a feeling of knowing binds nothing. If it cannot survive being written down, it was recognized, not determined.

Failure Modes

Failure modeMechanismSignatureFix
Narration-firstDeriving high-DOF from low-DOFDownstream drift; nothing syncsRe-author top-down from the highest open layer
Type confusionShared surface form hides DOF differenceThe annotation feels like the executableAsk of each artifact: what does this determine, and what determines it?
PerfectionismValidation loop with no exit criteriaUpstream pin silently reopens on every downstream resultEnshrine the spec; define exit criteria before executor mode
Atom-grindingIterating on a settled layerStuck/depressed on "elegance" of a primitiveMove one layer up to chemistry
Premature downstream commitmentPinning derived artifacts while upstream floatsAnxiety proportional to open upstream DOFFix the upstream first; the downstream complaint is a symptom
Lossy delegationSpec entropy filled by the delegate's priors"That's not what I meant" at the endCheckpoint by remaining ambiguity; verified gates as ground truth
Fan-out before selectorBranching above an unpinned layerUnmergeable candidates piling upPin the taste lockfile, then generate

The Protocol

  1. Enumerate the representations. For whatever you are making, list every artifact the process will produce: concept, spec, structure, surface, annotation.
  2. Rank by degrees of freedom. Which artifact could vary in the most ways? That one is upstream, whatever order feels natural. Distrust the surface form — two artifacts made of the same material (words, sketches, prose) can sit at opposite ends of the chain.
  3. Pin top-down. Fully determine each layer before deriving the next. Each level is the macrostate of the one below it.
  4. Enshrine at mode boundaries. When a determination is made, lock it in a dated artifact. Executor mode reads the shrine; it does not edit it. Manufacture a lock event.
  5. Use anxiety as the probe. When downstream work feels unstable, stop editing it. Run the debugging walk: walk up the chain until you find the open variable. Pin it.
  6. Use stuckness as the other probe. When you are grinding on elegance, check whether the layer is already settled. If so, move up one.
  7. Delegate by entropy. Checkpoint at a frequency set by remaining ambiguity, and treat each verified gate as ground truth constraining everything downstream of it.

Integration with the Mechanistic Framework

Connection to Branching and Convergence

Determination order is merge order. Parallel branches are only convergeable if the thing they merge into — the upstream pin — existed before they diverged. Fan-out before determination produces unmergeable variance; determination before fan-out makes convergence a mechanical collapse.

Connection to Macrostate Engineering

The macrostate is the highest-DOF pin. "Each level is the macrostate of the one below it" — the entire refinement chain is macrostate engineering applied recursively, and committing to macrostates rather than plans is order of determination applied to time.

Connection to Selection over Design

Selection systems obey the ordering too: the selector (the taste lockfile) must be determined before the generator runs, or generation produces candidates no one can judge. Pinning taste is upstream of sampling.

Connection to Container Design

Containers enforce the visionary/executor boundary environmentally. A well-designed container mode-locks you into deriving against the enshrined spec instead of reopening it.

Connection to Anxiety

This article gives anxiety its structural reading in creative work: not a state to manage but a sensor reading, proportional to unconstrained upstream degrees of freedom above committed downstream work.

See Also


Core Principle: In any process with multiple representations, pin the representation with the most degrees of freedom first and derive the rest against it — concept before visuals, visuals before narration, spec before code, selector before fan-out. Mis-ordering is usually a type confusion: two artifacts share a surface form, so the annotation masquerades as the executable. Anxiety in downstream work is the instrument reading — it is proportional to the unconstrained degrees of freedom left open upstream of what you already committed. Fix the upstream first; the downstream complaint is always the symptom.


Focus on the things that determine other things. Everything else is narration.