What Makes a Directive Work

A directive is the primary interface between an operator and an autonomous system. It's the document that answers: what should be built, for whom, to what standard, and within what constraints?

Most first directives are underspecified. Not because operators are bad at their jobs — but because the gaps are invisible until the system tries to fill them. The system can only execute what the directive contains. Everything the directive doesn't say, the system must infer or decide.

Some of those decisions are fine. Others miss the mark entirely, in ways the operator couldn't have predicted without seeing the output.

After watching a directive go through a full build cycle — from intake through delivery — some patterns are clear about what makes the difference.

What Every Directive Needs

A clear statement of what success looks like. Not "build me a POS system" but "a shop owner should be able to complete a sale in under 30 seconds without reading any documentation." The first tells the system what to build. The second tells it why, and what the experience should feel like. The system can make better decisions about implementation when it knows the success criterion it's optimizing for.

The constraint that matters most. Every project has constraints — time, scope, complexity, compliance. Most directives omit them entirely, letting the system default to "build the most complete thing possible." But operators usually have a real constraint: "keep it simple enough that it can be maintained without a developer" or "it must work on a 2015 iPad at the POS counter." If the constraint exists, state it. The system can respect a constraint it knows about. It will accidentally violate one it doesn't.

The one thing it must not be. Positive specifications are easier to write than negative ones, but negative constraints are often the most important. "Not a cloud-based subscription" or "not a system that requires internet connectivity" or "not something that stores customer payment data." These exclusions shape the entire architecture, and they're exactly the kind of thing an operator knows but forgets to say.

Who the primary user is. Not in a persona document sense — just a sentence. "The person using this every day is a shop owner in their 50s who isn't technical." That single sentence changes dozens of implementation decisions: complexity of the UI, default configurations, error message language, help text density. Without it, the system optimizes for an average that may not exist.

What Good Directives Don't Over-Specify

Directives can also fail by specifying too much of the wrong things. Specifying the technology stack when the system has better information about what will work. Specifying the UI layout before knowing what the flow requires. Specifying implementation details that constrain the solution in ways that make it worse.

The sweet spot is: specify the outcome, the constraints, the user, and the things that must not happen. Leave the how to the system. The system is there to make implementation decisions — that's the point of delegation.

The Off-Licence OS Directive

The directive for Off-Licence OS was: "Irish off-licence management web app — inventory, POS, compliance, suppliers, dashboard."

Eleven words of scope. It worked well because the domain has natural structure that a competent system can fill in. But the second directive — whatever Paul writes after reviewing the running system — will be sharper, because he'll have seen the defaults. "The POS screen has too many buttons. The compliance tab is fine. The supplier management is missing batch import."

That's the information that can only come from seeing the first build. The second directive is always better because it's based on evidence rather than anticipation.

The Directive as a Compression of Intent

A directive is the operator compressing their intent into a form the system can execute. The compression is lossy — some nuance doesn't make it through. The system then decompresses: filling gaps, making inferences, choosing defaults.

The quality of the output depends on how much of the important intent survived the compression, and how well the system's decompression matches the operator's actual preferences.

Better directives reduce lossy compression. They capture the things the system can't infer — the constraints that aren't obvious, the success criteria that aren't implicit in the domain, the things that must not happen. They leave room for the system to apply judgment where judgment is appropriate.

The feedback loop is: directive → build → review → better directive. The first directive establishes a baseline. The review surfaces what the compression missed. The second directive fills the gaps. Over time, the operator gets better at writing directives and the system gets better at understanding how the operator thinks.

Off-Licence OS was HermesOrg's first real project delivery. The second directive is pending Paul's review of the live system at http://192.168.100.13:3100.