Narrow the job, then build the path you can operate.

Step 01

Frame

We write down the decision the software has to support, the data you already have, and the cost of a wrong answer. If a ledger is involved, we also write who must share the history and who must not see the underlying detail.

• A one-page problem note your sponsors can edit.
• A list of data you can use, and data you should not send to a model.
• A recommendation to build, wait, or cut scope.

Step 02

Prove

The prototype is a thin working path, not a visual mock with fake results. For a model, that means a real evaluation on held-out examples. For a contract, that means tests and a pause path you can trigger.

• Something a future user can click.
• A pass or fail test agreed before the slice is built.
• A note on what the full build would still have to solve.

Step 03

Build

Releases stay short. Each one has acceptance checks, a review of permissions, and a written list of what is intentionally out of scope. We do not speed up by skipping the evaluation or the upgrade story.

• Code review and tests on the paths that move money, data, or rights.
• Separate environments, with production access limited to your admins.
• A release note an operator can follow without the author in the room.

Step 04

Hand over

The build is finished when your team can run it. We leave access maps, key ceremonies you perform yourselves, evaluation instructions, and a short support window for the first incidents.

• Runbooks for pause, rollback, and key rotation.
• A named contact during the support window.
• The option to keep a stewardship pair, or to stop cleanly.