A closed loop, run every six weeks

The loop is deliberately narrow. Instead of tracking dozens of metrics at once, each cycle commits a team to one binding constraint and one intervention, run as a time-boxed experiment.

Built on Chapter 15's rhythm: diagnose, engineer, observe, diagnose again

1. 1. Diagnose

   Every member of a team, plus its leader, completes the nine-condition diagnostic. Responses are collected privately and scored on the server.

2. 2. Prioritize

   The scoring engine identifies the one or two binding constraints for the team — the conditions most limiting progress right now — rather than producing an average score across everything.

3. 3. Engineer

   The team and its leader design one focused intervention addressed directly at the binding constraint, using the Intervention Studio.

4. 4. Run a six-week experiment

   The intervention runs as a bounded, six-week engineering experiment. Six weeks is the design of the experiment cycle — it is not a guarantee that the constraint will be resolved in that window.

   The six-week cycle is this app's experiment design; the book does not set a fixed duration.

5. 5. Prove

   At the end of the cycle, the team reviews what evidence was actually gathered against the original constraint: what moved, what did not, and what should happen next.

6. 6. Repeat

   The team re-runs the diagnostic, and the loop selects the next binding constraint. Capacity engineering is a standing discipline, not a one-off project.

From Chapter 14 — Where to begin

The repair precedence the engine applies

Step 2 is not "pick the lowest score". The scoring engine applies a fixed, deterministic order of repair, in this exact sequence:

1. Fear-Load first. If Fear-Load is materially adverse, it is selected before any other condition — even when another condition has a lower raw mean. Work on other conditions is unreliable while it is costly to report problems.
2. Then direction. Once Fear-Load clears, low Expectation Precision is examined next, because effort spent elsewhere is likely to be misdirected.
3. AI leverage in parallel. Low AI Leverage Architecture is surfaced early as a safe mechanical-load removal opportunity. It never overrides the gates above and is not automatically the selected constraint.
4. Otherwise, the ranked binding constraint. Selected on condition level, between-person dispersion, the leader-team gap and the strategic result stated at launch.
5. Human confirmation. The engine proposes; a leader confirms the constraint with the team. Nothing can be activated without that confirmation.
6. Reassessment. A fresh diagnostic — never the previous reading — selects the next constraint.

You can see this precedence in action on the fictional tour, where the lowest raw mean is AI Leverage but the fear gate correctly selects Fear-Load.

On the instrument itself

Brainload Engineering Diagnostic — Pilot v0.2. This instrument has not undergone formal psychometric validation. It is not a validated psychometric instrument, a clinical assessment, or a performance measure. Treat scores as a structured conversation input, not a measurement of individuals.

For the precise relationship between the book's condition model, the BrainEng Pilot v0.2 instrument and Appendix G, see the instrument crosswalk on Research & Methodology.

Read more in Research & Methodology, or see a fictional walk-through of the whole loop on the interactive tour.