Skip to content

Toolkit — System Fitness Checklist

Use this checklist to evaluate any system (framework, process, governance mechanism, operating routine) on a monthly or quarterly cadence. The goal is not to defend or attack systems—it is to decide keep / modify / subordinate / remove based on evidence.

This checklist is intentionally short. If you can’t evaluate a system quickly, you probably don’t have an inspectable system—you have an ambient ritual.

How to Use

  1. Pick one system.
  2. Bring the last 3 artifacts it produced (or admit there are none).
  3. Score it across five dimensions (0–2 each).
  4. Decide: keep, modify, subordinate, remove.
  5. If modifying, choose one lever: artifact, constraint/default, authority boundary, cadence/trigger, unit-of-analysis scope.

The Fitness Scorecard (0–10)

1) Problem fit (0–2)

Question: Is the system still aimed at the real, dominant failure?

  • 0: The target failure is unclear, obsolete, or not evidenced.
  • 1: The failure exists but is not clearly dominant, or evidence is mixed.
  • 2: The failure is observable, evidenced, and still dominant.

Evidence to check:

  • recurring incidents, missed commitments, escalation logs, queues, reversals

Score: __ / 2

2) Decision clarity (0–2)

Question: Can people name the decision this system optimizes, and does it produce decisions?

  • 0: Decision type is unclear; outputs are discussions.
  • 1: Decision type is sometimes clear; outputs inconsistently commit action.
  • 2: Decision type is explicit; outputs reliably produce commitments.

Test prompt:

  • “Which decision became safer/faster/harder to avoid because this system ran?”

Score: __ / 2

3) Artifact inspectability (0–2)

Question: Does the system produce artifacts that can be challenged and reused?

  • 0: No consistent artifact, or artifacts exist but are unused.
  • 1: Artifacts exist but are inconsistent, ambiguous, or not referenced later.
  • 2: Artifacts are consistent, inspectable, and used in future decisions.

Artifact checks:

  • includes owner
  • includes decision change
  • includes assumptions/constraints where relevant
  • lives in a known “source of truth” location

Score: __ / 2

4) Constraint enforcement (0–2)

Question: Does the system have teeth (constraints + defaults) and are they enforced?

  • 0: Constraints are optional; enforcement is reminders/shame; defaults don’t exist.
  • 1: Some constraints are enforced but exceptions are frequent or invisible.
  • 2: Constraints are enforced; defaults trigger; exceptions are explicit and rare.

Test prompt:

  • “What happens when people avoid the decision or skip the artifact?”

Score: __ / 2

5) Misuse resistance (0–2)

Question: Is misuse recognized and mitigated, or is it dominating usage?

  • 0: The system is dominated by misuse (reporting theater, ritual, gaming, capture).
  • 1: Misuse exists; mitigations are partial or informal.
  • 2: Misuse is anticipated; mitigations exist in artifacts/constraints/authority.

Misuse lenses:

  • busy-team weakening
  • leadership reporting/control pressure
  • political capture (veto/shield/weapon)

Score: __ / 2

Total Score

Total: __ / 10

Decision Rule

Choose one outcome (mandatory):

  • 8–10 → Keep System is fit, enforced, and producing decisions.

  • 5–7 → Modify System is partially working; change one lever (see below).

  • 3–4 → Subordinate or Redesign System likely collides with others, lacks enforcement, or targets the wrong failure.

  • 0–2 → Remove System is ritual/theater or obsolete. Retire it; replace only if a real gap remains.

Decision: keep / modify / subordinate / remove

Modification Levers (Pick One)

If you chose modify, choose exactly one primary lever first.

Lever A — Artifact upgrade

Use when:

  • artifacts exist but don’t drive decisions

Moves:

  • add “decision changed” field
  • add owner + timestamp
  • add explicit next action
  • reduce artifact scope (make it harder to fake)

Lever B — Constraint + default

Use when:

  • decisions are avoided or deferred

Moves:

  • add timebox + default outcome
  • add scope/WIP cap + displacement rule
  • add gate (“cannot proceed unless…”)

Lever C — Authority boundary

Use when:

  • system relies on consensus or persuasion

Moves:

  • define decider
  • define consult vs inform
  • define escalation path + default resolution

Lever D — Cadence / trigger change

Use when:

  • system runs too often (ritual) or too rarely (stale)

Moves:

  • shift from time-based to event/threshold-based triggers
  • shorten cycles to increase learning
  • remove meetings unless artifact is produced

Lever E — Unit-of-analysis correction

Use when:

  • system was copied across scales and collapsed

Moves:

  • redesign artifacts for the correct scale (interfaces/contracts at multi-team)
  • reduce scope to where enforcement exists
  • add precedence rules for cross-scale coordination

Collision & Landscape Check (Fast)

Answer these every time:

  • Does this system collide with another system’s artifact?

  • ☐ Yes ☐ No If yes: name the other system and define a precedence rule or subordinate one.

  • Is it duplicating a decision already “owned” elsewhere?

  • ☐ Yes ☐ No

  • What would we remove if we keep this?

Retirement Checklist (If Removing)

If you chose remove, do these three steps to avoid chaos:

  1. Name what decision it was supposed to optimize:

  2. Name what artifact (if any) will remain as historical record:

  3. Name what replaces it, or explicitly accept the gap for now:

Add a sunset date if you’re not removing immediately:

  • Sunset date:
  • Owner of retirement:

“Healthy System” Quick Tell

A healthy system has:

  • a named failure
  • a named decision
  • an inspectable artifact
  • an enforced constraint with a default
  • known misuse modes and mitigations

If you can’t say all five in two minutes, the system is not healthy.