Skip to content

Decision Latency Scorecard

A measurement audit — instantiates Coupling Latency and Time-Delay Effects

Breaks a decision loop into sensing, analysis, approval, handoff, execution, and feedback stages and times each one, so the slowest stage stops hiding inside a single "we're too slow".

A Decision Latency Scorecard decomposes an organization's sense-decide-act loop into its named stages — sensing, analysis, approval, handoff, execution, feedback — and records the elapsed time actually spent in each. What makes it this mechanism and not its siblings is that it produces measured latency, stage by stage, for a human decision loop: it answers "where does the time actually go?" with numbers rather than a diagram or a target. Its payoff is localization — it reveals whether the drag is detection-to-decision or decision-to-action, because a reorganization aimed at the wrong stage buys nothing.

Example

An IT org's change-approval pipeline feels glacial, and everyone blames "the CAB" (change advisory board). A scorecard timestamps one quarter of changes at each stage: a monitoring alert fires → an engineer files a change (sensing→analysis: ≈2 hours), the change waits for the weekly board (approval: ≈6 days), the board meets and approves (analysis: ≈20 minutes), the ticket is handed to the ops queue (handoff: ≈1 day), the change is deployed (execution: ≈1 hour), and outcome is confirmed (feedback: ≈2 days). The numbers overturn the story: the board's deliberation is trivial; the killer is the ≈6-day wait for the board to convene plus the feedback lag. Re-run the next quarter, and the scorecard also shows whether that wait is creeping up as change volume grows — turning a one-time audit into a drift signal. The fix that follows (a daily lightweight approval lane) targets the measured stage, not the blamed one.

How it works

  • Fix the stage taxonomy first. Agree on the loop's stages and the exact events that begin and end each, so two runs are comparable and no time falls between stages.
  • Timestamp real instances, not estimates. Pull start/end times from tickets, logs, or calendars for a sample of actual decisions; the scorecard's authority comes from measured elapsed time, not recalled effort.
  • Report the profile, not a single number. Present per-stage latency — typically median and tail — so the dominant stage is unmissable and the long-tail cases show up separately from the typical ones.
  • Re-run on a cadence to expose drift. Repeating the measurement turns it into a monitor: rising latency in a stage is visible before it becomes a crisis.

Tuning parameters

  • Stage granularity — coarse (three stages) versus fine (a dozen sub-handoffs). Finer pinpoints the offender but costs more instrumentation and risks slicing time so thin the boundaries are arbitrary.
  • Percentile focus — median versus p95/max. Optimizing the median can leave a brutal tail untouched; pick the statistic that matches what the coupling actually suffers from.
  • Sample vs. census — a hand-timed sample versus full instrumentation. A sample is cheap and immediate; a census supports the drift monitor but requires the pipeline to emit timestamps.
  • Re-measure cadence — one-shot audit versus standing dashboard. More frequent catches drift sooner but competes for the same attention the scorecard is trying to free.

When it helps, and when it misleads

Its strength is that it refuses to let "we're too slow" stay a single blob: it splits total loop latency into stages and names the one worth fixing, and by repeating it turns latency into something you can watch rather than rediscover. It maps naturally onto any explicit sense-decide-act framing of a decision cycle.[1]

Its failure modes are measurement failures. Time spent waiting between stages is the easiest to miss and often the largest, so a taxonomy that only times "active" work systematically understates the loop. Chosen carelessly, the statistic misleads — a good median can hide a lethal tail. And a scorecard is trivially gamed or run backwards: teams optimize the stage that is measured, or the audit is produced to justify a reorg already decided. The discipline is to timestamp the gaps as rigorously as the work, agree the statistic before seeing results, and treat the scorecard as a diagnosis to act on, not a scoreboard to win.

How it implements the components

The scorecard fills the two measurement-side components a timing audit can genuinely produce:

  • latency_profile — its core output: measured elapsed time per stage, as a distribution rather than a point, exposing both the dominant stage and the tail.
  • latency_drift_monitor — re-run on a cadence, the same instrument tracks whether stage latencies are trending up, converting a snapshot into an early-warning signal.

It does not draw the loop's feedback structure (coupled_interaction_boundary, timing_chain_map) — that's the Causal Loop Delay Map — nor does it set a target or consequence for the latency it measures (delay_bounded_escalation_threshold), which belong to the Delay Budget Table and Latency SLO or SLA.

References

[1] The sense–decide–act decomposition mirrors the OODA loop (observe, orient, decide, act) associated with John Boyd; the scorecard's contribution is timing each leg rather than treating the cycle as instantaneous. ↩