The drawing says what to build

Any drawing tool has to answer one question eventually. You have the picture. Now what?

The usual answer is that you look at it and think, which is worth something and is not a method. There is a better one available here, and it comes from a property of the notation rather than from anything clever: a network of commitments partitions every moment of a business into exactly two kinds. Either it is something a named person must be given a way to do, or it is something a rule does on their behalf while they stay answerable for it.

The first kind is a specification for an interface. The second is a specification for automation. There is no third kind, and nothing falls between them.

The inbox is already generated

This is not a proposal. Press play on a network and a work inbox appears beside it: whose turn it is, which act is theirs to take, what they are waiting on, and the day each thing is due. Nobody typed that list. It is derived, moment by moment, from the drawing.

That inbox is a user interface, generated from a model, and it is sitting inside a simulator being used as a way of looking at the design. It is the same artefact you would have to build for the real Sofia — the same rows, the same acts, the same question of whose turn it is — assembled from the same source.

Which is the argument in miniature. If a screen for one person can be derived from the network for the purpose of showing you what the design asks of them, it can be derived for the purpose of building the thing they will use.

What one person's screen has on it

Take any name on a map and the drawing already answers, without further work:

Which acts are theirs. At each moment they own, the notation allows a fixed set of moves and no others. A customer at the agreement moment is not choosing from a menu of everything; they are waiting to be answered. A performer there can agree, decline or counter. Those are the buttons. Not buttons somebody thought would be useful — the complete set of things it is possible to say at that point in that conversation.

What they are waiting on, and from whom. Every promise a person is customer of, that has not come back. This is the half of any inbox that is usually missing, because most systems can show you your tasks and cannot show you your unanswered requests. The map has both, because a loop has two ends.

Where they are the one who accepts. Only the customer closes a loop. On a screen that means a person needs a place to say this is what I needed, and — the part that matters more — a place to say this is not. A system that offers no way to be disappointed has quietly decided that reports are acceptances.

What is theirs but a rule performs. Where a moment they own is delegated, they need to see it happened and to have been able to step in. Nobody performs an automatic act; somebody is still answerable for it.

Four facts about one person, read off a drawing, and between them they describe a screen.

The button nobody builds

Run the exercise on software you already have and the same omission turns up almost every time. There is a way to accept and no way to decline. There is a way to mark work done and no way for the person who asked to say it was not what they wanted. There is a queue of what you owe and nothing at all about what is owed to you.

None of these are oversights of craft. They follow from modelling the record rather than the conversation: a row with a status has one axis to move along, and refusal is not a point on it. The absence is invisible while you are looking at the schema and obvious the moment you draw the loop, because the loop has a place for it and the place is empty.

A design that leaves somebody nowhere to say no does not get reliability. It gets compliance, and it gets it silently — there is nothing in the log that says a person could not have refused. Where a promise comes apart is what that costs.

Where a rule goes instead

The other half of the partition is the more interesting one now, because it is the question everybody is asking about agents in different words.

An automatic moment is one the network is designed to have a system perform on behalf of one of the two parties. The threshold clears it; the job fires; the approval goes through under the limit. Automating it is usually right. What the drawing insists on is that the delegation is visible and that it has a name attached: not the system approves this, but the system approves this for Tomas, who could have stepped in, and who is still the one answerable.

That distinction is exactly what a build needs and what a workflow engine loses. Two moments can be automated identically and differ completely in what a person needs to see about them — whether they must be told, whether they can intervene, whether they can undo it afterwards — and the answer comes from whose act it was, which the network records and the schema does not.

So the same drawing that says which screens to build says where the rules go, and says which person each rule is standing in for. Those are not two exercises. Deciding a moment needs no interface is deciding it is delegated, and every delegation is a moment somebody is no longer being shown.

This has been tried, and it is worth knowing how

Generating software from the loop is not a new idea and its history is not an unbroken success. ActionWorkflow, in the early 1990s, put the four quarters on the screen and let people build coordination applications from them directly. The notation was sound and outlived the company that sold it.

What proved hard was never the derivation. It was the demand that a whole organisation adopt the vocabulary at once, in the tool they could not avoid, all day — what it does to software has that history. Reading a design off a map you drew for one piece of work asks nothing like as much. You are not asking anybody to classify their sentences. You are using the drawing the way an architect uses a plan: to find out what the building needs before pouring anything.

If you are building something

Three questions, and they need no adoption of anything.

For each person in your design: what can they say at each point, and does the interface offer all of it, including the refusals? For each thing your system does by itself: whose act is it, and can that person see it happened and step in? And for the one that decides whether any of the rest matters: is there a place where the person who asked says whether it was what they wanted, and is that place different from the place the work was marked done?

If the third answer is no, the first two are decoration. You have built a system that lets people report, and calls it agreement.