Automation Bias¶

The human-factors regularity in which operators over-weight an automated system's outputs and under-weight contradicting evidence, so the human-automation team can perform worse on rare anomalies than the unaided operator would — through commission errors (acting on a false recommendation) or omission errors (staying passive when the system is silent).

Core Idea¶

Automation bias is the regularity that operators supervising automated decision-support over-weight the system's outputs and under-weight contradicting evidence, producing errors that can exceed unaided operation. It has two failure modes: commission errors (acting on a false recommendation despite contradicting evidence) and omission errors (staying passive because the automation did not flag a real problem). Highly reliable automation acquires "machine-says-so" authority, displacing the operator's independent evaluation.

Scope of Application¶

Automation bias lives across human-factors subfields sharing one substrate — a human supervising an authoritative automated source under divided attention, with a rare anomaly against a reliable common case.

Aviation human factors — instrument cross-check failure, autopilot-mode confusion, GPS over-reliance.
Clinical decision support — radiologists agreeing with wrong AI flags; missed unflagged interactions.
Process and supervisory control — dispatchers drifting into passive supervision, then failing at anomalies.
Autonomous-vehicle supervision — driver inattention in conditions the system was never rated for.
AI assistants for knowledge work — over-trust in LLM outputs in programming, law, and writing.

Clarity¶

Naming automation bias makes legible a failure that automation actively creates: a team can perform worse on anomalous cases than the unaided operator, even when the automation is individually more accurate. It reframes the unit of analysis from component to team, and warns that a more reliable system can deepen the bias by earning more unwarranted authority. It also separates commission from omission, and automation bias proper from its companions — skill atrophy and alarm fatigue.

Manages Complexity¶

Case by case, these failures look nothing alike — a pilot on a stale display, a radiologist accepting a wrong flag, a dispatcher passive through a fault. The construct reduces the standing question to four trackable quantities: common-case reliability, operator load, automation salience, and whether the anomaly arrives with the automation asserting-false or silent. That last classifier sorts the incident into commission or omission and, with it, the applicable intervention class — without re-modeling the operator's full attention-and-trust dynamics.

Abstract Reasoning¶

The construct licenses diagnostic reasoning — from a team underperforming its unaided baseline back to mis-set trust, then sorting by the assert-false-versus-silent signature and disentangling trust-miscalibration from skill atrophy from alarm fatigue. Its interventionist moves attach a predicted direction to each lever (uncertainty estimates, foregrounded contradicting channels, manual-mode practice), including the counterintuitive non-monotonic prediction that a more reliable component can worsen the team. It also supports boundary-drawing (requires a human in the loop with rare-event structure) and order-of-events forecasting.

Knowledge Transfer¶

Within human-factors research the construct transfers as mechanism, but its home is one substrate — a human supervising an authoritative automated source under divided attention against rare anomalies — deployed across aviation, clinical, process-control, vehicle, and now AI-assistant settings; the commission/omission taxonomy, four parameters, and non-monotonic prediction carry intact. Remove the human or the rare-event structure and there is no automation bias — the failure is plain component error. What little is portable belongs to the parent authority_bias (an authoritative source earning more credence than warranted), plus thinner bias and attention; "automation bias" itself stays home-bound.

Relationships to Other Abstractions¶

Current abstraction Automation Bias Domain-specific

Parents (1) — more general patterns this builds on

Automation Bias is a kind of Authority Bias Domain-specific

Automation bias is authority bias specialized to an automated source that has acquired machine-says-so authority for a human supervisor.

Hierarchy path (1) — routes to 1 parentless root

Automation Bias → Authority Bias → Bias

Neighborhood in Abstraction Space¶

Automation Bias sits in a sparse region of the domain-specific corpus (63^rd percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (309 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-07-12