What you actually do with it

You draw an organisation or open one of the shipped examples. Teams are the leaves, units nest above them, dependencies say who waits on whom and with how much delay; each team is marked as either deciding locally or escalating to someone above. Fulcrum then scores that structure out of 100, lists every move legally open to you with the points it would gain or lose and lets you play one, watching the number and the map change. The same definitions below are in the app under Help, Decision glossary.

The moves you can play

• Delegate authority. Give a team the right to decide and ship on its own, removing an escalation and dissolving influence that had collected with no authority to use it.
• Resolve authority. Collapse a contested decision class to a single accountable owner, so who decides never has to be settled before anything can be decided. The repair for matrix and dual reporting.
• Downgrade a claim. Turn a second claimant into a consulted party: an explicit interface with a small delay rather than shared control, so the overhead is priced instead of hidden.
• Stabilise interfaces. Thin and steady the boundaries so changes cross between teams with less waiting.
• Realign incentives. Pull a team's rewards back toward the outcome it is asked to ship, so less delivered work comes back as rework.
• Collapse a boundary. Let one team own the whole slice. It deletes a handoff, not headcount, so it is not centralisation; merging far past a small band, however, raises internal coordination and turns costly.
• Split a team or add an owner. Relieve an overloaded owner by creating a second complete one, the opposite of splitting along a technical layer.
• Add an approval layer. The canonical blunder, playable here like any other: a gate every team routes through, formalising missing authority as process.
• Impose a matrix overlay. Its contest twin: a second claimant on every team at once, so every decision starts with an argument about who decides.

The signals you watch

• Handoff queue age. How long a change waits at a boundary before the next team picks it up.
• Escalations per release. How many teams must push a decision up to get one release out.
• Rework rate. The share of delivered work that comes back for redo soon after.
• Influence without authority. Teams many others depend on but that cannot decide locally. Left unchecked it burns people out.
• Contested ownership. Teams whose decisions carry a standing claim from someone else.
• Centre escalation load. Escalated decisions per turn landing on the single most loaded authority.
• Unowned interfaces. Two sovereign teams depending on each other with nobody above both to settle a conflict.

The ideas underneath

• Local authority and escalation. Whether a real person at the team can decide or whether the decision has to travel. A team that needs sign-off for every schema change escalates constantly; that wait is structural rather than personal.
• Propagation delay. The turns a change spends waiting at a boundary. A ticket sitting four days in another team's queue is four days of it.
• Incentive skew. How far a team's rewards pull away from what it is asked to ship. A team measured on tickets closed while asked to improve reliability is skewed; it surfaces later as rework.
• Structural health. The 0 to 100 score, falling with backlog at boundaries, with teams that cannot decide locally and with skewed incentives.
• Move classification. How a move grades before you play it, exactly as a chess engine grades moves: great, good, neutral, bad, blunder, by the points it would move the score. Deltas are scored inside the section you are focused on, so the same change reads larger the deeper you drill.
• The prince band. Concentration priced by size. One decisive founder works up to roughly the Dunbar horizon, because escalating to them is a conversation; the identical structure at thousands of people scores badly, because the centre is now far from the work.

What grounds it, briefly

The score is a hand-tuned evaluation function, the same kind of thing a classical chess engine uses: an expert prior written as arithmetic. It is not a statistical model fitted to organisational outcome data: there is no training set, no regression and no learned parameter anywhere in the engine.

The split is honest. The books supply the mechanisms: what gets penalised and in which direction, which is backlog at boundaries, teams that cannot decide locally, incentive skew, contested ownership, fragmentation with nowhere to arbitrate it and concentrated authority priced against the size it has to govern. The magnitudes, the specific coefficients, are engineering judgement from 28 years of practice. No number here is claimed to be derived from theory.

They are held accountable a different way. Every coefficient sits in one published dataclass in one module, every score decomposes into its named penalties and the structural constraints are enforced in code rather than trusted, so a weight you disagree with is something you change and rerun. Scaling every coefficient up and down by a fifth, one axis at a time and then all at once, leaves the published conclusions standing.

What that buys is reproducibility and inspectability, not validity: a deterministic function is exactly as right or wrong every time you run it. The external test that would settle it, scoring real organisations blind to their documented outcomes, is specified and has not been run. The full coefficient table, the assumptions, the places the model is expected to be wrong and that protocol are in What grounds the score.