Running the Engine — the operating spec

How a team actually works day-to-day with machine partners. The companion to two-speed-engine.md: the playbook is the framework (why and what); this is the operating model (how you run it, and what you measure).

The naming rule. The metaphor — the engine, two speeds, "judgment is torque" — is the mental model: you teach it once, in the diagram. The words a team says every day are plain words they already know. No translation. The whole daily vocabulary is ~11 words.

The model in one line

When code is cheap, a team's job is judgment. So a team runs Runs: a human (the Owner) decides, a machine (the Agent) builds, and the value lands in Review — where a human catches what's plausible-but-wrong before it ships.

The roles — two seats

Compounding — turning finished work into the evals, templates, and priors that make the next Run cheaper — is an activity between Runs, not a third role to memorise. (One person owns it this week; it rotates.)

The Run — the unit of work

One piece of work, from intent to shipped. It moves across a board of four words everyone already knows — plus a fifth if you want the learning step visible:

Frame → Build → Review → Ship → (Log)

The only "new" idea on the board is that Review is where the humans add the value — and nobody has to learn a word for it.

The Review verdict. Review isn't pass/fail — the Owner renders one of five, and owns it (they're answerable for the call):

(Distinct from the Blocked alarm, which is the agent stalled mid-Build. After Osmani, "Own the Outer Loop" (Jul 2026) — his set is ship/block/redirect/narrow/reject; "block" is renamed "hold" here to avoid the collision.)

From idea to Runs — the PRD, transformed

You start with an Idea. The old chain turned it into PRD → Epics → Stories → Tasks. The two-speed chain is shorter, and the PRD transforms (it doesn't dissolve): it stops being a persuasion document and becomes machined intent.

Why it shrinks: a thick PRD was insurance against building the wrong thing, back when building cost engineer-months. Building is cheap now — so the cheapest way to kill uncertainty is often to build a probe, not write a doc. The PRD's job was to be right before you build; now you can build a probe to find out if you're right.

It splits into two lean artifacts:

• Brief — the why, as a bet: the problem, the falsifiable claim, the riskiest assumption, and a probe-or-build call. One page.
• Executable spec — what "correct" means, as evals + failing tests the agent can't fake passing. And it moves later — written per-Run at build time, not front-loaded. A green spec is necessary, not sufficient: it verifies the falsifiable; it's blind to taste, legibility, and UX. So a spec must disclose its coverage gap (what it doesn't test) and hand that to the Review verdict — otherwise "all tests pass" gets misread as "done." (Learned by running this framework through its own test: a spec went fully green while the UI was wrong three times; only human Review caught it.)

Requirements stop being a list of features to implement and become falsifiable bets + executable specs. You don't describe the solution — you state the bet and the test.

Splitting the work — a Run is one bet

You no longer split work to fit human hours (execution is cheap; you don't estimate the machine). You split it to isolate a bet — so one owner can judge it and reality can settle it. That retires SMART/INVEST's load-bearing criteria (Estimable, Small) and replaces them.

The Four Ones — a well-formed Run has:

1. One bet — you can write it as a single claim that could be proven wrong. Can't state the bet? It's a bucket, not a Run.
2. One owner — one person can make the two calls (is it right, is it done).
3. One test — small enough to ship and learn from; it can actually reach reality. Sized by feedback, not effort.
4. One scope — the agent's blast radius is bounded: what it may touch, what evidence returns, where a human must decide.

The hierarchy got shorter. Old: Epic → Story → Task (humans planned to the task, because humans executed). New: Goal → Run → Decisions — humans stop at decisions; the machine owns tasks. Your backlog is bets and open decisions, not task tickets.

How to split — four patterns:

• By decision — two independent calls = two Runs (isolate each bet).
• By trust — separate what the agent can run autonomously from what needs tight review.
• By risk — isolate an uncertain bet as a cheap probe Run that tests the claim before you commit (the spike, reborn).
• By reversibility — cheap-and-reversible ships now; expensive-and-irreversible earns a real collision (the tier check, playbook §3).

The alarms — three signals

What you measure — the instrument panel

The old dashboard (story points, velocity, burn-down) measured one thing: human throughput. That was the scarce resource. It isn't anymore. So the panel inverts.

The principle: measure the bottleneck (judgment), not the throughput (execution). Put the scarce resource in the denominator — measure output per unit of judgment, gated by whether the output was trustworthy. You can't game that by spending more tokens.

The metric test — audit any number on your dashboard with one question:

"If the team optimises this number, do they get better judgment — or just more output?" More output → it's a throughput metric. Retire it.

Retire: story points, velocity. They counted human effort, which is no longer the constraint.

The panel — the vital few:

Two rules to post on the dashboard so nobody games it:

1. Agent activity (tokens, PRs, lines) is shown as cost, not output. It's the fuel gauge, not the speedometer. (Keep it visible — execs and finance need the unit economics — just never as a productivity score.)
2. The progress bar is open decisions, not tasks-remaining. The Agent finishes tasks fast; decisions are what's actually left. Forecasting runs off review bandwidth, not build capacity.

The methods — how you actually run it

• The daily is not a status standup (Agents self-report their status). It's a judgment sync: "what decision needs another human's judgment today?" (playbook ledger: standup → transforms.)
• Starting a Run = Frame it: write the falsifiable claim, then the interface spec — what the Agent may do, what evidence must come back, and where a human call is mandatory (§4). Underspecified Frame → Blocked or Miss later.
• The Review is the mesh work: verify, calibrate trust, catch Misses, render the verdict — and own it. The Owner is answerable for what ships: able to explain what changed, why it was safe, and what happens if they're wrong. Then Log the delta. (A Run with no answerable Owner is the machine shipping unowned.)
• Between Runs, someone compounds — turns results into evals/templates so Leverage rises without Miss rate rising.
• Retire the dead ceremony first: run the practice-audit on your own rituals; most sprint machinery dissolves (see the playbook's worked verdicts).

The tools

Monday

Take one current initiative. Reframe it as a Run: write its intent as a claim reality could prove wrong, name the Owner, hand the build to an Agent, and put open decisions — not tasks — on the board. Run one Review, catch or clear it, and Log one delta. Then look at what your old velocity number would have measured this week — and everything it would have missed.

Companion to two-speed-engine.md · The Two-Speed Engine · theproductguy.xyz/two-speed-engine. Same rule as the playbook: adapt it, measure it, and let reality have the last word.