Writing specifications that a machine could actually run

In a previous essay, I argued that the real frontier of AI-generated software is not the code model but the specification layer, the place where human organizations state what they actually want. If you are a workshop facilitator or an enterprise architect, that frontier is your job description.

Here is the good news: if you already run serious modeling workshops — Astrakan, Zachman, ArchiMate, BPMN, event storming, or any disciplined methodology — you are doing most of what is needed. Your concept, process, goal, and rule models, as well as your stakeholder analyses, are fine. What changes is not the foundation but the finish. A specification written for a future where a machine generates and verifies the system needs to close a few specific gaps. Gaps you already feel in your current work, even if you have not named them yet.

Here are five shifts to experiment with in your next engagement. None of them requires new tools. All of them can be tried on Monday morning.

1. From directional goals to quantified goal functions

What most workshops capture today

A list of business goals in declarative form. “Improve customer experience.” “Reduce operational cost.” “Accelerate time-to-market.” Perhaps a rough priority ranking.

The gap

None of these statements can be tested against. A machine, or for that matter a disciplined human, cannot verify whether an outcome satisfies “improve customer experience.” The statement commits to nothing specific and therefore cannot fail.

The shift

For each goal, drive the workshop toward a measurable function. Not just a KPI, but the shape of the function. Is more always better, or is there a threshold beyond which additional improvement has no value? Is there a floor below which the goal is considered violated? What is the unit, and over what time window?

“Improve customer experience” becomes something like: increase Net Promoter Score in the consumer segment, measured quarterly, with a minimum acceptable value of 40 and a saturation point at 65, beyond which further improvement is not worth trading off against other goals.

The hard part is not the math. The hard part is getting executives to commit to the numbers. That commitment is exactly the work that later becomes invaluable, and it is the work a facilitator is uniquely positioned to extract.

2. From listed trade-offs to explicit dominance rules

What most workshops capture today

A recognition that goals sometimes compete, usually documented as “we will balance cost and quality” or “we will weigh customer experience against efficiency.”

The gap

“Balance” is a verb that specifies nothing. When cost and quality conflict in a concrete situation, the system — human or machine — has to make a call. If the specification does not encode the call, someone makes it silently, and their silent call becomes the de facto policy.

The shift

Build a habit of asking, for every pair of potentially conflicting goals, what concretely happens when they collide? There are usually three possible answers, and it is worth forcing the room to pick one: a strict dominance (A always wins over B), a bounded dominance (A wins over B unless B drops below a floor), or a weighted trade-off (a scalar or curve specifying the exchange rate).

A practical technique: draw a 2x2 of “high A, low B” and “low A, high B” scenarios and ask which quadrant the organization prefers. Then pressure-test the framing. “If A could be improved by 5% at a cost of a 3% drop in B, would we do it? What about 5% for 8%?” Executives often discover, in this exercise, that their intuitions are inconsistent. That discovery is the point. The output of the exercise is a dominance rule that can be written down and, later, enforced.

This is where your facilitation craft matters most. Most people have never had to make these trade-offs explicit. The conversation is uncomfortable. It is also, in my experience, the most valuable hour of most engagements.

3. From process narratives to invariants

What most workshops capture today

Process models that show how work flows, often as BPMN diagrams or swimlanes. These describe the happy path and sometimes the exception paths.

The gap

Processes describe what happens. Specifications need to describe what must always be true; the invariants that hold regardless of which path the process takes. A machine generating a system from the spec needs to know not just the choreography but the constraints.

The shift

After you have a process model, walk through it with the question: “What properties must hold throughout? What would be true in every possible execution of this process, regardless of the branches taken?” Typical invariants involve conservation (no money is created or destroyed), ordering (a payment cannot be confirmed before it is authorized), uniqueness (a customer cannot be assigned two account managers simultaneously), or referential integrity (every order references a valid customer).

Capture these separately from the process model, in the same vocabulary as your concept model. You are, in effect, building the contract that the generated system must honor. A good rule of thumb: if your invariants read like things a lawyer or auditor would care about, you are probably on the right track. If they read like implementation details, you have drifted too far down.

4. From “the developer will write tests” to specifying verification intent

What most workshops capture today

Acceptance criteria, usually at the user story level, are written in natural language.

The gap

Acceptance criteria describe what a human tester should check. They presume the existence of a developer and a tester as roles distinct from the business. In a world where specifications drive generation, the specification itself must contain enough information to automatically derive tests. That means capturing verification intent, not just verification outcomes.

The shift

For each goal and each invariant, ask: how would we know this was violated? What data would change? Over what time window? With what statistical confidence? A goal like “reduce handling time” should be accompanied by specification metadata along the lines of: measured in the fulfillment process, sampled over rolling 30-day windows, with a violation signaled when the 95th percentile exceeds 8 minutes.

This looks like extra work, and it is. But it is work that already happens — at the end of the project, hurriedly, by people who were not in the original workshop and do not carry its context. Moving it to the front loads the workshop but removes the worst source of late-project surprises. And it produces a specification that can be verified against, not just delivered against.

5. From decisions-in-meeting-notes to decisions-in-the-model

What most workshops capture today

The model is the model; the discussion that produced it lives in separate meeting notes, email threads, and tribal memory.

The gap

Six months later, when a business rule needs to change, no one remembers why it was set that way. The institutional knowledge that would tell you whether the original decision still holds has decayed. In traditional IT, this is annoying. In a spec-driven world, it is fatal — because the specification is the system, and its longevity depends entirely on its being maintainable.

The shift

Treat every non-obvious specification choice as carrying a provenance record: the decision, the alternatives considered, the rationale, the stakeholders who signed off, and the conditions under which the decision should be revisited. This does not need to be heavy. A sentence of rationale attached to a goal threshold is enough. What matters is that it travels with the model, not in a separate document that no one opens.

A practical technique: at the end of each workshop day, walk the group through the day’s model changes and ask, for each, “one sentence: why this, not something else?” Capture the answers inline. You will produce a document that is roughly twice as useful for maintenance as a pure model, at a cost of roughly twenty minutes per day.

Running your own experiments

None of this requires new technology. All of it can be layered onto whatever methodology you already use. The five shifts above are, roughly in order, the easiest to hardest to introduce in a real client engagement — not because the techniques are difficult, but because each demands a bit more from the room.

If you try these, I would like to hear what happens. Not the polished success stories; those are easy to find. I am interested in the failure modes. Where did the method collapse? What did executives refuse to commit to? Which of the five shifts turned out to be premature for your organization’s maturity? The field of executable business specification will advance by accumulating honest reports from practitioners, not by generating more frameworks.

If you are working on related problems — as a facilitator, architect, methodologist, or researcher — I am actively looking for people to experiment with. The long-term vision is a methodology mature enough that AI systems can generate and verify business applications directly from workshop output. The short-term work is smaller and more concrete: closing the gaps above, one workshop at a time, and writing down what we learn.

The workshop room is where this methodology will be built, or not built. Let us get on with it.