This is the short form of the manual. It follows a project from what someone wants to the thing delivered, and says at each step who does what and what to keep on record. Keep it beside the work as a checklist. The full manual explains the reasons, with examples, and the Chirality Agent User Manual shows how it is done in the Chirality repository.

If you join a project already under way, find out where it actually stands before doing anything. The project's own instructions and decisions come first; this book does not replace them.

1.What the method rests on

People decide; agents do the work. A person sets the aim, makes the choices that matter, and decides what to rely on and what to deliver. Agents can do a great deal within that, but being able to do something is not permission to approve it.

Agents' work is checked before it is relied on, as you would check work from anyone else.

The record lets someone else pick the work up. Another person or agent should be able to see what was decided, what was made, what was checked, and what is left.

Reference: Manual, Preface.

2.The route

What is wanted, and the limits on it
        ↓
An accepted basis: the requirements document
        ↓
The work divided into deliverables, each with a contract
        ↓
The order the deliverables depend on each other: the project graph
        ↓
A piece of work selected, with its own plan: the work graph
        ↓
Make → check → review → fix → merge      repeat while work remains
        ↓
Bring the records up to date with what was made
        ↓
Test the product in use; fix, and test again
        ↓
Deliver, and hand over responsibility

The route passes through six stages. A stage gate is where a person decides whether the work is ready to go on.

The percentages mark positions, not effort. Parts of a project can be at different stages, and testing goes on throughout, not only at the end.

At each gate, show the person deciding what is settled, what is not, what the next stage would rely on, and what you propose. They decide whether to go on, go on with conditions, change direction, or ask for more work.

Reference: Manual §1.7.

3.Who does what

Use only the roles the job needs. On a small job, one agent can do several.

Agents carry routine work forward on their own. When a decision belongs to the person, the agent brings it as a concrete choice: the options, the evidence, and what follows from each.

Reference: Manual §§1.8, 4.3.

4.What to keep on record

Keep four things apart: the project's stage, a deliverable's state, a job being finished, and something being accepted. Finishing a job accepts nothing.

Reference: Manual §§1.6–1.9.

5.Agree the basis

1. Write down what is wanted, who it is for, and what it has to do.
2. Note the scope, the limits, the sources that govern it, its interfaces, and what is excluded.
3. Look into anything uncertain that affects the next decision. Keep prototypes labelled as prototypes.
4. Write the basis: a product requirements document (PRD), a design basis memorandum (DBM), or whatever the project uses.
5. Check it. Does it cover everything? Is it consistent? Does each claim have a source? What is still open? Fix it and check again.
6. Put it to the person for acceptance, and record what they decided and on what conditions.

Keep what is required, what is assumed, and what is only proposed apart. Permission to proceed on an assumption does not make it true. Leave gaps visible rather than filling them with guesses. For each open question, note what it affects, who owns it, and whether it must be settled before the next stage.

Reference: Manual §§2.1–2.11.

6.Divide the work and put it in order

Divide the scope. Give each part of the scope one home, in one package. Name each deliverable and draw its boundaries. Check that together the deliverables cover the whole scope, with nothing missing and nothing done twice.

Write each deliverable's contract. Say what it must produce, the requirements and interfaces it answers to, how each will be checked, and what evidence will show it. Keep the chain in view: output, requirement, check, evidence, decision.

List the dependencies. For each, say who supplies what, to whom, and when it is needed.

Break any loops. Where dependencies go round in a circle, treat the loop according to what it actually means:

Draw the project graph (a directed acyclic graph, or DAG) before the 30% gate. It can include dependencies not yet met. A graph without loops can still be missing something, so check that every source was read.

Reference: Manual §§3.1–3.12.

7.Carry a piece of work through

Each piece of work gets one work graph, which carries it across sessions and agents. The project graph says what depends on what; the work graph plans the work now in hand.

1. Find out where things stand. Read the person's direction and the basis. Compare the work graph with the actual files, unmerged work, evidence and open decisions. Don't redo work that is already merged, and make sure anyone who worked on it before has stopped before you take over their files.

2. Plan the route. Say what finishing means. Give each step an output, what it needs first, an owner, the files it may change, and how it will be checked. Plan one update of the records at the end.

3. Brief each job. Give each executor a brief:

Give each shared file one owner, and let only that owner change it. Run only as many jobs at once as you can check and merge.

4. Make, check, review, fix, merge. Verification asks whether the work meets its requirements; validation asks whether it is fit for use. Test how the parts work together, not only each part alone. Have the work reviewed independently where that is required. Fix what the review finds, within the brief, and check again. Never weaken a test or a reference result to make the work pass. Merge into the actual current state, test the result, and repeat while work remains.

5. Bring the records up to date. Check both ways: every obligation has its output and evidence, and everything built answers to something in scope. Correct the records. If something required is missing, send it back to step 4. Add a line to memory.

6. Finish. Check that the finishing conditions are met. Record what was done, what is left, and where the rest has gone. In software, update the records before the final pull request, then review and merge it. Finishing a piece of work does not accept or release the product.

Putting work off does not meet a requirement. If a real problem has nowhere to go, record it with an owner and a time to look at it again; the person decides what becomes of it.

Reference: Manual §§4.1–4.11, 5.2–5.8.

8.Test the product

Freeze a version. Before formal testing, show that nothing required is left undone; an empty to-do list does not show it. Then hold the version fixed while it is tested, and record findings separately. A fix goes back through the work and produces a new version to test.

Test it in use. Define the task, the starting state, the version, the environment, what should happen, and what to keep. Follow a user's path from start to end, including saving, errors and recovery. An agent can run scenarios under the person's direction; bring in a practitioner where the question needs one. A simulated environment shows only what it actually exercised.

Fix defects one at a time. Keep the observation, reproduce it, find the cause, make a narrow fix, have it reviewed, and test again.

Ask for the decision. Present the exact version, what the evidence supports, what is still limited, and the decision you need.

Reference: Manual §§5.9–5.14.

9.When something goes wrong

Reopen only what the change affects, and keep the work that is still good.

Reference: Manual §§1.9, 4.7, 5.10.

10.Deliver and hand over

1. Follow the organisation's delivery process, and find the person who can accept and release the result.
2. Tie their decision to the exact product, version, scope, purpose and conditions.
3. Prepare and check what the recipient will receive, including instructions and records.
4. State the limits, the exclusions, and anything unresolved.
5. Hand over support, operation, maintenance and future changes, and say where the records are.
6. Record what was actually delivered, against what the project set out to do.

A good handover says what the result is, what it rests on, what it may be used for, its limits, who is responsible for it now, and how to recover it.

Reference: Manual chapter 6.