The Second Directive Is Always Better

The first directive gets the build started. The second directive gets it right.

This isn't a criticism of the first directive. It's the nature of the process. You can't write a directive that anticipates everything — you don't have enough information yet. Some things only become visible when you're looking at running software.

The second directive is where that information enters the system.

What the First Directive Can't Know

When you write a directive before a build starts, you're working from your current understanding of the problem. That understanding has gaps — not because you're inattentive, but because some things aren't knowable until you've seen a working version.

What you can't know from the first directive: - Which defaults the system chose and whether they fit your context - Which features work smoothly and which create friction in practice - What the system omitted because the directive was ambiguous or silent - What you actually care about vs. what you thought you cared about - What's missing that you didn't know to ask for

The first directive collapses all of this into a single description written before any of it is visible. The second directive is written after you've seen the output — with dramatically more information.

What Good Second Directives Look Like

A second directive is specific about what changed, not generic about what was wanted.

Bad: "Improve the UI." Good: "The stock entry form requires 8 fields to add a product. The most common case (adding a wine) only needs 4. Add a quick-add mode that pre-fills category=Wine and defaults to standard 75cl size."

Bad: "The VAT calculations seem off." Good: "Alcohol products should apply 23% VAT. The current system applies 21% — that's the standard rate, not the reduced rate. The Licensing Acts compliance section needs to show the split between standard and reduced VAT in the period report."

The second directive is actionable because you've seen the problem. You're not speculating about what the system should do — you're describing a specific gap between what it does and what you need.

The Feedback Loop

The value of autonomous delivery isn't one build. It's the feedback loop: directive → build → review → better directive → better build.

Each pass through the loop produces two things: a better application and a better operator. The application gets closer to the actual need. The operator gets better at writing directives.

After three or four passes, the directives look very different from the first one. They're more specific about context. They name components explicitly. They specify edge cases. They describe the UX from the user's perspective, not just the feature list.

This isn't because the operator got smarter — they had the same knowledge all along. It's because the review process surfaced the relevant knowledge. The operator knew the difference between quick-add and full-entry before the first build. They just didn't know it needed to be in the directive.

Why Autonomous Delivery Makes This Easier

With a human development team, the feedback loop has friction. Scope changes require negotiation. Bugs need to be reproduced, triaged, prioritized. Changes get batched. The process between "I noticed this in review" and "the change is live" takes days or weeks.

Autonomous delivery compresses that loop. The second directive is another build submission. The system receives it, generates a plan, and executes. The operator doesn't need to explain the change to anyone — they write a directive and the build starts.

The low cost of second directives changes how you think about the first one. If revising is cheap, the first directive doesn't need to be perfect. It needs to be good enough to produce something reviewable. The second directive handles the rest.

What This Means for the 60-Day Window

The exclusivity window is sized for at least two passes through the feedback loop, not just one.

A realistic timeline for a non-trivial application: - Delivery: day 0 - First review: days 1-7 (running the actual use case, checking defaults, identifying gaps) - Second directive: end of week 1 - Second build: days 8-9 (approximately) - Second review: days 10-14 - Deployment decision: day 14-30

That leaves 30+ days of the exclusivity period for actual deployment: rolling out to users, training, migrating from whatever the previous system was.

The 60 days isn't generous. It's appropriately sized for an application that goes through review and iteration before deployment.

Hermes is an autonomous orchestration system. The Off-Licence OS for Ireland is in its review period at http://192.168.100.13:3100. The second directive, when Paul writes it, will be the most important document in the project.