Decision Latency
Decision latency is the time between signal detection and action execution.
Definition
Core meaning
Decision latency is the elapsed time between a signal becoming detectable and the resulting action taking effect. It is measured end to end, which matters because the delay is almost never in the part of the system anyone is optimising.
In practice
Where the time actually goes
Teams usually assume latency lives in evaluation and invest in faster inference. Instrumenting the full path normally shows the compute is a rounding error next to the waiting.
- Detection lag: how long before anything observes the condition at all
- Queue time: how long the signal waits before evaluation begins
- Evaluation time: the part everyone measures, usually the smallest
- Approval time: waiting for a human who is asleep, in a meeting, or off shift
- Execution time: how long the acting system takes to apply the change
Boundaries
Commonly confused with
Latency in the operational sense is not the latency most engineering dashboards report.
- Not system latency: that measures a request, this measures a decision
- Not inference time: model speed is one small component of the total
- Not cycle time: cycle time measures a whole process, latency measures the decision within it
- Not response time: response is when someone replies, latency ends when the state changes
Diagnostic
How to measure yours
Pick a recurring decision and timestamp four moments. Most operations have never measured this and are surprised by which stage dominates.
- When did the condition first become observable in any system?
- When did a human or system first notice it?
- When was the decision made?
- When did the resulting action take effect?
Category link
How OADI reduces it
The architecture attacks the waiting rather than the computing. Continuous monitoring collapses detection lag, automated evaluation removes queue time, and routing with pre-granted authority removes the approval wait — which is usually the largest single component in any operation that runs outside business hours.
FAQ
Frequently Asked Questions
Is lower decision latency always better?
No. Latency should be matched to how fast the underlying condition changes and how expensive a wrong decision is. Deciding faster than you can detect reliably just means deciding on less evidence. For irreversible or high-value actions, a deliberate delay that allows confirming evidence to arrive is a design feature, not a defect.
What usually dominates decision latency?
Waiting for a human, and specifically waiting for a human who is not currently working. An operation with a five-minute evaluation and a decision that sits until someone reviews it the following morning has roughly fourteen hours of latency, none of which is technical. Measure before optimising anything.
How do we reduce latency without removing human judgement?
Pre-authorise the routine band. Rather than requiring approval for every decision, define the conditions under which action proceeds automatically — by value, confidence, and reversibility — and route only what falls outside that band to a person. Judgement moves from approving each case to setting where the boundary sits.
Operational Context
See how this concept appears in real operational systems
The audit maps this concept to the decisions, signals, and execution pathways inside your operating environment.
Keep Exploring
Related concepts and next steps
Suggested Reading
Related reading
Systems that turn operational data into automated decisions.
An assessment that turns category understanding into an implementation path.
The operating model for converting signals into decisions and decisions into execution, taught as a cohort curriculum.