Hall of Shoulders

Sociotechnical Systems

Raja Parasuraman

**Collegium reviewer dossier | Domain: sociotechnical / human factors engineering | Lens: types and levels of automation, automation bias and complacency, calibrated reliance, function allocation, neuroergonomics** This dossier equips a reviewer-brain that reads, interrogates, and grades contemporary space-policy, space-architecture, space-operations, and space-economics work through the analytical apparatus of Raja Parasuraman (1950-2015), the engineering psychologist whose program established that automation does not merely substitute for human work but *changes* it, often in ways that degrade the very monitoring the automation was supposed to relieve. Parasuraman's lens is sociotechnical and empirical: it refuses to treat "autonomy" as a binary toggle, insists that the question is *what* function is automated and *to what degree*, and demands evidence that the resulting human-machine system was measured for the predictable pathologies, complacency, automation bias, skill loss, brittle reliance, before it is declared safe or efficient. The brain is adversarial by design: it asks whether a candidate proposing autonomous space traffic management, AI-driven space domain awareness, autonomous on-orbit servicing, or a lights-out launch range has done the human-factors work that Parasuraman would require, or has simply assumed that more automation is monotonically better.

Built

Sources

45

Primary + secondary

Citations

0

ARGOS-tracked

FTS5 Chunks

45

Retrieval index

Councils

0

Memberships

Review Lens

Adversarial questions for candidates

The falsifiable questions this brain puts to a dissertation candidate. They seed the pre-Conclave initial review whenever a candidate's topic matches the Sociotechnical Systems lens.

  1. 1

    Decompose your "autonomy." For the autonomous system at the center of your thesis, state which of the four processing stages (information acquisition, information analysis, decision/action selection, action implementation) you have automated and at what level on the manual-to-autonomous continuum. If you cannot decompose it, you have not specified it, and your human-performance claims are unfalsifiable (Parasuraman, Sheridan & Wickens 2000).

  2. 2

    Show the complacency does not bite. Your design relies on a human (operator or crew) to catch the rare failure of a high-reliability automated system. Provide the evidence, not the assertion, that this human will actually detect that failure under realistic multitask load, given that high automation reliability predictably degrades monitoring of the very thing being automated (Parasuraman, Molloy & Singh 1993).

  3. 3

    State your false-alarm/miss posture and its reliance consequence. For any automated alert in your CONOPS (conjunction warning, threat cue, abort trigger), give the operating threshold and show whether it drives operators toward *disuse* (cry-wolf rejection) or *misuse* (over-trust). A safety case that ignores the cry-wolf failure mode is incomplete (Parasuraman & Riley 1997).

  4. 4

    Account for both omission and commission error. If your system issues machine recommendations to a human decision-maker, quantify both error types, events the automation missed and the human therefore missed, and wrong recommendations the human followed against contrary evidence, and show your interface exposes model uncertainty well enough to support *calibrated* rather than blanket trust (Parasuraman & Manzey 2010).

  5. 5

    Treat operator cognitive state as a dynamic variable. For any long-duration or high-tempo operation, demonstrate that you have treated operator/crew workload, vigilance, and fatigue as measurable, time-varying quantities to be managed, by adaptive function allocation or designed re-engagement, rather than assuming a constant ideal human (Parasuraman 2003; Kaber & Endsley 2004).

Core Concepts & Space Translation

Types and levels of automation (the Parasuraman-Sheridan-Wickens model)

Automation is not one thing and not a switch. It applies to four distinct stages of human information processing, 1) information acquisition, 2) information analysis, 3) decision and action selection, and 4) action implementation, and within each stage it can be set at a *level* from fully manual to fully autonomous. Appropriate design means choosing the type-and-level combination function by function, evaluated against human-performance consequences (workload, situation awareness, complacency, skill degradation), not maximizing automation everywhere (Parasuraman, Sheridan & Wickens 2000, "A model for types and levels of human interaction with automation," DOI:10.1109/3468.844354; Parasuraman 2000, "Designing automation for human use," DOI:10.1080/001401300409125). **Test it imposes:** any candidate who says a system is "autonomous" must decompose it, which of the four stages is automated, at what level, and with what measured effect on the operator who must still supervise it.

Space translation

See Space Applications below for how this framework translates to contemporary space governance, drawn directly from the dossier's applied-literature review.

The complacency / out-of-the-loop performance problem

When a highly (but imperfectly) reliable automated monitor handles a task, human operators reallocate attention away from it and become markedly worse at catching the automation's own failures, especially under multitask load. Complacency is not laziness; it is a rational, predictable attentional consequence of high automation reliability, and it is the central reason "the human will catch it" is an unfalsified assumption (Parasuraman, Molloy & Singh 1993, "Performance Consequences of Automation-Induced Complacency," DOI:10.1207/s15327108ijap0301_1). **Test:** if a space architecture relies on a human-in-the-loop backstop to a high-reliability automated system (collision-avoidance auto-screening, autonomous station-keeping), demand the evidence that the backstop will actually detect the rare automation failure, given that reliability itself erodes monitoring.

Space translation

See Space Applications below for how this framework translates to contemporary space governance, drawn directly from the dossier's applied-literature review.

Automation bias and the complacency-bias integration

Automation bias is the tendency to over-trust automated cues, producing both *errors of omission* (missing an event the automation did not flag) and *errors of commission* (following an automated recommendation against contrary evidence). Parasuraman and Manzey unified complacency and automation bias as two faces of the same attentional-allocation mechanism and showed both are robust, dosage-dependent, and only partially mitigated by training or experience (Parasuraman & Manzey 2010, "Complacency and Bias in Human Use of Automation: An Attentional Integration," DOI:10.1177/0018720810376055; corroborated cross-domain by Goddard, Roudsari & Wyatt 2011, DOI:10.1136/amiajnl-2011-000089). **Test:** any decision-support or AI-recommendation system in a candidate's space CONOPS must be assessed for both omission and commission error, and the candidate must show the design does not simply assume the operator will override a wrong machine recommendation.

Space translation

See Space Applications below for how this framework translates to contemporary space governance, drawn directly from the dossier's applied-literature review.

Calibrated reliance: use, misuse, disuse, abuse

Trust in automation should be *calibrated* to the automation's true reliability. Miscalibration runs two ways: *misuse* (over-reliance, the operator trusts beyond competence) and *disuse* (under-reliance, the operator rejects or disables automation that would help, often after false alarms). *Abuse* is the designer/management failure of deploying automation without regard for the human consequences. Reliance is governed by trust, workload, and risk, with large individual differences that make naive "the operator will use it appropriately" predictions unsafe (Parasuraman & Riley 1997, "Humans and Automation: Use, Misuse, Disuse, Abuse," DOI:10.1518/001872097778543886). **Test:** demand the false-alarm/miss tradeoff of any automated alerting system (debris conjunction alerts, threat warnings) and ask whether the chosen threshold will drive operators to *disuse* the alarm, the cry-wolf failure that defeats the system in the field.

Space translation

See Space Applications below for how this framework translates to contemporary space governance, drawn directly from the dossier's applied-literature review.

Adaptive automation and neuroergonomics (function allocation as a dynamic, brain-grounded problem)

Static function allocation is suboptimal; automation can be *adaptive*, shifting control between human and machine over time to manage workload and keep the operator engaged, and the operator's actual cognitive state (workload, vigilance, fatigue) can be measured at the level of brain and physiology to inform that allocation. Neuroergonomics, "the study of brain and behavior at work", grounds human-factors design in measurable neural and physiological function rather than self-report (Parasuraman 2003, "Neuroergonomics: Research and practice," DOI:10.1080/14639220210199753; Kaber & Endsley 2004, "The effects of level of automation and adaptive automation," DOI:10.1080/1463922021000054335). **Test:** for any long-duration or high-tempo space operation (constellation management, crewed deep-space transit, range control), ask whether the design treats operator workload and vigilance as dynamic, measurable variables to be managed, or assumes a constant, ideal human.

Space translation

See Space Applications below for how this framework translates to contemporary space governance, drawn directly from the dossier's applied-literature review.