Skip to content

Multi-Level KPI Review

Metric / dashboard — instantiates Nested Feedback Alignment

Reviews local, intermediate, and system-level indicators together so a correction that improves one level is checked for consequences at the others.

A Multi-Level KPI Review is a recurring decision forum in which the indicators owned by each level are laid side by side and any proposed correction is tested against the targets of the other levels before it is approved. Its defining idea is adjudication, not display: the review exists to catch the move that makes a unit's own number better while quietly degrading a neighbor's or the system's, and to state — when two levels genuinely conflict — which target has priority this time and why. Where a dashboard shows a metric at many grains, this review takes several different metrics that belong to different levels and decides whether a correction proposed at one is safe for all.

Example

A regional hospital network runs a monthly KPI review with three levels in the room. At the unit level, the emergency department reports median door-to-provider time creeping up and proposes a fix: admit borderline patients faster to clear the waiting room. At the hospital level, the metric is inpatient bed utilization, already at 94%. At the system level, the number is 30-day readmission rate and total cost per episode. On its own the ED's proposal is obviously good — shorter waits. Reviewed against the other two levels, it is dangerous: faster admits push utilization past the safe ceiling and, because some of those borderline patients did not need admission, lift readmissions and cost.

The review does not simply veto the ED. It applies the network's standing priority rule — patient-safety and system solvency outrank a single department's throughput metric — and reshapes the correction: the ED gets a fast-track discharge lane and a rapid-assessment unit instead of a lower admission threshold. The output is a correction that improves the local number without spending the hospital's beds or the system's readmission budget, plus a note in the cross-scale log to watch utilization next month for the second-order effect.

How it works

  • Bring the levels' own targets, not one shared metric. Each level arrives with the indicator it is actually accountable for; the review does not force them onto a single KPI, because their targets legitimately differ.
  • Test every proposed correction against the other levels. Before a fix is approved, the review asks the explicit question: does improving this number move any other level's number the wrong way?
  • Adjudicate real conflicts by rule, not rank. When two targets genuinely collide, a written priority rule decides — weighing safety, reversibility, evidence quality, and system consequence — rather than defaulting to whoever is most senior in the room.
  • Log the second-order watch. Approved corrections that could have a cross-scale effect are recorded with the neighbor metric to monitor, so next cycle checks whether the predicted harm materialized.

Tuning parameters

  • Review cadence — how often the forum meets. Frequent reviews catch cross-scale harm early but consume leadership attention and can thrash; infrequent ones let a bad correction run for a full cycle before anyone checks its neighbors.
  • Priority-rule specificity — how precisely the conflict rule is written. A sharp rule resolves collisions fast but can misfire in a case it never anticipated; a vague one preserves judgment but reopens the same fight every meeting.
  • Correction-approval scope — which corrections must pass the cross-level check versus which a level may make autonomously. Widen it and nothing local moves without central sign-off; narrow it and a harmful correction slips through un-reviewed.
  • Second-order watch list length — how many neighbor metrics each approved correction is tracked against. More coverage catches subtle risk transfer but dilutes attention across too many watch items.

When it helps, and when it misleads

Its strength is that it converts "every level optimizing its own KPI" from a recipe for cross-scale harm into a governed trade-off with an explicit priority behind it. It is the direct defense against local metric gaming — Goodhart's law, where a measure that becomes a target stops measuring what it did — because a gamed local number is caught the moment it is checked against the level it was stolen from.[n1]

Its failure mode is theater of a subtler kind than an idle dashboard: a review that looks at several levels' KPIs but never actually blocks or reshapes a correction is just a status meeting, and it launders local optimization with the appearance of oversight. It also tilts toward the highest level in the room if the priority rule is weak, quietly re-centralizing until local responsiveness is lost. The guarding discipline is to require that every approved correction name the neighbor metric it was checked against — a review that never reshapes a proposal is not doing its job.

How it implements the components

  • target_alignment_check — its core function: it lays each level's target beside the others and makes their conflicts explicit instead of letting them collide unseen.
  • conflict_resolution_priority_rule — when targets genuinely clash, it applies a written rule that weighs safety, reversibility, and system consequence to decide which prevails this cycle.
  • cross_scale_effect_monitor — it logs approved corrections against the neighbor metric they might disturb and checks the following cycle whether the harm appeared.

It does not perform signal_translation_rule or aggregation_window — carrying one metric between aggregate and local grain is the job of Aggregation/Disaggregation Dashboard. That dashboard shows a signal across scales; this review decides between different levels' targets.

Editorial Notes

Form Classification

Form family: Assessment, Review & Assurance

Rationale: The review evaluates a proposed correction against indicators at every relevant level and records cross-level effects before approval.

Nearest alternative: Decision, Gate & Allocation — Conflict rules can determine approval, but the defining operation is evidence review of consequences across levels.

Review outcome: Adjudicated after independent review; high confidence.

Origin Attribution

Primary origin: Organizational & Management Science

Origin pattern: Cross-disciplinary synthesis

Present-day reach: Multi-domain

Rationale: Reviewing key performance indicators across nested organizational levels originates in management control and performance-management practice.

Related originating lineages:

Review resolution: Both independent reviews agree on primary origin organizational_management; reconciliation resolves secondary fields (alternate_origin_disagreement, encyclopedia_synthesis_disagreement). Alternate origins retained (accounting_auditing, systems_cybernetics, data_science) are the union of reviewer-supported formative lineages with explicit rationales, not a list of later application domains. Present-day breadth is represented separately as domain_reach=multi_domain; origin_mode=cross_disciplinary_synthesis records the historical relationship among lineages. Confidence is conservatively reconciled to high, and encyclopedia_synthesis=true preserves either reviewer's finding that the encyclopedia generalized the mechanism.

Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.

Review outcome: Reconciled after independent review; high confidence.

Notes

[n1] Goodhart's law — "when a measure becomes a target, it ceases to be a good measure." In a nested system the failure is local: a unit optimizes its own KPI in a way that degrades the level above it, which is exactly the move a cross-level review is built to catch.