Intent Mediation Platform

The method

Nothing gets built until somebody has read the plan and said yes.

Software written with a machine goes wrong in a particular way. It goes wrong fast, confidently, and in sentences that read beautifully. Speed is not the problem to solve. Meaning is.

First: has this already been built?

Before anything new is written, that question gets asked of the library rather than of somebody's memory. Most of the time the answer is yes, and the work becomes wiring two things together instead of inventing a third.

Then: the plan, in writing

What is wanted, who wants it, and how anyone will know it worked — written down as sentences you can disagree with. That is where names get chosen too, because a name is much harder to change later than a plan is.

This is also the part you buy first. You get the plan, you read it, and it is yours whether or not you build it with us.

Then: the test before the thing

The check that proves a piece of work is finished gets written before the work does, and it is expected to fail at first. A test written afterwards tends to describe what the code happens to do. Written first, it describes what somebody actually wanted.

Then: prove it, in the real thing

Not 'it compiles'. Anything a person will look at gets opened in a real browser, in the language they will read it in. A page that loads but is missing half of what was asked for is reported as half done, because it is.

Then: keep what was general

After the work is done there is one more question, and it is the one that compounds: was any of that not specific to this job? If so it goes into the library, and the next project starts with it already made. That habit is why there are 445 parts rather than 45.

And the whole thing is designed in the open

The process itself gets worked on the same way the software does. Here it is being turned into something a program can run, stage by stage, with the pieces that do not exist yet written down as missing.

A terminal showing a design session. A table gives each state of a sprint — ask, recon, plan, consensus, approve, dispatch, build, verify, review and close — beside the program that produces its artifact and the probe that decides it is finished. Above it, the principle: a sprint is a state machine, not a conversation.
Designing the process itself, in the open. Every stage names the program that does it and the check that decides it is done — and the ones that do not exist yet are marked owed rather than described as though they did.

The rule underneath all of it

Anything that happens twice becomes a small program. The machine never counts what code can count.

It is the cheapest rule in the workshop and the only one that gets better with age. Each thing worked out once stops being something anybody has to work out again.