Method statement

Humans steer. Agents execute. Sensors decide. Humans accept.

AI agents now write much of the code in our builds. That makes building faster, and it makes a particular kind of mistake easier: plausible work that nobody checked. So the speed is wrapped in a written method, with a specification before anything is built, automated checks on everything that is, and a named person signing off at each gate.

Sheet
A-07
Title
How we build
Issued for
Information
Drawn by
Snilld

Sequence of works

Five steps, every time

The same loop whether the change is a typo or a new module. Only the depth changes.

  1. Spec it

    Every piece of work starts as a written specification with testable acceptance criteria, including what should happen when things go wrong. If a requirement cannot be tested, it is not finished being written.

  2. Harness it

    Each repository carries its own guides, which steer an agent before it acts, and sensors, which check its work after: formatting, linting, unit and acceptance tests, traceability from requirement to test, and checks that tests have not been quietly weakened.

  3. Loop it

    Small changes, verified as they are made. The same failure twice means stop and re-plan. Scope that grows means stop and ask. An unknown tool or key is reported, never invented.

  4. Graph it

    Larger work runs as a defined sequence of roles — explorer, test designer, implementer, reviewer, verifier — so the agent that wrote the code is not the one that approves it.

  5. Steer it

    People own the decisions that cannot be undone: what gets built, what is good enough, and what is released. The agents never merge their own work.

Lanes

The process is sized to the risk

A typo does not go through a design review, and a new integration does not skip one.

  1. Lane 0: Chore

    Configuration, documentation, dependency updates. Reviewed with the check results attached.

  2. Lane 1: Bug

    A failing test that reproduces the fault comes first, then the fix.

  3. Lane 2: Small change

    One module, low risk. A light specification and a plan before any code.

  4. Lane 3: Feature

    Anything crossing modules, adding data or touching security. The full sequence, through all four gates.

  5. Lane 4: Idea

    Value or feasibility is unclear. Researched and shaped until someone decides go, clarify or stop.

Hold points

Four gates, each with a named owner

A feature does not move past a gate until a person has checked it against these conditions.

  1. G1 Spec ready

    No open questions, every requirement testable, failure cases written down, scope explicit.

  2. G2 Design ready

    Existing modules reused, contracts and data model agreed, a verification plan and a rollback path.

  3. G3 Ready to build

    Every requirement traced to a task and a test, and the acceptance tests reviewed by a person.

  4. G4 Done

    All checks pass, traceability complete, an independent review clean, and the evidence filed with the change.

Completion

What done means

  • It ran: the full checks passed, not just the fast ones.
  • It is scoped: it does what the specification says and nothing it does not.
  • It is reversible: there is a written way to roll it back.
  • It is readable: the next person, or the next agent, can pick it up.

For the client

What this gives you

  1. You can read what is being built before it is built

    Specifications are in plain language and you can sign them off. Disagreements surface on paper, not in a demo.

  2. Every change carries its evidence

    A change arrives with what changed, how it was checked, what was skipped, what is blocked and how to roll it back.

  3. Nothing is quietly weakened to get it through

    Tests and acceptance criteria are never deleted or loosened to make a check pass. There is a sensor that looks for exactly that.

Note

Where this applies

This is our standard for new builds and it is installed in our most recent repositories. Club OS was built with the same specification-first workflow the kit extends, without every sensor the kit now adds. We would rather say that than imply every past project ran this way.

See what it has built →See what we build for ourselves

See it on your own problem

A prototype runs the same way: a short specification you sign off, then two to four weeks against your own files, with the evidence attached.

Start with a prototype