The Precondition Trap

What It Is

A task can disappear behind the system that was supposed to make it possible. 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. Each day produces visible work on a prerequisite, while the intended act never happens.

The precondition trap begins when "I need to build the [system/pipeline/platform] before I can start" replaces the demand to act. Building the enabling layer, or merely promising to build it, relieves that demand. The absence of the intended result does not register as failure because progress on the prerequisite is being counted instead.

In computational terms, act A is redirected into building an enabler E(A). That enabler can require another enabler, producing recursion with no base case. Nothing defines the point at which "now I can start" becomes true. The process optimizes relief from the demand rather than execution, and designing the enabler supplies that relief immediately.

Planning euphoria explains why this substitution feels rewarding: the energy available for execution is spent on design. The precondition trap describes the resulting arrangement, in which the work being built keeps the intended act one prerequisite away.

A closer look

An act displaced by its prerequisites

The tripwire is whether the original act ever runs. The article recommends letting operated instances reveal which tools are actually needed.

Read this diagram

The intended act → A required tool → That tool's prerequisite → Another enabling layer.

The Tell-Sentence, Caught Live

Will recorded the reasoning while it was happening:

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

The accrual substrate diagnosis is valid: work needs a place where results can persist and change. The error is using that diagnosis to conclude that today's task cannot happen until a new structure exists.

The observation came from the same day as the planning-euphoria example in which thirty issues were enumerated and none was executed. Planning consumed the available motivation, while the prerequisite supplied a reason that the planned work still could not begin.

A month later, Will described the trigger:

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

Anxiety or a sense of being an impostor can initiate the proposed build before any recurring operational need has appeared. Saying "I'll build a system for it" relieves the feeling. The promise can supply enough relief that the proposed system is never built either. In that case, even the enabling layer remains only an answer to the anxiety.

The Trap Shape: Why It Never Halts

Building a platform provides daily visible progress in an environment the builder controls. Sending outreach, publishing a piece, or doing a repetition exposes the work to results outside that control. A stranger can remain silent, respond on their own schedule, or say no. The difference makes the prerequisite more rewarding to work on than the act it displaces.

The audience differs too. An imagined investor, professor, or future self can admire the structure, while revenue and completed repetitions require a response from the market or the work itself. Without an operational definition of "ready," there is no event that requires the builder to stop preparing. An unused platform also cannot be shown wrong through use, whereas a delivered artifact can fail today.

At craft scale, taste compilation describes the same problem. A pipeline designed before making the work records an imagined process. Its mistakes become part of the machinery before the builder has the examples needed to recognize them.

The startup-isolation account in reality contact followed this sequence for eighteen months. Sophisticated platform work continued under the explanation "building the platform first, then we'll get users." The first week of customer conversations collapsed the model. Eighteen months of visible development had preceded the first performance of the act it was meant to enable.

Pulled vs Pushed

The relevant distinction is what initiates a system 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 starts with work that has happened. Someone performs the task manually, performs it again, and discovers a recurring demand for tooling. The specification can then describe what the work actually required.

A pushed system starts before those instances exist. Its specification predicts what future work will need, so it has no completed attempt against which to check that prediction. Hand-making the first instance by the fastest available path exposes the missing pieces. A second instance establishes whether a shared schema recurs.

That order applies at portfolio scale as well:

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

The common structure has to be discovered across concrete instances. Designing it before those instances exist invents the framework first, which repeats the trap. Taste compilation's instruction, "do the work once, by hand, badly," makes the first artifact a requirements document for later tooling.

A Platform Is a Compression of Operated Instances

A platform preserves what is shared across instances that have already been operated. With zero completed instances, there is nothing observed to compress:

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

This still leaves a substantial role for frameworks, platforms, and factories. A functioning business demonstrates a form that can be decomposed into reusable modules. Those modules can become a template, and a factory that reliably creates further instances can provide a real competitive moat.

The condition is that the general structure descends from something that ran. A useful platform's features have actual repetitions behind them, so each feature can be traced to a demand encountered in the work.

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

Committing to an outcome and running the contact loops by hand supplies the information from which the tooling can form. The resulting vessel records what reality required. A vessel designed first and justified afterward cannot provide that same provenance for its features.

The Boundary: This Is Not an Argument Against Substrates

Accrual substrate recommends establishing a place to retain work early. That can sound like another prerequisite, but a simple capture surface can be created inside the task rather than displacing it. The distinction matters because the record includes both years spent building vessels for outcomes that never arrived and years of effort lost because there was nowhere for it to accumulate.

An append-only file, log, or list qualifies as a substrate when an entry can be added in under ten seconds without deciding on a schema. Its first entry arrives in the same hour it is created, prompted by something that already needs to be captured. It has immediate use within today's work.

A build project has a roadmap and a completion date after which the real work is supposed to begin. Anxiety about repetitions that have not happened supplies its demand. Cost, timing, and blocking distinguish the cases:

A capture surface costs minutes rather than days. If the proposed prerequisite costs more than performing the task once by hand, it is replacing the task.
The first use happens in the same session. A present repetition pulls the substrate into existence; a platform's promised first use remains in the future.
The act can proceed while the surface is created. A repetition can be recorded on paper. "I can't start until it exists" describes a blocking project rather than a substrate.

A person can therefore perform the task today and capture it on the cheapest available surface. Repetition can later justify more structure without forcing a choice between elaborate preparation and losing the result.

The Tripwire Protocol

The statement that a system must exist before work can start triggers a concrete response:

One manual instance happens today. Paper, a raw email, or a bare file provides a surface for it. The instance is available now and supplies the requirements that speculation cannot.
Any needed capture goes into a file in the same session. An append that takes ten seconds and requires no schema satisfies the legitimate need to retain the work.
The second repetition for a real demand authorizes a system build. Recurrence supplies the reason for construction; a feeling about future work does not.
The urge to build is itself recorded. Anxiety proposing a system is information about the anxiety. Recording the impulse gives that information somewhere to accumulate without treating it as a tooling specification.

Integration with the Mechanistic Framework

Connection to Reality Contact

"I need to lose 10 pounds before joining the gym" and "building the platform first" both put a condition between a person and an available act. Reality Contact places these narratives among the ways to remain in simulation. The precondition trap explains why each condition can produce another without reaching a stopping point.

Connection to Planning Euphoria

Designing an enabler is a planning activity. If its reward arrives during design, the motivation is spent before the intended act can use it. The visible prerequisite can therefore keep growing while the work it was meant to support remains undone.

Connection to The Accrual Substrate

A capture surface takes seconds, receives an entry from current work, and does not prevent that work from happening. A build project can use the language of accumulation while delaying the first use indefinitely. The same-session entry distinguishes the legitimate first move from the substitution.

Connection to Taste Compilation

Making a first artifact by hand exposes the process that a production pipeline will need to support. Building the pipeline before making any artifacts commits to a process whose requirements have not yet been encountered.

Connection to Procrastination

In procrastination, the launch script fails to load. In the precondition trap, the person occupies the work session with an enabler-building script that avoids the intended launch. The second case can look productive because a different artifact is receiving work.

Connection to Structure over Request and Generative vs Retrospective

Structure determines output quality, which makes it a persuasive justification for a premature build. The constraint concerns where that structure comes from. Retrospective extraction uses operated instances to discover the common form; generating the form ahead of the instances supplies no such evidence.