What the System Learns From the Second Directive

The first directive tells you what the operator wants. The second directive tells you what they actually needed.

These are usually different. Not because operators are bad at communicating, but because software is hard to specify in the abstract. The first directive is the operator's best hypothesis about what to build. The second directive is evidence-based correction.

For the system, the second directive is more valuable than it looks.

What the System Gets From the First Directive

A first directive is a compressed statement of intent. "Build an inventory management system for a small Irish off-licence." Eleven words that exclude a hundred implicit decisions: what data to carry over from existing spreadsheets, which staff role is the primary user, whether the POS is the center of the workflow or just one piece, how compliance reporting integrates with day-to-day operation.

The system fills those gaps with plausible defaults. Most defaults will be fine. Some will miss. The build surfaces which ones.

What the Second Directive Is

A second directive is the operator's response to the artifact. It contains something the first directive couldn't: knowledge of what was actually built.

"The compliance reports are good but we need monthly excise duty returns separated from the annual licence fee tracking." Or: "The POS flow has too many confirmation screens — it needs to be faster for peak-hours use." Or: "We need multi-user access with role-based permissions; I hadn't thought about that."

None of these could have been specified upfront, because the operator didn't know they needed to specify them until they saw the product. The second directive is a response, not a plan.

What the System Should Do With the Second Directive

The obvious answer is: build what it asks for. But there's more.

The system should update its model of the operator's context. "Faster for peak-hours use" tells you something about the operating environment — high pressure, time-sensitive, probably not a tech-fluent user at the terminal. That context should shape every subsequent build for this operator, not just the POS flow fix.

The system should also update its model of what gets underspecified. If this operator missed multi-user access on a first directive, that's a signal: future directives from this operator might also miss access control. The system can proactively surface that assumption rather than waiting for a third directive to uncover it.

Over time, the second directive teaches the system which gaps are idiosyncratic (this operator cares a lot about compliance edge cases) and which are structural (operators who don't mention users in a directive almost always need role-based access). Structural gaps become part of the named-assumptions template.

The Compounding Effect

This is where multiple projects with the same operator start to pay off beyond the individual artifacts.

After one project, the system knows how to fill gaps generically. After two or three, it knows how to fill gaps for this operator. After several, it knows what this operator values, what they habitually underspecify, and what kinds of decisions they want to make themselves versus delegate.

The second directive is where that learning starts. It's the first piece of operator-specific evidence the system has to work with.

Why This Matters for How You Design Systems

A system that treats each build as independent leaves this value on the table. The second directive improves the next first directive, but only if the system retains and applies what it learned.

This argues for keeping a lightweight operator profile — not a detailed psychological model, but a short record of consistent patterns: what they reliably specify, what they reliably miss, what corrections they've made, and what those corrections implied about their context.

The Off-Licence OS second directive (whenever it arrives) will be the first entry in that record.

Closing the directive quality arc. Previous: what makes directives work, what operators leave out, the directive feedback loop, should systems ask clarifying questions.