In "Formalise the Road," I made the case that structured specifications produce exponentially better outcomes than prose. The argument holds. But it was scoped to the mechanism, to what formalisation does for the system downstream. It did not ask what formalisation does to the intent itself. That turns out to be the more consequential question. Because no one begins by formalising. Everyone begins with intent. And intent, when you try to make it precise, does not hold still.
Have you ever sat down to write something and discovered, mid-sentence, that you didn’t know what you thought until you wrote it?
The writing was not transcribing a thought that already existed in complete form. The writing was the thinking. The sentence, once written, showed you something about what you meant that you could not have seen before you began. You revised. The revision showed you something else. By the end, you had not expressed an intent. You had constructed one.
Intent is a disposition. A partially formed, context-sensitive orientation toward an outcome that becomes more determinate through the act of expression, the resistance of the medium, and the responses of the people involved. It is not the ghost in the machine- the immaterial, fully-formed thought driving behaviour from behind the scenes. Gilbert Ryle spent a career dismantling that picture. The ghost was never fully formed. It takes shape through the attempt to express it.
This matters enormously when the entity receiving your expression is not a collaborator who pushes back, but AI that resolves your incompleteness silently, fills every gap with its most probable answer, and builds from the result. The act of building software with AI has quietly removed the rehearsal from the process. And the rehearsal, it turns out, was where intent was constructed.
A language model assigns probabilities to what comes next. More data extends the range of what it has seen. A larger model stores finer-grained patterns within that range. The nature of the function does not change.
The problem this creates is not about coverage. It is about representation.
A probability distribution has no mechanism for encoding unresolvedness as a first-class object. When someone describes what they want to build, the description may not be a poor encoding of a clear intent. It may be an accurate expression of an intent that is genuinely unresolved, because the decisions that would resolve it have not yet been made. But the model cannot output “this intent is unresolved.” It can only output the most probable completion. The architecture forces resolution where none exists. Unresolvedness is not surfaced but papered over with confidence, and that confidence is the most dangerous thing about it, because it looks exactly like understanding.
More scale does not change this. Doubling the training corpus extends coverage. It does not give the distribution the capacity to distinguish between “this is resolved” and “this has not been decided yet.”
In molecular biology, function follows from structure. A protein is a chain of amino acids, but the chain does nothing until it folds. The three-dimensional shape of the folded protein determines what it binds to, what it catalyzes, what signals it transmits. Change the fold, and you change the function. The amino acid sequence is the same. The behaviour is entirely different.
I see a parallel to this model in what a specification template does to intent.
Templates sound static and dead but they are an abstraction of experience. Let’s consider the process of order fulfilment. Someone has studied how order fulfilment actually works across warehouses and logistics networks, how inventory states change, how handoffs between teams succeed and fail, how exceptions propagate through a pipeline. They have watched these processes run, watched them break, and identified the structural elements that recur: the states an order can be in, the roles that act on it, the rules that govern transitions, the handoffs that connect one decision to the next. The template encodes that experience into a reusable shape. It is not a theory about how fulfilment should work. It is a compression of how it does work, distilled into a structure that new teams can inhabit.
But the template is still generic. It carries the standard states, knows the common transitions and the roles that typically act on them. That is the value of abstraction. What the template does not know is how this particular business deviates from the standard shape. Perishable goods that cannot be restocked on return. Subscription orders that cycle rather than terminate. Oversized items that skip the standard packing queue. High-value orders that require signature confirmation before the state changes to delivered.
The template provides the default. The PM’s product, catalog, and constraints are what force the deviations. And the deviations are where intent gets constructed.
A PM building an order fulfilment workflow does not need to invent the concept of a “shipped” state. The template already has it. What she needs to decide is what “shipped” means for a product that requires cold-chain logistics versus one that does not. Whether “returned” routes to restocking or disposal depending on product type. Whether “confirmed” triggers packing immediately or waits for payment clearance on orders above a threshold. The template surfaces these questions by providing the standard process against which her specific case pushes back.
Structure determines behaviour. In the cell, the fold of the protein determines what it does. In the specification, the shape of the template determines what decisions get made. The template does not record intent. It produces it. The scaffold, not the building
But structure alone is not enough. The decisions produced by structure may be inconsistent, incomplete, or contradictory. Intent now has form, but it does not yet have direction.
In the fourth century BCE, Pāṇini composed the Aṣṭādhyāyī, a grammar of Sanskrit in roughly four thousand sutras. Leonard Bloomfield later called it one of the greatest intellectual achievements ever produced.
Pāṇini worked with abstract variables over sound classes, defined context-sensitive rewrite rules, and used explicit markers for elements that guide derivation and then disappear. When Frits Staal analysed the system in the 1960s, he showed that it corresponds to a context-sensitive grammar in the Chomsky hierarchy. What Pāṇini achieved was a compression of an already disciplined linguistic practice into a system that made its structure explicit, reproducible, and portable.
But the grammar’s deepest contribution was not what it permitted. It was what it rejected. The grammar defined the boundary of well-formedness. Anything inside the boundary could be expressed. Anything outside it could not. The grammar did not tell you what to say. It told you what you could not say. And by constraining the space of possible expressions, it made the remaining choices sharper, more deliberate, more visible.
This is what verification does to a specification.
Verification is the grammar pass over structured intent. It checks whether references resolve, whether types are consistent, whether the contracts between components hold. It does not tell you what your system should do. It tells you what your system cannot do in its current form. A role references a permission that does not exist. An agent expects an input that its upstream source does not produce. A business rule triggers on a state that the entity state machine cannot reach.
These rejections are not failures. They are clarifications. Each one gives intent a direction it did not have before. The PM now knows that the return path has no restocking rule, that the refund trigger is undefined for partial shipments, that the delivery agent’s retry logic conflicts with the cancellation window. The specification is still unfinished. But it is unfinished in a way that points toward resolution.
Pāṇini’s grammar closes the syntactic gap. Verification closes the structural gap. Neither closes the semantic gap. They cannot tell you whether the well-formed, structurally valid specification is the one you meant. That requires something else.
A map of a city is geometrically precise. Every street is measured, every intersection placed correctly, every elevation contour verified against survey data. A delivery company uses the map to plan routes.
But a driver who knows the city looks at the planned route and says, “This road floods every monsoon season.”
The map is correct But the route is still wrong. The gap between the two is not something any amount of cartographic precision could have closed, because the knowledge lives outside the formal system. It lives in the experience of someone who has driven the road and knows what the map does not represent.
This is ratification.
The human encountering a verified specification is not asking “is this well-formed?” They are asking “is this what I meant?” These are fundamentally different questions. Verification checks whether the specification is internally consistent. Ratification checks whether the specification corresponds to the world it is meant to describe.
Ratification catches semantic wrongness: the plausible but incorrect representation that passes every structural check. And it resolves genuine indeterminacy: the moment when a gap surfaced by verification forces a decision that had not previously been made.
This is not error correction but construction. The intent entering ratification is less determinate than the one that leaves it. Each encounter with a formal representation forces the human to decide something they had deferred, to notice something they had assumed, to reject something that looked right but was not what they meant.
Ratification is not a review step bolted onto the end of a pipeline. It is the epistemically irreplaceable moment in the construction of intent. Every specification has roads that flood. The question is whether your process surfaces them before production does.
These three movements - structure, verification, ratification, are not theory. They describe what happens each time a specification passes through the cycle of formalisation. Let’s take a concrete example.
Consider a product manager building an order fulfilment workflow. She starts with a template to build AI agents. The template requires her to declare the agent’s inputs, outputs, handoff targets, and failure modes. She had a rough sense that a dispatch agent should “assign orders to delivery partners and track shipments.” But the template asks: what is the input type? What states can a shipment be in? What happens when a delivery attempt fails? How many retries before escalation? To which role? With what timeout?
Structure has forced decisions into existence. The PM now has a dispatch agent that takes a packed_order from the warehouse agent, assigns it to a delivery partner based on zone and capacity, and tracks three delivery states: in_transit, attempted, delivered. A failed attempt triggers reassignment after two hours.
This is when verification catches a structural gap: the reassignment node triggers after a failed delivery attempt, but no max_retries limit is defined. The order can loop between attempted and reassigned indefinitely. The specification is well-formed in every other respect, but this edge is open. The PM adds a max_retries of 3 with an onExhaust escalation to the Operations Lead. Verification has given intent a direction it lacked.
Now the PM looks at the compiled graph. Every node is typed. Every contract is satisfied. Every reference resolves. The specification is structurally complete.
But she sees the return path and says: this routes all returned items back to the originating warehouse for restocking. For perishable goods, returns should trigger disposal, not restocking. The graph is correct. The business logic is wrong. No formal property of the specification could have caught this, because the constraint lives in the PM’s knowledge of the product catalog and handling requirements, not in the schema.
She revises the specification. A new verification pass. A new ratification. Each cycle produces a more determinate state than the last.
The loop does not terminate when the representation is complete. It terminates when further clarification is no longer worth the cost.
We stop not because truth has been reached, but because the marginal cost of resolving one more ambiguity exceeds the expected cost of leaving it unresolved. The remaining assumptions are not eliminated. They are deferred, often with interest, to production.
Specification tooling does not deliver completeness. It lowers the cost of clarification. It shifts the point at which we are willing to stop. Better tools do not change the nature of the problem. They change how far we can push it before we give up.
And this leads to a structural fact about intent and systems. It is asymptotic.
Every improvement in models, context, retrieval, or formalisation narrows the gap between what was meant and what was built. But the gap does not close. The target is not fixed.
As intent is pursued, it changes. The act of expressing it refines it. The moment a representation is produced, it reveals something the human did not fully know before. The next iteration incorporates that realization. The limit moves as it is approached.
This is why the claim that systems will “fully understand intent” is not merely optimistic. It is mistaken. There is no fixed endpoint to converge to. Every milestone is a position along a curve whose boundary shifts with each step forward.
Formalisation does not eliminate this gap. It reshapes it. It reduces the space of ambiguity, making the remaining distance smaller and more tractable. Better systems do not reach the limit. They move the asymptote.
A system designed around the asymptote, one that treats generation as a starting point, builds verification that can genuinely reject, and preserves ratification as an irreducible human act, is not weaker for acknowledging the gap. It is correctly aligned with the structure of the problem.
Intent is not discovered. It is constructed, incrementally, through the act of making it formal enough to be challenged.
The asymptote is not a failure of that process.
It is its permanent condition.