What grounds the score: the model behind Fulcrum's number

The claim

What kind of model this is

Fulcrum implements a hand-tuned evaluation function: an expert prior encoded as arithmetic, derived from the Decision Architecture series and 28 years of practice across defence, fintech, telecoms and startups. It is not a statistical model fitted to organisational outcome data and it does not claim to be. There is no training set, no regression and no learned parameter anywhere in the engine.

The right comparison is a chess engine's classical evaluation. Stockfish's evaluation function was hand-tuned by strong players and engineers for years; nobody called it illegitimate, because the weights were published and could be argued with. That is the standard this page is built to meet. Every coefficient in Fulcrum's scoring function is published below with where it came from, so the argument can be had against the actual numbers rather than against an impression of them.

Provenance

Where the weights come from

The scoring function lives in one module, fulcrum/domain/simulation.py, and every coefficient lives in one frozen dataclass, SimulationParameters. There are no hidden constants: the table below is the complete set. The honest split is this: the mechanisms (what is penalised and why) come from the books; the magnitudes (the specific numbers) are engineering judgement, constrained where the code enforces a structural rule. A table claiming every number was derived from theory would not be believed and would not be true.

Signal / weight	What it does	Mechanism source	Magnitude
`authority_penalty` = 0.45	Multiplies a team's decision capacity when it lacks local authority.	Decision Architecture (authority before accountability); Relativistic Decision Architecture, Axiom 2 (authority worldlines)	Engineering judgement
`contested_penalty` = 0.35	Multiplies capacity for a team whose decisions carry a standing claim (matrix and dual reporting). Enforced to be at most `authority_penalty`, so contest is never cheaper than clean escalation.	Relativistic Decision Architecture, Axiom 2 refinement (a worldline that cannot name its owner is broken; the meta-question is the cost)	Judgement; the ordering constraint is enforced in code
`coupling_weight` = 0.6	Divides capacity by 1 + 0.6 × the dependencies touching the team.	Decision Architecture (latency accumulation); The Move Space (coordination overload)	Engineering judgement
`incentive_weight` = 0.8	Divides capacity as the team's incentive skew rises.	Relativistic Decision Architecture, Axiom 5 (incentive-induced curvature)	Engineering judgement
`delay_arrival_weight` = 0.25	Inflates a team's effective arrivals per unit of incoming propagation delay.	Relativistic Decision Architecture, Axiom 4 (causal propagation)	Engineering judgement
`cognitive_load_weight` = 0.6 `ideal_team_size` = 3	Divides capacity per unit of team size beyond the comfortable band; zero for teams at or below it.	Engineering judgement (deliberately gentle: zero in the benign case, so it never disturbs an existing position)	Engineering judgement
`latency_weight` = 0.5	Share of the composite penalty carried by backlog at boundaries.	Decision Architecture ("decision latency is the first scaling bottleneck") justifies this being the largest share	Judgement; the three shares must sum to 1.0, enforced in code
`escalation_weight` = 0.3	Share carried by the fraction of teams that cannot decide locally.	Decision Architecture (escalation as the signal of missing authority)	Judgement; same sum-to-one constraint
`rework_weight` = 0.2	Share carried by mean incentive skew across the teams.	Relativistic Decision Architecture, Axiom 5 (skewed incentives surface later as rework)	Judgement; same sum-to-one constraint
`influence_weight` = 0.08 `influence_tolerance` = 1	Divides the whole score per point of influence-without-authority load: excess inbound dependence on teams that cannot decide locally.	Decision Architecture (delegation without authority); Decision Architecture Patterns (decision shadow, phantom authority)	Engineering judgement (gentle by design)
`contested_weight` = 0.1	Divides the whole score per standing claim: the structural owner is claimant one, so each claim is one claimant too many.	Decision Architecture Patterns (decision semaphore, phantom authority); Relativistic Decision Architecture (authority fragmenting within a domain manufactures coordination load)	Engineering judgement (gentle by design)
`base_capacity` = 12.0	Decisions a team can clear per turn before penalties; sets the scale that arrivals are measured against.	Queueing framing (arrivals against capacity)	Engineering judgement
Classification bands: great ≥ +9, good ≥ +3, blunder ≤ −1	Turn a move's score delta into a grade from blunder to great.	The Move Space (the move taxonomy itself)	Band edges are engineering judgement
Move constants: approval gate delay = 3; stabilise and realign retention = 0.4; consultation delay = 1	Shape what each move does: a new approval gate arrives with delay on every team; stabilising interfaces and realigning incentives pull values toward zero without forcing them there; downgrading a claim prices the consulted party as one turn of explicit waiting. The matrix overlay needs no constant: its damage is pure contest.	The Move Space (the blunder and good-move catalogues)	Engineering judgement

The magnitude column is uniform on purpose. The books argue what should be penalised and in which direction, which is why the mechanism column can cite chapters; they state no coefficient values, so no derivation is claimed for any. The chosen values are held accountable a different way: each sits in one published dataclass, every score decomposes into named penalties and the structural constraints (the sum-to-one shares, the contest ordering) are enforced in code, so a disputed magnitude is something you change and rerun rather than something you argue about.

The distinction

What determinism buys, and what it does not

Determinism buys three things. Reproducibility: two people with the same model get the same number, so a disagreement about structure becomes something you can examine rather than adjudicate. Inspectability: every score decomposes into its named penalties and every coefficient sits in one published dataclass, so there is nowhere for a fudge factor to hide. Diffability: two candidate structures for the same organisation can be scored and compared move by move.

It does not buy validity. A deterministic function is exactly as right or wrong every time you run it. Whether the number tracks anything true about real organisations is a separate question; nothing about reproducibility answers it. The rest of this page is about that question.

Load-bearing

Assumptions the model rests on

Each of these is built into the arithmetic. If one is false, the output is wrong in the specific way stated.

Decision latency dominates structural health. Backlog at boundaries carries half the composite penalty, the largest single share. If latency matters less than that, the score over-rewards removing queues relative to fixing incentives.
Authority misplacement compounds. A team without local authority is charged three times: its capacity is cut, it counts toward the escalation share and it drives the influence divisor when others depend on it. If authority mattered less than this, the delegation moves the guide favours would be systematically overpriced.
Every dependency costs alike. Coupling counts edges, not their nature; a well-interfaced, cheap dependency and a daily-friction dependency weigh the same. Where cheap dependencies are common, coupled organisations read worse than they are.
Delay converts to load linearly. Arrivals inflate by 0.25 per unit of propagation delay. If the true effect is super-linear (oscillation, compounding rework), high-latency boundaries are under-priced, not over-priced.
Workload arrives uniformly. Every team receives the same arrivals per turn. If load concentrates on hotspots, the score is too kind: one drowning team is averaged away.
The declared structure is the real one. The model scores the organisation you drew. If informal authority routes around the formal graph, the score describes an organisation that does not exist.

Known limits

Where I expect this to be wrong

A model with no admitted failure modes is marketing. These are the places the model is expected to fail, not hedges.

Very small organisations. With a team or two there are few boundaries, little coupling and often no hierarchy: most of the model's terms have no signal and the score collapses to workload against capacity plus skew. Below that size the tool is a toy, not a diagnostic.
Contest is priced, not fully simulated. Matrix and dual-reporting structures are drawn as authority claims and priced through three channels (a capacity cut, the escalation share and a whole-score divisor), but the reconciliation traffic between the claimants themselves is not synthesised as edges. A claim is also binary: a courtesy dotted line and a co-equal second boss weigh the same. Where claim strength varies widely, the score is coarser than the organisation.
Organisations where informal authority dominates. The model reads the formal graph. Where the shadow structure makes the real decisions, the inputs are fiction and so is the score.
Non-engineering organisations. The coefficients encode software-delivery experience in defence, fintech, telecoms and startups. A hospital, a newsroom or a logistics firm has different latency and authority economics; nothing in the model knows that.
Anything short-lived or mid-transition. The score is a steady-state reading of a static structure. An organisation that never reaches steady state (a rapid reorg, a project org wound up in months) is described by a number about a state it never occupies; latency-induced oscillation over time is invisible to a single snapshot.
Heterogeneous teams. Every team gets the same base capacity. Differences in skill, seniority and tooling do not exist in the model; two structurally identical teams always score identically.

The test

What would actually falsify this

An earlier version of this site offered an internal test: model an organisation in which adding an approval layer improves structural health and the framework is wrong. That test cannot come out false, because Fulcrum's own scoring function decides whether the layer improved anything. It is a consistency check wearing a falsifiability costume; it has been retired.

The real test is external and blind:

Assemble a set of real organisations whose structural outcomes are independently documented: sustained delivery at scale on one side, delivery collapse or a structural post-mortem on the other. The outcome record is fixed before anything is scored.
A modeller who does not know the outcomes builds each organisation's Fulcrum model from structural facts alone: the org chart, the dependency map and the authority placement as they stood at the time.
Score each model once. No re-modelling after seeing a result.
Test whether the score ranking predicts the outcome ranking better than chance, against acceptance thresholds fixed before any score is computed.

Fixed where matters. A threshold stated only on this page is timestamped by the same person who computes the scores, which a reviewer can discount for free. The full protocol, thresholds included, therefore lives in the repository as PREREGISTRATION.md, written for deposit with an independent registry (OSF) whose timestamp is not the author's to edit. Until that deposit exists, the honest reading is that the bar is public but self-timestamped; discount accordingly.

This protocol has not been run. The obstacle is data honesty rather than design: structural facts about failed organisations are confidential and post-hoc accounts of them are unreliable, so assembling a clean blind set is slow. Until it runs, the correct status of the model is: a published, inspectable expert prior whose external validation is specified but outstanding. If you hold structural records that could join such a set, the repository is the place to say so.

Robustness

Sensitivity: do the conclusions depend on the exact numbers?

If the published results only hold at precisely these coefficients, the model is a curve-fit to its own examples. So the repository carries a deterministic sweep, sensitivity.py, which scales every tunable coefficient by 0.8 and by 1.2 (the three composite penalty shares are renormalised to keep their enforced sum of 1.0), re-scores the ten shipped archetypes under each of the 24 perturbed configurations and checks five qualitative conclusions: the typical archetypes still collapse in order with scale, the well-designed archetypes keep their order, every well-designed archetype still outscores its typical counterpart and both canonical blunders (the approval layer and the matrix overlay) still lower the score on every typical archetype.

All five conclusions survive every perturbation. The baseline scores below reproduce the published archetype numbers exactly; under all 24 perturbed configurations the orderings, the typical-versus-well-designed gap and the signs of both blunders are unchanged. The qualitative results come from the structure of the model, not from the particular values of its coefficients.

An axis sweep only explores the edges of the box; models typically break in the interior, where several coefficients drift at once. So the same script runs a second, joint sweep: a Latin hypercube of 1,000 draws inside the same ±20% band with every coefficient moving simultaneously, each draw renormalised and capped so it respects the model's own validation, reporting the fraction of draws under which each conclusion holds. All five conclusions hold in 100% of the 1,000 joint draws (seed 20260711, the same published seed the books use).

The sweep has already earned its keep once: the first cut of contested ownership counted a team's own authority as its only structural claimant, and under that rule the matrix overlay read positive on the escalation-heavy archetypes (it barely contested anyone while diluting every penalty share). The sweep failed, the semantics were corrected (the structural owner is always claimant one, so any standing claim is contest) and the failure is recorded here rather than erased.

Archetype	Typical	Well-designed
Startup	75.6	98.7
Scale-up	49.0	91.0
Enterprise	24.5	78.7
Very large	18.9	68.8
Conglomerate	14.8	66.4

The sweep's own limits, stated plainly: it stays within ±20%, against the ten shipped archetypes. It does not test larger swings or every published claim (the 1,732-team move-locality result is not re-run under perturbation). And the archetypes themselves are authored by the same hand as the coefficients: both sweeps test robustness to the numbers while holding fixed test cases that were built to exhibit the very properties the model penalises. It is a robustness check on the published conclusions, not a proof about every organisation. Rerun it from the repository root with python sensitivity.py; the axis sweep has no randomness and the joint sweep draws from the published seed, so you will get these numbers exactly.

Download Fulcrum Why this exists