precondition-trapdebugging-methodologypractical-application

The Precondition Trap

What It Is

The precondition trap is discharging an execution demand by building — or promising — the enabling layer instead of doing the act. The tell-sentence is always some form of "I need to build the [system/pipeline/platform] before I can start," and the defining property is that the container is always one layer of tooling away: when the system is half-built, it turns out to need a schema; the schema needs a data model; the data model needs a rethink of the whole architecture. The act the structure was supposed to enable never runs, and the not-running never registers as failure, because every day produced visible progress on the prerequisite.

In computational terms: a demand for act A is rerouted into constructing an enabler E(A), whose completion is claimed as a precondition for A. Since enablers can themselves require enablers, the recursion has no base case, and the halt condition — "now I can start" — never fires, because starting was never the objective function being optimized. The optimization target was relief from the demand, and building E(A) delivers that relief immediately. This page owns the substitution topology: what gets built instead of the act. Why the substitution feels like progress is owned by its sibling, planning euphoria — the energy that funds the enabler-build is the same charge that execution needed, discharged into design.

The Tell-Sentence, Caught Live

The trap is easiest to see in Will's own captures, because both the reasoning and the later diagnosis are on record. The reasoning, from inside the trap:

"the reason why I can't work is because nothing is accruing and nothing is accruing because I haven't written it down in a place where it can change"

This sentence is worth slowing down on, because it is almost right — the accrual diagnosis is real, as the accrual substrate article establishes at length. What makes it a trap-sentence is its position: it is offered as the reason work cannot happen now, which converts a true observation about substrates into a precondition for the day's task. (It was captured on the same day as planning euphoria's type specimen — thirty issues enumerated, zero executed. The two mechanisms fired together: the charge discharged into planning, and the residue rationalized into a prerequisite.)

The diagnosis, arriving a month later:

"whenever something appears to have anxiety or imposter syndrome... i'll build systems for it. and i think that can be cope if i don't actually build the systems"

This names the input side of the machine. The trigger for a system-build is not a recurring operational need — it is a feeling. Anxiety arrives, and "I'll build a system for it" discharges the anxiety the way an answer discharges a question. The honest kicker is that the systems often don't even get built; the promise alone was enough, because the promise was the product.

The Trap Shape: Why It Never Halts

The enabler-build is not just a detour — it is a structurally better environment than the work it displaces, which is why the detour is stable. Platform work pays daily, visible progress inside an environment you fully control. The displaced act — sending the outreach, publishing the piece, doing the rep — pays in silence from strangers, on their schedule, with real odds of a no. The trap runs on that gradient. It also optimizes for the wrong audience: the platform is legible to an imagined evaluator (an investor, a future self, a professor) while revenue and reps are legible only to the market. It has no halt condition, since "ready" is never operationally defined. And it is unfalsifiable while it runs: a platform cannot be wrong until it is used, whereas one shipped artifact can be wrong today. Taste compilation makes the same point at craft scale — the pipeline built before the reps encodes your fantasy of the process, and the badness gets baked in exactly where it is most expensive to see.

The flagship specimen is the one reality contact tells as its startup isolation example: eighteen months of sophisticated platform-building justified by the narrative "building the platform first, then we'll get users," followed by a first week of customer conversations that collapsed the model. Eighteen months of daily visible progress; zero days of the act the platform supposedly enabled.

Pulled vs Pushed

The trap has a clean discriminator, and it is temporal. The question is never whether to build systems — it is what event is allowed to trigger the build.

"Systems are pulled, not pushed: built after the second manual rep for a real customer, never before the first rep in response to a feeling. 'I'll build a system for it' said about an anxiety is the tell — do the task instead."

A pulled system is extracted from work that already happened: the rep ran by hand, it ran again, the repetition itself now demands the tooling, and the tooling's spec is simply a description of what the hands did. A pushed system is projected from work that hasn't happened, and its spec is a guess. The sequencing rule shows up independently wherever the trap costs the most. Hand-roll the first instance by the fastest path, and extract the shared abstraction only once a second instance proves the schema recurs — building the framework now is inventing the framework first, which is the trap itself. The platform should emerge from solving the real missing pieces encountered while making the first instance operational, not precede that struggle as a framework. And at portfolio scale:

"Do not build seven generalized systems in parallel. Use concrete instances to discover the shared body plan."

Each is the same law at a different scale: the concrete instance comes first, and the abstraction is discovered inside it, not designed ahead of it. The first artifact, made by hand and badly, is the requirements document — taste compilation's operating rule ("do the work once, by hand, badly") is this law applied to a single craft.

A Platform Is a Compression of Operated Instances

The positive definition that dissolves the trap: a platform is not a prerequisite for operating — it is a compression of instances that were already operated. Platformizing with zero completed instances means encoding structure no reality demanded.

"The keeper line: platformize what recurs; first something has to recur."

This also marks out the legitimate endpoint of systematization, so the trap-diagnosis doesn't overreach. A working, operated business is a proof-of-form that can be decomposed into reusable modules — not just a business but a template — and the factory that stamps out the next instances is a real moat. Nothing about the precondition trap forbids frameworks, platforms, or factories. It constrains their ancestry: everything general must descend from something that ran.

The deepest one-sentence statement of the reversal:

"Before, you built a vessel and searched for a reason it should exist. Now, you want an outcome, run contact loops, and let the vessel form around what reality requires."

The vessel forms around the outcome. Structure is precipitate, not prerequisite — you commit to the outcome, run the contact loops by hand, and the shape of the tooling condenses out of what those loops actually required. Every feature of a vessel built this way has a rep as its provenance, which is exactly what a pushed vessel can never have.

The Boundary: This Is Not an Argument Against Substrates

The accrual substrate article teaches a first move that sounds like this trap's tell-sentence: faced with any large problem, stand up the substrate first. The two laws are compatible, and the boundary between them is worth drawing precisely, because the record contains disasters on both sides — years of vessels built for outcomes that never arrived, and years of effort that evaporated because it had no surface to land on.

A substrate, in the accrual sense, is a ten-second append-only capture surface: a file, a log, a list. Its test is that you can write to it in under ten seconds with no schema decision, its first entry lands the same hour it is created, and it is pulled into existence by a capture that already wants somewhere to land. Standing one up is a move inside today's work, not a project that displaces it. A precondition-trap artifact is a build project: it has a roadmap, its completion date is when the real work may begin, and it is pushed by a feeling about reps that haven't happened. The discriminators, stated as checks:

Cost: minutes versus days. If the "prerequisite" costs more than doing the task once by hand, it is not a prerequisite — it is the substitute.
Direction: pulled by a rep that is happening today, versus pushed by anxiety about reps that aren't. The substrate's first write and the rep it captures occur in the same session; the platform's first use is always in the future.
Blocking: a substrate never blocks the act — you can do the rep on paper while the file is being created. The moment "I can't start until it exists" is asserted, the object being described is not a substrate.

This resolves the apparent double-bind. You never face a choice between building the vessel first and never starting: do the rep today, capture it on the cheapest surface that exists, and let recurrence pull the structure into being.

The Tripwire Protocol

The trap is caught at the tell-sentence, and the response is behavioral, not analytical:

Do the task once, by hand, today. On whatever surface exists — paper, a raw email, a bare file. The rep is the only object that can generate a true requirements document, and it is always available now.
If capture is genuinely needed, append to a file. Ten seconds, no schema, same session. This satisfies every legitimate accrual demand the tell-sentence smuggles in.
Grant the system a build slot only after the second rep for a real demand. The pulled-not-pushed rule, made mechanical: recurrence authorizes construction; feelings do not.
Log the urge itself. An anxiety that proposes a system is data about the anxiety, not a requirements document. Recording it converts the impulse into a capture — which is the one form of it that actually accrues.

Integration with the Mechanistic Framework

Connection to Reality Contact

The parent frame. Reality contact classifies precondition narratives ("I need to lose 10 pounds before joining the gym," "building the platform first") among its simulation stories and escape hatches; this page canonicalizes the shape they share and why the recursion never halts.

Connection to Planning Euphoria

The energy source. Designing the enabler is a planning act, and the sibling page explains why it pays: the motivational charge fires at design time and is gone before the act it displaced can claim it.

Connection to The Accrual Substrate

The boundary case. Substrate-first is a legitimate opening move because a substrate costs seconds, never blocks the rep, and is pulled by a capture; the trap wears substrate language while proposing a build project pushed by a feeling.

Connection to Taste Compilation

The craft-domain instance. Pipeline-before-reps is this trap inside a production process, and its resolution is the same: the first hand-made, bad artifact is the requirements document the pipeline must descend from.

Connection to Procrastination

The adjacent launch failure. Procrastination is the launch script failing to load; the precondition trap is a launch-avoidance script running in productive clothing — the work state is occupied, but by the enabler.

Connection to Structure over Request and Generative vs Retrospective

Structure-over-request establishes that structure determines output quality — which is true, and is the trap's favorite justification; the constraint this page adds is that legitimate structure is extracted retrospectively from operated instances, never generated ahead of them.