The Two-Speed Engine — Implementation Playbook

How to adapt the framework to your own team. A self-contained guide: you don't need to have read the site to use it. · v1.4

The one-sentence version. When machines make code cheap, the bottleneck stops being human throughput and becomes human judgment. The Two-Speed Engine is a way to rebuild how you work around that shift: a human loop that supplies judgment, a machine loop that supplies execution, coupled at a mesh — and a discipline for keeping both honest.

Canonical reference: https://theproductguy.xyz/two-speed-engine. This playbook is the practitioner's version of what's published there (Charter, Ledger, Roles, Teams, Prepare), reorganised for someone who wants to do it, and built so that tools — Skills, plugins, prompts — can be compiled directly out of §7–§8.

0 · How to use this

Three ways to read it, depending on why you're here:

• Skim the model → §1. Ten minutes, the whole idea.
• Adopt it on a team → §0.5, then §2–§6, in order. Each is a step with a template and an output. You end with your own ledger, both loops installed, and a reshaped team.
• Build tools from it → §7 (the compilable core) and §8 (how each part maps to a Skill / plugin / prompt).
• Run it day-to-day → running-the-engine.md — the operating manual: roles, the Run board, the alarms, and the instrument panel that replaces story points and velocity.
• See it applied → example-run.md — a real app built end-to-end through the tools in one session (shape → frame → spec → build → review → log), with the honest scorecard and the two fixes the run fed back into the tools.

Adapt, don't transcribe. The framework's own first rule is that authority isn't correctness — so audit these claims against your reality. Where this guide and your evidence disagree, your evidence wins. Log the disagreement (§3 tells you how).

0.5 · Before you touch anything: mandate, interfaces, and the honest subtext

This playbook changes practices other people depend on. Skip this section and the rollout dies political, not empirical — which is how most transformations actually die.

• Get a mandate. Name the sponsor with authority to actually stop a mandated ceremony. If no one in the room can retire estimation or a status gate without asking permission you don't have, you have an IC side-project, not an adoption. Stop here and go get the sponsor.
• You can't stop a practice other teams consume without first replacing its interface. Estimation feeds capacity and finance; standups feed cross-team dependency coordination; sprint cadence feeds release trains; all of it feeds someone's upward status report. Before you retire any of these, define the replacement signal you'll hand the surrounding org — what appears in place of the velocity number, the dependency board, the status roll-up. Retire the ritual, keep the interface.
• Name the subtext honestly. "Fewer, broader humans" (§5) reads to staff as layoffs and to managers as lost headcount and span of control — the two groups who must execute the rollout are the two it can threaten. Say plainly what it means for roles on your team before someone else fills the silence with the worst reading. It's a claim about role breadth, not a euphemism for cuts — so say which you mean.

1 · The model in one page

The thesis. Twenty-five years of software practice optimised for one scarce resource: human throughput. Machines have now made a large share of execution cheap. So the practices you inherited were solving a problem you increasingly don't have — and the scarce resource has moved to judgment: deciding the right thing to build, and telling when the machine's plausible output is actually wrong.

Two loops, coupled at a mesh.

They are not two teams and not an assembly line. They meet at the mesh — the coupling where judgment transmits into machine speed. Its three jobs: specification (turning intent into something a machine can't fake passing), trust calibration (deciding how much to believe the output), and verification (catching plausible-and-wrong before it ships).

The mesh is not a third loop. A third speed in series just rebuilds the assembly line you're trying to escape. The supervisory work between "writing code" and "shipping" is real, but it's a coupling, not a new tier. (Hold onto this — §5 keeps the promise.)

The one test that runs through everything. For any practice, ritual, artifact, or role, ask:

Did this exist because humans have judgment, or because human throughput was the bottleneck?

Throughput-scaffolding is now optional and often waste. Judgment-work is now the whole game. Everything below is that test, operationalised — with one guard (§2) for the practices that exist for a third reason the test can't see.

2 · Step 1 — Audit your practices (the Ledger method)

Don't reorganise anything yet. First, audit what you already do. The output is your own ledger: every practice with a verdict and a next action.

The four verdicts

There are four verdicts — don't invent a fifth. Note the discipline in DISSOLVES: the phase dissolves, the intent doesn't. "Manual QA as a phase" dissolves; the intent — catch defects — re-emerges as evaluation engineering. Don't hear "dissolves" as "stop caring."

The compliance guard (runs before the verdict)

Some practices exist for a reason the throughput/judgment test can't see: accountability — audit trail, legal liability, regulatory sign-off, segregation of duties. The test would shove a SOC2 control or a SOX approval gate into DISSOLVES, and dissolving a control you're legally required to keep isn't efficiency — it's a compliance finding waiting to happen.

So before assigning any verdict, run the guard: is this a mandated control? If yes, flag it CONSTRAINED — a freeze that overrides the verdict. It stays, in its current form, until the auditor's requirement changes, whatever the test says. CONSTRAINED is a guard, not a fifth ledger verdict; it sits on top of the four.

How to run the audit

1. List. Everything your team does on a cadence: ceremonies, artifacts, gates, roles. Tag each by category — principle / framework / method / practice / artifact / role.
2. Run the guard. Mandated control (audit / legal / regulatory / SoD)? → CONSTRAINED, skip the test, move on.
3. Apply the test. For the rest: judgment, or throughput? Be honest about which era it's from.
4. Assign a verdict. Use the table. When torn between DISSOLVES and TRANSFORMS, ask: is the intent still needed? If yes → TRANSFORMS (it moves); if the whole need was throughput-coordination → DISSOLVES.
5. Write the Monday move. One concrete action someone can take next week. A verdict without a Monday move is an opinion, not a plan.

Worked verdicts (borrow, then re-test against your reality)

These are claims, not facts — adopt them as hypotheses and let your own evidence (and §6's revert-on-residual step) overrule them.

• Scrum / sprint ritual → DISSOLVES. Cadence built to coordinate scarce, serial human effort. When agents report their own status, the coordination overhead is the cost, not the value.
• Story-point estimation → DISSOLVES. Rationed scarce engineering hours across a backlog. When building is cheap, you build the smallest slice and look. (But if estimation is a CONSTRAINED input to finance/capacity, it's frozen until that interface is replaced — see §0.5.)
• Manual QA as a phase → DISSOLVES → re-emerges as evaluation. The gate goes; the intent becomes executable evals. (CONSTRAINED in regulated shops — keep the gate until the auditor's requirement changes.)
• PRDs → TRANSFORMS. From a persuasion document (aligning humans) to machined intent (a spec a machine executes and can't fake passing).
• Code review → TRANSFORMS. From reading lines to reading intent and blast radius — what was meant, and what could this break.
• TDD → TRANSFORMS. From engineering hygiene to authorship: a failing test is executable, ungameable intent handed to an agent. "The strongest form of prompt engineering."
• Daily standup → TRANSFORMS. Status reporting dies; judgment synchronisation survives — "what decision needs another human's judgment today?"
• Pair programming → TRANSFORMS. The navigator seat becomes the job: you state intent, the agent drives, you verify before merge.
• Problem-framing / define → ENDURES. Choosing the right thing to build was always the highest-leverage judgment. When building is cheap, it becomes the whole game.
• Eval-driven development → EMERGES. Executable definitions of "correct" as the dominant control plane for machine-produced work.
• Loop / orchestration engineering → EMERGES. Designing the system that prompts the agent — stop conditions, verifiers — instead of prompting it yourself.

Output: your ledger (template)

PRACTICE:      <name>
CATEGORY:      principle | framework | method | practice | artifact | role
CONSTRAINED?:  yes (mandated control — freeze) | no
ERA:           judgment-work | throughput-scaffolding
VERDICT:       endures | transforms | dissolves | emerges   (skip if CONSTRAINED)
WHY:           <one line — which side of the test, and why>
MONDAY MOVE:   <one concrete action next week>

Do this for 10–20 practices. That inventory is your adoption plan — the DISSOLVES list is what to stop (after §0.5), the TRANSFORMS list is what to rewire, the EMERGES list is what to build, the CONSTRAINED list is what to leave exactly where it is.

3 · Step 2 — Install the human loop (The Judgement Loop)

This is the operational heart of the framework, and the part most directly compiled into a tool (§8). The audit told you judgment is the scarce resource; this is how a person actually forges it.

It is not a new framework — it's the human/outer loop, specified. Name the prior art plainly: it's the scientific method (form a claim, test it against reality, update) pointed at your own judgment on a piece of work. The one new part is the spine: each stage exists to defeat one specific adversary. Miss the adversary and the stage is theatre.

The loop yields no verdict. The four verdicts (§2) are the ledger's, stamped on practices. The loop's four stages are orthogonal — do not map Sourcing/Articulation/Calibration/Collision onto endures/transforms/dissolves/emerges. The loop's only output is the logged residual delta: a magnitude and a description, not a category or a stamp. (A second 4-part stamp set would just alias the ledger and fracture the vocabulary — deliberately avoided.)

The four stages

1 · Sourcing. Treat every input as guilty until proven innocent. Authority leans on the rank of its source, not its structure. The True Lie is technically true but engineered to mislead — the shiny metric, the sanitised claim — and it's dangerous because it passes "is it true?"; the lie lives in what's omitted. The Question Mark Move beats both: authority can't answer it, and the true lie can't answer without surfacing the fact it left out.

2 · Articulation. Writing demands definition, and definition exposes the gaps that internal dialogue glosses over. This is where you catch yourself wanting a narrative to be true. The gate (enforce it): you're not done until the claim names all four of — (1) an observable signal, (2) a direction or threshold, (3) a time/scope bound, (4) the specific observation that would count as refuted. Miss any one and it isn't falsifiable yet; a precise-sounding statement that commits to nothing testable hasn't beaten self-deception, only described it more fluently. That four-part claim is the prediction Stage 4 tests.

3 · Calibration. Push it against other minds — don't seek validation, seek the breaking point. Instant agreement is gravity, not proof. Separate the two actors: the adversary (you, or a tool) surfaces the single strongest objection and the cheapest way to test it; the human rules whether the belief survived or died — that call is never the tool's. Stage 3's job is to break everything cheap — in argument — so the surprise that reaches Stage 4 is signal, not noise. If the belief dies here, log the cheap death (§7) and stop; a killed belief still produces a record.

4 · Reality Collision. Ship it — but only if it earns it (the tier check, §7). Reality returns unmanipulated feedback — the one judge that can't be swayed by charisma, authority, or desire. It breaks your thesis, not just your argument.

The forge: judgment is the residual, not the gap

Judgment is forged in the delta between what you predicted in Articulation and what reality did in Collision — but not the raw gap. It's forged in the residual: the surprise that survived a hard Calibration. If Stage 3 did its job, cheap error is already gone; what's left is signal — something reality knew that no argument could have predicted. A large residual is high-value judgment. That residual rewrites the priors you carry back into Sourcing — which closes the loop and makes Calibration a stage inside it, not an optional pre-check.

Tiering: not every belief earns a collision

A full loop turns slowly — shipping a real thing costs days to months. So run Stages 1–3 constantly and reserve Stage 4 for load-bearing beliefs, the ones expensive to be wrong about (the cost rubric is in §7). Most beliefs should die cheaply in Calibration and never reach reality at all.

The delta log (do this or the loop doesn't close)

When a belief earns a collision, log the residual in one line — or it never happened:

BELIEF-ID:  <canonical one-line claim> · <artifact ref> · <date>
EXPECTED:   <your Stage-2 prediction>
GOT:        <what reality did in Stage 4>
RESIDUAL:   <the surprise that survived Calibration>
PRIOR →:    <how your prior is now updated>

No log, no calibration — just a more fluent way of running on intuition.

AI at every stage (this is the mesh, rehearsed)

Run the loop using the machine: an adversarial reader in Sourcing, a precision-forcer in Articulation, a devil's advocate in Calibration, a builder in Collision. The machine accelerates every stage; the two human calls — whether the belief survived Calibration, and what the residual is — stay human. That is exactly the mesh, run in a low-stakes rehearsal duty cycle to forge the priors you'll bring to the high-stakes delivery one.

4 · Step 3 — Install the machine loop (loop & eval engineering)

The inner loop is cheap execution under supervision — but "cheap" hides the real bottleneck: its efficiency is dominated not by model capability but by the cost of moving context across boundaries. Installing it well is two things — making intent machine-legible and output trustworthy (the mesh), and organising the agents so context doesn't leak on every handoff.

• Specify so a machine can't fake passing. Prefer executable intent (failing tests, evals, typed contracts) over prose. This is the Articulation stage's artifact, hardened.
• Evals are the control plane, not a release gate. Write down what "correct" means — behaviour, tone, safety, cost — as living, executable definitions. Crude and executable beats precise and verbal.
• Engineer the loop, don't babysit it. Give recurring machine work a written stop condition and a separate verifier that decides "done," so you review the result, not every turn. Your review bandwidth becomes the ceiling — design around it.
• Trust is calibrated, not assumed. Decide per class of work how much output you spot-check vs. gate. That calibration is judgment; it belongs to a human.

The bottleneck is contextual transaction cost, not model size

The moment the inner loop is more than one agent, its dominant cost is making task context usable across boundaries — handoffs, compression loss, semantic drift, verification burden, tokens/latency, governance. Optimise for low contextual transaction cost (CTC), not more agents or a bigger model:

• Typed handoff schemas — what crosses a boundary is a structured contract, not a paragraph.
• Uncertainty-preserving memory — compression must not discard "we're not sure about X."
• Trace validators — the evidence that travelled with an output stays checkable.

Corroborated in the field (2026-07). Mozilla shipped 423 Firefox security fixes in a single month (Apr 2026) through an agentic pipeline — roughly 5× the prior month and ~20× its 2025 monthly average of 21.5 (Mozilla Hacks). The engineer who built it, Brian Grinstead, names the unlock explicitly: not a better model — the harness around it (file scoring, goal loops, subagent verification, humans kept on review). That is this section's claim, run at scale by someone else: capability was not the binding constraint; the cost of moving context through the loop was.

Addy Osmani's "Loop Engineering" (Jun 2026, and the Jul follow-up) frames the design space the same way, via four loop kinds separated by what you hand off: the check (turn-based), the stop condition (goal-based), the trigger (time-based), or the prompt itself (proactive). His operating rules match §4's — an evaluator model, not the worker, decides "done"; a second agent reviews with fresh context to cut correlated bias; pilot on a slice before a run spawns hundreds of agents.

Scope discipline: one org, one domain (security triage), one vendor's tooling. Take it as an existence proof for the mechanism, not a general effect size — and note it corroborates the machine loop only. It says nothing about the §2 verdicts.

The benchmarked version (Ng, 2024). Before the field reports, the controlled comparison: Andrew Ng's HumanEval numbers — GPT-3.5 zero-shot 48.1%, GPT-4 zero-shot 67.0%, GPT-3.5 wrapped in an iterative agent workflow up to 95.1% — with his own verdict that "the improvement from GPT-3.5 to GPT-4 is dwarfed by incorporating an iterative agent workflow" (DeepLearning.AI, The Batch). Same scope honesty: it's a coding-only, 2024, "up to" figure aggregated across research teams, not one held-all-else-equal run — so it argues direction (architecture beats model capability), not effect size. Direction is the whole point here.

Organise agents agent-native, not human-imitation

The DISSOLVES logic you ran on human rituals (§2) applies inside the loop: agents imitating human meetings is waste. Prefer shared-state (blackboard) + adaptive orchestration over committees, hierarchies, and rigid pipelines — human-imitation forms lose because they create lossy handoffs and correlated deliberation without preserving evidence. Human-imitation is a mistake on both sides of the mesh.

When the blackboard has to persist — "the graph earns itself." Shared state has a gate most teams skip: does it need to outlive the run? A blackboard that lives only inside one execution is cheap; a persistent, queryable store — typed entities, edges, provenance — is not, and it earns that overhead only when the same fact is read by more than one agent, or across more than one session. Written once and never re-queried, it's a database table with ceremony. Three signals say pay for it: state must survive a context-window flush, agents must share facts without copying transcripts through a bottleneck, or a result must be explainable back through its provenance (the answerable-owner test, §3). Absent all three, keep it in-run — persistence is a CTC trade, not a maturity badge. (Same discipline as "the mesh is not a third loop": don't climb a ladder the task didn't ask for.)

Diversity is not headcount

More agents help only with genuine independence — different models, tools, or evidence sources. Pseudo-diversity (one model, rephrased) adds CTC without adding signal. The unit of scale is engineered diversity, not agent count.

The mesh as a boundary spec (the "interface organization")

The mesh isn't a vibe — it's a designed boundary. At every point where machine output enters a human workflow (or another agent's), specify six things:

1. What output may cross at all.
2. What evidence travels with it (the trace a human can check).
3. What uncertainty is disclosed (so confidence isn't laundered on the handoff).
4. What permissions the agent had.
5. What traces are preserved.
6. Where human judgment is mandatory — the points that hand off to the Judgement Loop (§3). And at each, a named answerable owner: someone who can explain what changed, why it was safe, and what happens if they're wrong. A boundary with no answerable owner is a place the machine ships unowned.

A vague mesh = laundered uncertainty and un-checkable output. This is the interface between your two loops, made explicit.

Corroboration (2026-07). These — CTC as the bottleneck, agent-native > human-imitation, diversity ≠ headcount, and the interface-organization boundary — are the findings of Liu, "The Organizational Behavior of Agentic AI" (arXiv 2606.30986, Jun 2026): a simulation + LLM-trace study where shared-state / adaptive forms beat committee / hierarchy forms and collective efficiency fell as contextual transaction cost rose. Import the mechanisms, not the specific simulation percentages.

Also corroborated (2026-07): Addy Osmani, "Own the Outer Loop" (Jul 2026), reaches the same boundary independently — the human owns the outer loop because "the agent can ship more than you can review," the boundary decision is a verdict (ship / block / redirect / narrow / reject), and it demands answerability: "someone must be able to explain exactly what changed, why it was safe, and what will happen if they're wrong." Capability is not agency — "only people can choose. Only people inherit consequence."

The four skills the loops demand — use these to assess and hire:

5 · Step 4 — Reshape the team (four hats, one team)

The plus-signs between Design Thinking + Lean + Agile + DevOps were never process — they were org-chart walls for specialisation. Remove the walls and what's left is one small team wearing four hats:

The mesh keeps §1's promise: it's where the Validate hat operates, a coupling, not a fourth tier — which is why "side" here reads human/machine, never "middle loop." Validate carries all three mesh jobs, so specification has an owner (it's the Understand→Execute handoff artifact Validate is accountable for).

One housing, two speeds, never two teams. Not bimodal IT, not a fast team and a slow team. Fewer, broader humans beat more, narrower ones, because every seam removed is a handoff tax refunded. Map your current roles onto hats; where one person can hold two hats, collapse the seam — except where a mandate forbids it. Segregation of duties (builder ≠ approver ≠ deployer, required by SOX / SOC2 / GxP) is a CONSTRAINED seam: keep it. And re-read §0.5 before you say "fewer humans" out loud.

6 · The adoption path

A staged rollout beats a big-bang reorg. Instrument it first, then four phases.

6.0 · Instrument it, or you can't tell it's working

The framework demands everything face reality — so it must face its own. Before touching anything:

• Baseline the numbers the org already trusts — cycle time, escaped-defect rate, rework %, deploy frequency. You can't show improvement you never measured.
• Pick 2–3 rollout-level metrics and, for each, the threshold that triggers rollback. Pre-commit the abort trigger — a transformation with no kill signal persists on faith long after it's gone net-negative. (Per-belief delta logs are not a rollout scoreboard.)
• Book the cost honestly: this adds ceremony (Judgement Loops, delta logs, eval authoring, audit workshops) and infra spend, plus a transition dip, before it removes anything. Name the bill.
• Define "done" — the state at which you stop rolling out — and the evidence that would tell you the framework is simply wrong for this team, at which point you stop and record why. That's the framework's own Reality Collision.

The four phases

1. Assess (week 1). Run §2 on your real practices → your ledger. Separately, have each person run one belief through §3 → a delta log. You now have evidence, not opinion.
2. Pilot (weeks 2–4). One team, one workflow. Retire the top DISSOLVES item — after replacing its interface (§0.5) and confirming it isn't CONSTRAINED (§2). Rewire one TRANSFORMS item (start with code review or standup — low risk, high signal). Stand up one EMERGES item (usually a first eval). Keep everything else.
3. Calibrate (weeks 4–8). Log deltas on the changes and track the §6.0 rollout metrics against baseline. Where a change's residual says you were wrong, revert and record why; if the rollout metrics cross the rollback threshold, stop the whole thing. This is the framework auditing itself — the point is a calibrated system, not fidelity to this document.
4. Expand. Roll the survivors to the next team. Fold the team into four hats only where the pilot proved the seams were tax — never across a CONSTRAINED seam.

Change first: the practice with the biggest throughput-scaffolding cost and the lowest judgment content (usually estimation or status ceremony). Leave alone: anything you verdicted ENDURES or flagged CONSTRAINED. Touching those first is the classic failure mode.

7 · The compilable core (procedures & templates)

Everything a tool needs is here, in one place, so §8 can wrap it. Entry condition for the loop: a valid input is a belief or decision you could be wrong about — not a task. "Should we bet on X?" qualifies; "implement X" doesn't. No truth value → not for this loop.

The Judgement Loop, as a procedure:

INPUT:  a belief/decision + the work artifact it attaches to
        BELIEF-ID = <canonical one-line claim> · <artifact ref> · <date>

1 SOURCING     — list the inputs behind the belief. For each, the Question
                 Mark Move: "what structural facts must be true for this to
                 hold?" Flag authority-leaning claims (rank, not structure)
                 and true-lies (technically true, key fact omitted).
                 If a carried prior exists for this BELIEF-ID, inject it here,
                 tagged "prior — Question-Mark it too."

2 ARTICULATION — write the belief as a falsifiable claim.
                 GATE (enforce; do not advance until all four present):
                   (1) observable signal
                   (2) direction or threshold
                   (3) time / scope bound
                   (4) the observation that would COUNT as refuted
                 Missing any → reject, re-prompt. This claim = the prediction.

3 CALIBRATION  — TOOL/adversary: surface the single strongest objection + the
                 cheapest way to test it. Attack the logic; seek the break.
                 HUMAN: rules survived or died — the tool may not.
                 If DIED → write a Calibration-death record and stop:
                   BELIEF-ID / KILLER-OBJECTION / PRIOR→
                 (cheap deaths still log — that is Stage 3 working.)

4 TIER CHECK   — proceed to a real collision only if being wrong clears a bar
                 on >=1 axis:  irreversibility · money · people affected ·
                 time-to-detect.
                 DEFAULT below-the-line: reversible in <1 day AND scoped to you
                 → stop; not load-bearing enough to ship a test.

5 REALITY      — design & ship the smallest thing that could produce the
                 refuting observation named in step 2.

6 LOG & CLOSE  — write the delta log; derive the carried prior; feed it back.

OUTPUT: an updated prior + a one-line delta log — OR a Calibration-death record.

Two calls a tool may never make (they are the human's): the survived/died verdict in Calibration, and the residual in the log. Decide either for the user and the tool has become the inner loop pretending to be the outer one.

The carried prior (machine-readable, so the loop closes across sessions):

{ belief-id, prior-statement, confidence, open-question }

Recurrence match = same BELIEF-ID (or the tool asks "same belief as <stored>?"). On re-entry, this object is the "prior" injected at Sourcing.

If the user resists a gate: don't wave it through. Won't produce a falsifiable claim → the belief isn't ready; name what's missing and stay in Articulation. Insists a below-the-line belief is load-bearing → ask which axis clears the bar; if none, it stops. Enforcing the gate is the tool's job.

The audit, as a procedure:

INPUT:  a list of practices / rituals / artifacts / roles
FOR EACH:
  - GUARD: mandated control (audit / legal / regulatory / SoD)?
           → CONSTRAINED, freeze, skip the test
  - classify category
  - apply the test: judgment, or throughput?
  - assign verdict: endures / transforms / dissolves / emerges
  - write one Monday move
OUTPUT: a ledger; group by verdict → stop / rewire / build / freeze lists

The machine-loop audit, as a procedure:

INPUT:  a described agent workflow (agents, handoffs, memory, tools, outputs)
1 CTC SCAN   — score cost across 6 components: handoffs · compression loss ·
               semantic drift · verification burden · tokens/latency · governance.
               Flag the 1-2 biggest cost sinks.
2 ORG-FORM   — is this a committee / hierarchy / rigid pipeline that should be
               shared-state (blackboard) + adaptive orchestration? recommend the shift.
3 DIVERSITY  — are extra agents genuinely independent (model / tool / evidence),
               or pseudo-diversity adding CTC without signal? cut the latter.
4 INTERFACE  — for each machine→human (or →agent) boundary, specify:
               output allowed · evidence carried · uncertainty disclosed ·
               permissions · traces preserved · mandatory-judgment points.
OUTPUT: a CTC-reduction list + org-form recommendation + the interface spec.
        Mandatory-judgment points hand off to /judgement-loop.

8 · Compiling this into tools (Skills, plugins, prompts)

The playbook is the spec; tools are compilations of specific sections. Build them "appropriately" — each artifact wraps exactly one procedure from §7, so it stays faithful and testable.

Design rules for any tool built from this:

• One procedure per tool. Don't fuse the audit and the loop — different inputs, different cadence.
• Enforce the gates, don't just mention them. The Articulation four-part gate and the tier cost-rubric are where the value is; a tool that lets you skip them is a poster with a CLI.
• Never make the two human calls. Tools accelerate stages and play the adversary; they must never decide the survived/died call or the residual. The loop yields no category of its own — the moment a tool decides either, it's the inner loop pretending to be the outer one.
• Stay faithful to the vocabulary (appendix) so derived tools interoperate.

Packaging for distribution: a Skill is SKILL.md + optional references; a plugin bundles Skills + commands. This playbook file is the source of truth all of them cite — change the framework here first, recompile the tools.

Appendix · Canonical vocabulary

Keep derived tools consistent by drawing terms from this controlled list.

• Verdicts: endures · transforms · dissolves · emerges — and the guard CONSTRAINED (a freeze that overrides a verdict; not a fifth verdict)
• Categories: principle · framework · method · practice · artifact · role
• Disciplines: product · design · engineering · qa · leadership
• Skills: judgment · specification · verification · orchestration
• Hats: Understand · Validate (owns the mesh's three jobs) · Execute (machine loop) · Compound
• The mesh's jobs: specification · trust calibration · verification
• Contextual transaction cost (CTC) components: handoffs · compression loss · semantic drift · verification burden · tokens/latency · governance
• Machine-loop org forms: prefer blackboard (shared-state) · adaptive orchestration — over committee · hierarchy · rigid pipeline
• Interface organization (the mesh boundary): output allowed · evidence carried · uncertainty disclosed · permissions · traces preserved · mandatory-judgment points
• The Judgement Loop's stages: Sourcing · Articulation · Calibration · Reality Collision
• The Judgement Loop's adversaries: Authority & the True Lie · Self-Deception · Groupthink · Reality
• Operating roles (see running-the-engine): Owner (human, decides) · Agent (machine, builds) · compounding (activity between Runs)
• The Run: Frame → Build → Review → Ship → Log
• Operating alarms: Blocked · Miss · Overloaded
• Review verdict (the Owner's call at Review, and is answerable for it): ship · hold · redirect · narrow · reject
• Instrument panel: Miss rate · Leverage · Open decisions · Cost per shipped item · Hit rate — retires story points, velocity

Adapted from The Two-Speed Engine · theproductguy.xyz/two-speed-engine. Revise it in public: date your changes, log your deltas, and let reality — not this document — have the final verdict.