Groundwork.
For agents

The method

3 teams. One shared model.

Product, design, and engineering all read from one file that says what the product does. Build from it, check the build against it, and change it first when something changes.

That file is the intent model. It lists what the product stores (fields), what it allows and forbids (rules), the paths people take through it (journeys), and what nobody has decided yet (open questions).

Start with the requirements you have and the part you will build next. It does not need to be complete. The team agrees on it, then designers and engineers build from it. Small checks compare the build to the model. When a requirement changes, you change the model first and the screens after.

INPUTS INTENT MODEL WORKING FOLDER BUILD SCREENS DRIFT CHECK REQUIREMENT CHANGE
Fig 015 stops, 2 ways back. The highlighted path matters most: a change goes into the intent model first, not straight onto a screen or into a ticket. Every other diagram on this page shows this same process from another side.

Handle changes at the source

Some changes only move things around on one screen. Others change a rule that several screens rely on. Ask one question: does anyone else depend on this? If yes, it goes in the model. If no, just change the screen.

YES REBUILD DEPENDENTSNO THIS SCREEN ONLY DOES ANYONE ELSEDEPEND ON IT? CHANGE REQUEST UPDATE MODEL REFINE CODE
Fig 021 question, not a rulebook. Size does not matter. What matters is whether anyone else depends on it. Changing 2 words on a fee label goes in the intent model if the fee is a rule. Redesigning a whole table does not, as long as it shows the same fields.
Follow the change guide

5 views of the workflow

The same process, drawn 5 ways. Use whichever one makes sense to the person you are explaining it to.

01

The contract

Product managers and clients
SAME SOURCE, SEPARATE WORK INTENT MODELV4, VERSIONED REQUIREMENTS CLIENT ANSWERS PRODUCT ACCEPTANCE CRITERIA DESIGN SCREENS & STATES FRONTEND ROUTES & RULES BACKEND OWN BUILD & CHECKS
Fig 031 file, several readers. Each team reads the part it needs, without asking another team for it. The dashed box is the back end: it could read the same model, but nothing here sets that up for you.

How to use it

Go through the model together. Everyone can see what is agreed and what is still open.

What to account for

It only helps if someone keeps it up to date.

02

The 3 lanes

Team leads
DEFINEBUILDREVIEW INTENT MODELHANDOFF 1 EXPORTED SPECSHANDOFF 2 PRODUCT DESIGN ENGINEERING
Fig 042 handoffs, and both are files. Between the dashed lines, each team works at its own pace with its own tools. They only have to agree at the 2 points where work passes from one to the next. That is why it keeps working when someone is on leave.

How to use it

Each team knows what it receives and what it hands on. The handoffs are files, not meetings.

What to account for

A small team may have one person covering several lanes.

03

The change loop

Designers and engineers
REQUEST OPEN QUESTION APPROVED EDIT REBUILD SCREENS CHECK COVERAGE SHIP NEXT REQUEST
Fig 05Step 2 is the one people skip. Write the change down before anyone acts on it. Waiting for an answer can take 2 days. That wait is where teams guess, and a wrong guess means building it twice.

How to use it

Write the request down, agree on it, then rebuild and check.

What to account for

Rebuilding takes time. Before changing a shared rule, see which screens use it.

04

The layers

Designers and frontend engineers
DESIGN SYSTEMINTENT MODEL SCREEN DESIGN TOKENS COMPONENTS PROJECT REGISTRY DATA DICTIONARY STAGES RULES & FLOWS
Fig 062 stacks, 1 screen. The left stack is how it looks, and comes from the design system. The right stack is what is on it, and comes from the intent model. The screen is where they meet. Spacing and balance still need a designer’s eye.

How to use it

How a screen looks comes from the design system. What is on it and how it behaves comes from the model.

What to account for

Spacing, density, and visual balance still need judgement on the screen.

05

The shared plan

The whole team
SHARED PLANREV B CLIENT MOVE A WALL ELECTRICIAN PLUMBER CARPENTER
Fig 07An old idea. On a building site, everyone works from the same drawing. It is what stops the electrician, the plumber and the carpenter each building a different house. The intent model does that job for product, design, and engineering.

How to use it

Everyone works from the same plan, and it gets updated as the team learns.

What to account for

The model grows during the build. It does not need to be finished on day 1.

What still needs review

The checks can tell you the build matches the model. They cannot tell you the model is right, the design is good, or the parts outside the screens work. People still review those.

COVERED BY THE MODELBEFOREAFTERBESIDEBENEATH INTENT MODEL DISCOVERY REQUIREMENT SCREEN OUTCOMES BACKEND & OPERATIONS DESIGN JUDGEMENT
Fig 084 areas it does not cover. Before and After are about time: the model starts once you have decided to build, and stops at launch. Beside is the rest of the system, like the back end, which this method does not touch. Beneath is what a file cannot hold: taste, real data, and what people just remember.

Some checks reach a little further. Real data validation tests the app's data shapes against real responses saved from the server. For rules no script can check, write down that a person must look, so nobody assumes it is covered.

Watch every check fail once

A check that always passes might be working, or it might be broken. From the outside you cannot tell. Think of a smoke alarm nobody has ever tested: silence could mean no fire, or a cut wire.

So every check here comes with a small test file that breaks the rule on purpose, called a probe, and one that follows it. Run the check on the probe and watch it fail. Now you know it can. We call this the red gate. And if a check could not run at all, that is not a pass. It is a check that did not happen.

Set up your project