Cognitive Systems Engineering: Human Factors, Situation Awareness and Decision Support

Cognitive systems engineering treats the human operator not as an external user of a technical product but as an active component of a sociotechnical system that includes information, automation, procedures, teams, time pressure, organizational constraints, and the physical environment. In this view, “is the interface usable?” is only one question. More consequential questions concern which cues practitioners rely on, what they are trying to understand, how they manage uncertainty, which decisions they make under time pressure, which cognitive functions automation takes over, and how human and technical components adapt together when the system enters an unexpected state.

This course integrates Cognitive Task Analysis, Cognitive Work Analysis, Naturalistic Decision Making, situation awareness, Ecological Interface Design, and resilience engineering into a single engineering framework. The objective is not to explain human behavior through detached psychological terminology. The objective is to derive findings that can shape requirements, architecture, interface design, automation, verification, and operations in complex and critical systems.

The visual and interaction-design aspects of human-machine interaction are covered in greater depth in UI/UX Engineering in Web Applications. System lifecycle, requirements, design, and quality are connected in Software Engineering; verification and validation in Software Test Engineering; safety-critical human-machine contexts in Avionics Systems and Unmanned Aerial Vehicles; and evidence-grounded generative AI in Retrieval-Augmented Generation.

Unit 1: The Scope of Cognitive Systems Engineering

From user to joint cognitive system

Conventional interaction design often models a person as the user of a service provided by a technical system. That model is incomplete in high-tempo or critical work. The operator, software, sensors, databases, automation, procedures, and other team members may form a joint cognitive system oriented toward a shared operational objective. Machines acquire part of the information, humans interpret part of it, some decisions follow automated rules, and others require expert judgment.

environment / events
       ↓
sensors and data sources
       ↓
technical system ── automation
       ↓                 │
information displays     │
       ↓                 │
human / team ←───────────┘
       ↓
decision and action
       ↓
new environmental state

Performance in this loop depends on more than computational correctness. The right information must be visible at the right time, stale data must be recognizable, alarm load must remain manageable, operators must be able to interpret system state, and the boundaries of automation must remain intelligible.

Human error is not a complete explanation

Labeling an outcome as “operator error” often terminates analysis rather than beginning it. Cognitive systems engineering examines which information was available, which goals were in conflict, what time and resource constraints existed, how automation behaved, whether procedures matched work as actually performed, and what uncertainty existed at the decision point.

This does not assume that humans are infallible. It places error probability in system context. The same practitioner may behave differently under a different information layout, workload, interruption pattern, or time budget. Reliability is therefore not only a training or discipline issue; it is also a system-design issue.

Complexity is not the same as difficulty

A technically complex system can present an intelligible operational model. A technically simple task can become cognitively difficult when information is fragmented and responsibilities are ambiguous. Cognitive engineering therefore focuses less on component count and more on the mental model and coordination burden required to achieve the goal.

Unit 2: Human Cognition and Expertise in Complex Work

Attention is limited

Operational systems can produce more signals than a person can attend to at once. The fact that information is technically present on a screen does not mean that it will be perceived at the moment it matters.

displayed ≠ noticed
noticed ≠ correctly interpreted
interpreted ≠ correctly projected
projected ≠ appropriate action selected

This distinction is fundamental when designing dense dashboards, alert streams, supervisory-control displays, and AI-assisted workspaces.

Working memory and externalization

Limited working-memory capacity makes long internal state chains fragile. Good systems externalize intermediate state: the selected object, previous step, timestamp, source, uncertainty, and result of a completed action remain visible. The practitioner can then spend cognitive resources on the problem rather than remembering interface state.

Mental models

Operators do not merely read values; they develop a mental model of how the system behaves. A rising metric, a delayed component, or a particular alert sequence has meaning inside that model. If an interface presents only surface values and hides functional or causal relationships, practitioners become more dependent on memorized procedures.

Expertise and pattern recognition

Experts do more than possess additional facts. They often select meaningful cues faster, organize cases around deeper structures, detect atypical patterns earlier, and project likely outcomes more effectively. This tacit knowledge is difficult to capture through ordinary requirements interviews because experts may experience it as an unremarkable part of competent work.

Unit 3: Cognitive Task Analysis

Cognitive Task Analysis (CTA) seeks to uncover the perceptual, knowledge, decision, reasoning, and problem-solving demands required for successful performance rather than limiting analysis to observable task steps.

Difference from conventional task analysis

A conventional decomposition might produce:

open record
→ inspect fields
→ compare
→ decide
→ save result

CTA investigates what is hidden inside “compare” and “decide”:

• Which cues matter?
• Which cue can be misleading?
• Which anomaly does an expert notice first?
• What additional information is sought in a difficult case?
• When is deviation from the normal procedure justified?
• Which uncertainty is acceptable and which is not?
• Which indicators are checked after the action?

Engineering outputs of CTA

The objective is not to produce a psychological profile. Useful engineering outputs include cognitive requirements, critical cues, decision points, traps, information needs, and training needs.

“Expert users are experienced” is a weak result. “Experts first test whether an apparent inconsistency can be explained by timestamp and source latency, but the two values are shown in separate views” is a direct design input.

Preparation and framing

A CTA effort should focus on cognitively difficult, high-consequence, or expertise-sensitive parts of work rather than attempting to model everything. Participant selection should capture meaningful differences among highly experienced, intermediate, and novice practitioners.

Concept mapping

Concept maps can externalize how domain concepts are related in expert knowledge. Their value is not the visual diagram itself but the operational distinctions they reveal: which relations matter, under which conditions, and how those relations change interpretation.

Incident-based interviewing

A generic question such as “how do you do your job?” often elicits an idealized procedure. Reconstructing difficult or unusual real incidents can reveal more. The analyst builds a timeline, locates decision points, and probes cues, expectations, goals, alternatives, and the role of experience.

Critical Decision Method

The Critical Decision Method (CDM) is an incident-based CTA method for examining challenging events in detail. An engineering use of CDM reconstructs the event, identifies critical decision points, and explores the cues, goals, expectations, alternatives, and experience involved at each point.

Useful probes include:

• What was the first change you noticed?
• How did you know this situation was not routine?
• Which missing information could have changed your decision?
• What would a less experienced practitioner likely miss here?
• What other action did you consider?
• What told you that the chosen action was working?

Knowledge Audit

A Knowledge Audit systematically searches for dimensions of expertise such as pattern recognition, anomaly detection, use of prior cases, perceptual discriminations, opportunities, mental projection, and workarounds. The most valuable result is often a cognitive requirement that was absent from the original functional specification.

Unit 4: Cognitive Work Analysis

CTA and CWA are not the same analysis

CTA and CWA often complement each other, but they answer different questions. CTA seeks to expose the cognitive content of expert performance in a particular activity, whereas CWA models constraints that are more persistent than a specific person, procedure, or interface. The distinction matters when an existing application is redesigned. CTA alone may accidentally freeze workarounds that experts developed around the current tool into the new design. CWA alone may fail to expose the cues, shortcuts, and coordination problems that shape real expert performance.

A useful relationship is:

CTA  → how do experts accomplish difficult work today?
CWA  → which goals and constraints remain stable in the work domain?
                         ↓
                 shared design requirements

Method selection should therefore be driven by the uncertainty that must be reduced, not by a belief that one technique is universally more advanced.

Design value of constraint-based reasoning

Procedures prescribe a particular route through work. Constraints define the boundary of acceptable behavior. An unexpected event may have no prewritten procedure, while physical, functional, safety, or organizational constraints still remain valid. A major design value of CWA is therefore to support representations from which people can understand boundaries rather than merely follow the next prescribed step.

Capacity limits, minimum data freshness, separation of duties, authorization thresholds, and resource dependencies should not remain invisible backend checks when they materially affect operator decisions. They need to become perceptible at an appropriate level of abstraction.

Cognitive Work Analysis (CWA) asks a broader question than how a particular person follows today's procedure: what goals, functions, constraints, possibilities, and strategies exist in the work domain, and what behavior must remain possible under different conditions?

CWA is therefore particularly valuable in complex sociotechnical systems where unexpected conditions matter. Instead of automating the current procedure step by step, it seeks to identify relatively stable domain constraints and the space of possible strategies.

Five complementary dimensions

CWA is commonly described through five complementary dimensions:

1. Work Domain Analysis
2. Control Task Analysis
3. Strategies Analysis
4. Social Organization and Cooperation Analysis
5. Worker Competencies Analysis

These are not a linear software-development lifecycle. They are different constraint perspectives on the same system.

Why constraints can outlive procedures

A procedure captures how work is performed under a current technical and organizational arrangement. Procedures change when technology, regulation, or organization changes. Work-domain constraints can be more stable: capacity limits, conservation relationships, safety boundaries, authority separation, or physical dependencies may remain relevant across multiple interface generations.

Unit 5: Work Domain Analysis and the Abstraction Hierarchy

Abstraction and decomposition are different dimensions

The abstraction hierarchy explains why, what, and how relations, while the part of the system under discussion is a separate decomposition dimension. The same functional purpose can be considered at whole-system, subsystem, or component level. Keeping the two dimensions separate prevents a large system from collapsing into one enormous diagram.

                         decomposition
                 system → subsystem → component
abstraction   purposes
    ↓         values
              functions
              processes
              physical resources

This is not an inventory. Every cell does not need to be populated. The model is valuable when means–ends links across levels explain engineering choices.

Validating the model

A work-domain model should not remain a conceptual diagram produced by the analyst alone. Domain practitioners can challenge it with concrete questions. If a high-level purpose is removed, can the reason for lower-level functions still be explained? If a physical resource disappears, can affected functions be traced? Are alternative means to the same purpose visible? Can both normal and degraded operation be expressed in the model?

If the model cannot answer these questions, adding more boxes is usually less useful than checking whether the abstraction levels or relationships are wrong.

Work Domain Analysis

Work Domain Analysis connects purposes, priorities, functions, processes, and resources. The objective is not to prescribe a procedure but to represent why the system exists, what constitutes successful operation, which functions make success possible, and which technical or physical resources realize those functions.

Abstraction hierarchy

One widely used representation is the abstraction hierarchy. Terminology varies by domain, but a typical structure is:

functional purposes
       ↓
values and priority measures
       ↓
purpose-related functions
       ↓
object-related processes / functions
       ↓
physical objects and resources

Higher levels answer more of the “why?” question; lower levels answer more of the “how?”. An operator can interpret a sensor value not merely as a physical measurement but in terms of the function and purpose it supports.

Means-end relations

Vertical links describe how a lower-level element serves a higher-level purpose and which lower-level means can realize that purpose. These relations are particularly useful when an interface must expose the functional significance of a local value.

Example: a generic data-processing service

Purpose
Produce trustworthy results on time
        ↓
Criteria
Accuracy / latency / capacity / traceability
        ↓
Functions
Accept / validate / process / persist / serve
        ↓
Technical processes
Queue / inference / database / cache / network
        ↓
Resources
Servers / storage / links / processes

In this representation, “CPU 80%” is not interpreted in isolation. It is related to incoming load, queue growth, processing capacity, and the service objective.

Unit 6: Control Tasks, Decision Ladders, and Strategies

The decision ladder is not a user-flow diagram

The decision ladder should not be turned into a mandatory screen sequence. Experienced operators do not traverse every step in every event. A familiar cue may directly activate a known action rule, whereas a novel or ambiguous situation may require goal formulation, option generation, and evaluation. Design should not force every user through every rung; it should make the information required for a skipped cognitive link available when deeper reasoning becomes necessary.

From information requirement to interface requirement

A statement such as “the user shall understand the situation” is not verifiable. The required variables, relationships, and time horizon can instead be specified. Assessing resource pressure, for example, may require not only current utilization but also trend, capacity boundary, queue growth, and the most recent configuration change. Cognitive analysis then becomes a source of measurable system requirements rather than a separate human-factors report.

Strategy switching and its cost

The same goal may admit a fast approximate strategy and a slower but more reliable strategy. Selection can change with time pressure, data quality, workload, and consequence. If a system supports only one officially correct route, real operators may create side notes, parallel tools, or shortcuts. Such behavior is not automatically misuse; it can be evidence that the design does not support legitimate strategy diversity.

Control Task Analysis

Work Domain Analysis describes constraints; Control Task Analysis examines the decision and control activities required in classes of situations. Routine operation, unusual load, missing data, component failure, and ambiguous state can require different information.

Decision ladder

The decision ladder can model cognitive stages from observation to action and the shortcuts that expertise enables. Experienced practitioners do not necessarily execute every stage explicitly in familiar situations. They may move directly from a recognized cue to a known rule or action, while novel conditions require more analytic processing.

notice event
   ↓
identify information
   ↓
interpret state
   ↓
define goal
   ↓
generate option
   ↓
select procedure / action
   ↓
execute

The model should not be used to force human behavior into a rigid sequence. Its value is to expose where information is required and where a design must bridge cognitive transitions.

Strategies Analysis

The same goal can be achieved through different strategies. An expert may use a fast pattern-based route while another practitioner performs a systematic comparison. A technical system may use local data when connectivity is constrained and a centralized service under normal conditions.

Supporting only one idealized strategy can make a system brittle. Strategies Analysis helps identify safe alternative paths and their information requirements.

Unit 7: Social Organization, Cooperation, and Competencies

Distributed cognition and a common operational picture

Complex work rarely places all relevant knowledge in one person's head. One team member may understand the technical state, another the operational priority, and another the historical context. Team performance is therefore not the sum of individual competence. People must know where knowledge resides, share it at the right time, and use compatible concepts.

A common operational picture does not mean that every role sees the same screen. Different roles can require different detail. What must remain consistent are shared variables and dependencies on which cross-role decisions rely.

Authority, responsibility, and feedback

Giving a person authority to act does not guarantee that the person can observe the effect of the action. Authority and observability should be analyzed together. If a user can change a state but the consequence is visible only to another team or on another display, the control loop is not closed. Conversely, when a role is responsible for monitoring an outcome but cannot intervene, the escalation path must be explicit.

Skill-, rule-, and knowledge-based control

The skill, rule, and knowledge distinction used in worker competency analysis highlights that the same task can demand different forms of cognitive control under different conditions. Well-practiced action may require little conscious effort; a familiar anomaly may trigger a rule; an unprecedented condition may require knowledge-based reasoning. An interface can optimize normal flow for speed while still providing explanatory context when the situation moves outside familiar patterns.

Cognitive work is distributed

In complex systems, relevant knowledge is rarely located in one person. One role may understand technical state, another operational priority, and another authorization or safety constraints. Decision quality therefore depends on how knowledge is distributed and coordinated across the team.

Authority and information can be separated

The role authorized to decide may not hold all required information. A system must move the right level of detail to the right role without creating unnecessary exposure or violating separation of duties. This is simultaneously an interface, access-control, and workflow problem.

Worker Competencies Analysis

Worker Competencies Analysis examines the demands of the work in terms of skill-, rule-, and knowledge-based behavior. The objective is not personnel scoring but understanding what forms of control the system must support.

• Skill-based behavior is fast and fluent; unnecessary confirmations can disrupt it.
• Rule-based behavior maps recognized conditions to known procedures.
• Knowledge-based behavior requires reasoning in novel situations.

A system that exposes only a checklist may fail when unexpected conditions require knowledge-based reasoning. The work-domain structure itself may need to remain visible.

Unit 8: Naturalistic Decision Making

Recognition, evaluation, and mental simulation

In the RPD account, an expert does not always generate and score a large option set. The situation may be recognized as a familiar pattern that brings typical goals, expectancies, relevant cues, and a plausible first action into view. The decision maker then mentally simulates what that action is likely to produce. If no serious problem is found, the first workable option can be used; if a problem appears, it is modified or another option is considered.

This must not be simplified to “experts do the first thing that comes to mind.” Recognition quality depends on experience, feedback, and regularity in the environment. Mental simulation becomes especially important when consequences are delayed or difficult to reverse.

The cost of option generation under time pressure

Conventional decision support sometimes treats a larger option set as inherently helpful. Under time pressure, however, additional options can increase comparison cost. Decision support should not maximize option count; it should expose discriminating cues, eliminate clearly infeasible choices early, and help the operator project likely consequences.

Expertise depends on feedback

Experience alone does not guarantee reliable intuition. If decision outcomes are delayed, ambiguous, or systematically misreported, a person can accumulate many cases while learning the wrong patterns. System design should therefore treat post-decision feedback as part of expertise development, not merely as a reporting feature.

Naturalistic Decision Making (NDM) studies decision behavior under high stakes, time pressure, incomplete information, changing goals, and real work constraints. It complements models that assume every decision begins with exhaustive generation and scoring of alternatives.

Decisions are not always comparative optimization

Comparative analysis is appropriate for many problems, but experienced practitioners under time pressure often behave more like this:

recognize situation
→ recall a plausible action
→ mentally simulate the outcome
→ act if workable
→ otherwise evaluate the next plausible action

This is not random intuition. It depends on learned patterns, expectations, and domain-specific mental models.

Recognition-Primed Decision model

The Recognition-Primed Decision (RPD) model combines situation recognition with evaluation of an action. If the situation fits a familiar pattern, one plausible action may become the first candidate. The decision maker mentally simulates its consequences and may act without comparing a large set of alternatives.

The model does not imply that the first idea is always correct. Recognition quality depends on domain experience, feedback quality, and environmental regularity. Novel, deceptive, or rapidly changing situations may require analytic reasoning.

Limits of expert intuition

System design should not turn expert intuition into unquestioned automation. When the data distribution changes, historical patterns become invalid, or AI introduces new information, old intuitions can produce misplaced confidence. Good decision support preserves expert agency while making evidence and counter-evidence visible.

Unit 9: Situation Awareness

Situation awareness concerns the perception of relevant elements in a dynamic environment, comprehension of their meaning, and projection of their likely near-term status before action is selected.

Three-level model

Endsley's widely used model distinguishes three levels:

Level 1: Perception
What is happening?
     ↓
Level 2: Comprehension
What does it mean?
     ↓
Level 3: Projection
What is likely to happen next?

These levels are not a rigid computational pipeline. Goals, mental models, and expectations affect what information is noticed and how it is interpreted.

Data richness is not awareness

More indicators do not necessarily create better situation awareness. Hundreds of independent metrics can increase integration burden. The design problem is to expose relationships, priorities, trends, and constraints that matter to the task.

CPU: 82%
Queue: 14,200
Ingress: 480/s
Egress: 450/s

Those are values. The operational question may be whether capacity is deteriorating, whether the queue will continue growing, and how long remains before intervention becomes necessary.

Time and freshness

Timestamps matter. Two values can appear in the same view while one is 100 ms old and another is 30 seconds old. Treating them as simultaneous evidence can produce a false state model. Data age, update period, and transport delay therefore affect human-machine decision quality.

Automation and awareness

Automation can reduce workload while distancing the operator from the process. If a person is expected to intervene only when automation fails after long periods of nominal operation, maintaining the necessary mental model becomes difficult. Automation design must therefore ask not only “which steps can be removed?” but also “what must remain visible so that a human can re-enter the loop with adequate state knowledge?”.

Unit 10: Measuring Situation Awareness

Define the measurement target first

Situation awareness should not be reduced to a generic score before the decisions and required situation variables are defined. Remembering hundreds of values is not high SA. What matters is whether task-relevant variables, relationships, and future developments are represented accurately enough for the work. Measurement items should therefore be derived from task and decision requirements.

Engineering use and limitations of SAGAT

In a freeze-probe technique such as SAGAT, the scenario is interrupted at selected moments, normal displays are hidden, and the participant is queried about the current situation. The strength of the method is that responses can be compared with the actual state rather than relying only on a subjective question about perceived understanding. If freeze points become predictable, however, participants may adapt attention to the measurement. If questions cover only easily measured low-level values, comprehension and projection remain untested.

The place of SART and subjective measures

Subjective approaches such as SART can capture perceived attentional demand, attentional supply, and understanding. That evidence is useful, but it should not be treated as the same variable as objective state accuracy. A person can feel highly aware while misunderstanding a critical dependency, or feel uncertain while still making an accurate decision.

Triangulating measures

A stronger evaluation usually combines different evidence:

state queries
     +
subjective assessment
     +
task performance
     +
observation / incident analysis
     ↓
stronger interpretation

These measures are not interchangeable. Good task performance may be achieved through expert compensation despite weak system support, while poor performance can occur even with correct SA when authority or resources are inadequate.

Claims that an interface “improves situation awareness” are weak without measurement. No single measure perfectly captures all dimensions, however.

SAGAT

The Situation Awareness Global Assessment Technique (SAGAT) is a direct assessment approach used in controlled simulations. The task is frozen at selected times, display information is removed, and participants answer questions about the current state. Queries should be derived from information genuinely required by the task.

A strength is that SAGAT can assess what the participant knows independently of final task outcome. A limitation is that freezing the task may disturb natural flow and is not always feasible in production settings.

SART

The Situation Awareness Rating Technique (SART) collects subjective ratings after a task. It is easier to administer, but perceived awareness is not the same as accurate state knowledge. Confidence can be high when knowledge is wrong.

Performance measures

Task success, error count, and response time are valuable but are not pure measures of situation awareness. A participant may obtain a correct result by chance or may understand the situation but fail because the system prevented an effective action.

Multi-method assessment

A stronger evaluation may combine:

direct SA queries
+ task performance
+ behavioral observation
+ incident / error analysis
+ subjective workload and confidence

The purpose is not merely to produce a single SA score but to understand which cognitive mechanism a design change affected.

Unit 11: Ecological Interface Design

Perceptual form should correspond to a work-domain constraint

In Ecological Interface Design, visualization is not merely an aesthetic summary. Geometry and layout should make a meaningful work-domain relation directly perceptible. If safe operation depends on a ratio between two variables, the operator should not have to repeatedly calculate that ratio mentally when the boundary and current state can be represented in one perceptual structure.

This does not justify visualizing every relationship. EID aims to reduce cognitive transformation by representing decision-relevant constraints, not to maximize information density. Unnecessary constraint graphics simply create another layer of noise.

Supporting skill-, rule-, and knowledge-based behavior together

During normal work, an experienced operator may rely on fast perceptual matches. A less familiar condition may require rules and procedures, while an unprecedented case may require reasoning from system goals and constraints. An ecological representation should not be optimized for only one level. It can preserve a direct perceptual structure for rapid work while retaining means–ends and causal context for deeper investigation.

Ecological Interface Design (EID) seeks to make work-domain constraints and functional relationships perceptually available, rather than presenting only isolated state variables. A central objective is to support skill-, rule-, and knowledge-based behavior without forcing users to perform unnecessary higher-level reasoning.

Displaying constraints rather than only values

Conventional display:

Ingress: 420/s
Processing: 400/s
Queue: 12,000

Constraint-oriented display:

               capacity boundary
                      │
ingress 420/s ────────┼─────┐
                            │ +20/s accumulation
processing 400/s ───────────┘

current queue: 12,000
if the differential persists, the queue grows

The second representation can reduce mental integration because the operational relation is visible.

EID is not visual decoration

EID does not mean making a dashboard look more technical. Without Work Domain Analysis, complex graphics can simply increase information density. The visualized relation must correspond to a real physical, functional, or safety constraint.

Support for unexpected events

Procedure-centered interfaces can work well for anticipated failures. Unexpected events may require reasoning from deeper system relations. EID is valuable when it exposes those relations and thereby supports knowledge-based behavior.

Unit 12: Designing Decision Support

A decision-support system does not have to make the decision on behalf of the operator. Often the higher-value objective is to highlight critical cues, integrate relevant context, keep competing explanations visible, and preserve traceability to evidence.

Data, information, situation model, and decision support

data
  ↓
contextualized information
  ↓
situation model
  ↓
possible consequences / options
  ↓
human decision

Displaying a number is data presentation. Connecting it to the correct object and time is information presentation. Integrating multiple sources into a common interpretation forms a situation model. Relating consequences and evidence to the user's goal begins to constitute decision support.

Actionable traceability rather than verbose explanation

In AI-assisted systems, a long natural-language explanation is not sufficient by itself. The practitioner should be able to determine:

• Which records support this result?
• How old and trustworthy are those sources?
• Which elements are direct observations and which are derived?
• What uncertainty exists in the inference?
• Can the result be reproduced if the source set changes?

This connects directly to provenance and grounding in Retrieval-Augmented Generation.

Unit 13: Resilience Engineering

Shared variability behind success and failure

Everyday work is not a perfect copy of procedure. People and technical components continually adjust to time, resource, and information conditions. The same adjustment can improve efficiency on most days and create fragility when other dependencies vary at the same time. Studying only failures hides the adaptations that make ordinary success possible.

Functional resonance and coupled variability

Small timing or accuracy variability in one function may be harmless in isolation. Unexpected outcomes can emerge when variability in several functions combines at the wrong time and in mutually reinforcing directions. A single-root-cause model can be inadequate in such cases. Analysis should examine timing, resource, and control dependencies among functions as well as component faults.

Leading and lagging indicators

Incident count, error count, and downtime usually describe outcomes that have already occurred. Resilience assessment also needs indicators that can expose eroding margins earlier. Queue slope, capacity reserve, frequency of alarm suppression, amount of manual compensation, handoff load, or dependence on a single resource can provide earlier evidence of fragility.

Learning is more than a postmortem

Learning should not be limited to reports after major failures. Difficult but successful shifts, near misses, manual compensations, and unexpectedly effective adaptations can reveal where the system is consuming margin. The purpose is not to grade individuals; it is to understand where adaptive capacity is being used and under which conditions it could be exhausted.

Resilience engineering focuses not only on preventing failure but also on the capacity to sustain required functions and adapt under changing, partially unpredictable conditions. Success and failure are not treated as entirely separate processes; both can emerge from everyday adaptations made under finite time, information, and resources.

Work as imagined and work as done

Procedures describe an intended form of work. Real work occurs under varying staffing, workload, tools, data quality, and environmental conditions. Practitioners make small adjustments continuously so that the system continues to function. Those adjustments are often the source of success, but some combinations can also create risk.

An incident review that stops at “the procedure was not followed” can therefore miss why adaptation was required.

Four resilience potentials

A common resilience-engineering framing emphasizes the capacities to:

• Respond: act effectively when a condition materializes.
• Monitor: observe indicators that signal relevant change.
• Anticipate: consider future threats and opportunities.
• Learn: convert past success and failure into usable knowledge.

These capacities can be translated into design. Monitoring requires meaningful leading indicators; response requires authorized and reversible actions; anticipation may require capacity trends; learning requires reliable post-event evidence.

Graceful degradation

A critical system does not always have to become completely unavailable when one component fails. Safe functions can be preserved while secondary capabilities are restricted. Graceful degradation requires explicit definition of the minimum service set that still produces safe value.

normal mode
   ↓
resource pressure
   ↓
limit secondary functions
   ↓
preserve core service
   ↓
recovery

Margins and adaptive capacity

Capacity is more than average utilization. How much additional load, failure, or coordination burden can the system absorb? CPU, queue, and connection margins create technical boundaries; attention, staffing, and team workload create human boundaries. If those margins are invisible, a system may look nominal while moving toward brittleness.

Unit 14: Automation, AI, and Human Oversight

Function allocation matters more than a single automation level

“More automation” is not a one-dimensional objective. Information acquisition, analysis, option generation, and action implementation can be automated to different degrees. One system may collect data automatically while leaving judgment to a person; another may recommend options but reserve execution authority for the human. Design review should state which cognitive function is being allocated to automation, why, and how that allocation changes the remaining human task.

Mode awareness and automation surprise

When users cannot determine which automation mode is active, why it changed, or which authority remains with the automation, behavior can become surprising. A mode change should not be represented only as a small label when it materially changes the decision space. The operational consequences and action boundaries need to be understandable.

Representing uncertainty

A numeric confidence score is not sufficient by itself. Its calibration, the data distribution from which it was produced, and the decision to be made all matter. Uncertainty representation should preserve the distinction among measured fact, deterministic derivation, statistical estimate, and generative interpretation without overwhelming the operator with unnecessary mathematical detail.

Designing handover

When automation fails, “switch to manual” does not provide context. Effective handover communicates current state, recent automated actions, pending work, critical boundaries, and the first variables the human should inspect. Handover time can itself be treated as a performance requirement: the time required to reconstruct sufficient context can be measured and tested.

The automation paradox

Automation can reduce routine workload but create a more difficult human task during exceptions. When automation performs well for long periods, operator practice and process understanding can decay. Handover is therefore an engineering requirement, not a minor UI event.

Automation bias and calibrated trust

Users may over-trust automated recommendations, a behavior commonly discussed as automation bias. The opposite failure also occurs: frequent false alarms and weak recommendations create chronic under-trust. The objective should not be maximum trust but calibrated trust aligned with actual system capability and uncertainty.

Canonical evidence and derived interpretation

In critical AI-assisted systems it is useful to keep layers distinct:

canonical record / measurement
          ↓
deterministic derivation
          ↓
statistical model output
          ↓
generative-model interpretation
          ↓
human assessment and decision

An interpretation at an upper layer should not replace the evidence below it. If model output is persisted, version, time, input, source set, and relevant uncertainty should be retained as provenance.

Human oversight is more than an approval button

“Human in the loop” is sometimes reduced to adding a confirmation button at the end of a workflow. Meaningful human oversight requires enough information to decide, enough time to inspect, authority to reject the recommendation, and a way to verify the basis of the output.

Unit 15: Applying Cognitive Systems Engineering

Traceability of analysis outputs

Cognitive analysis has limited impact if it remains in a separate report. Critical findings should be linked to requirements, design choices, and verification evidence:

difficult incident / expert cue
           ↓
cognitive requirement
           ↓
interface / automation decision
           ↓
test scenario
           ↓
measurement and acceptance criterion

This chain turns a statement such as “human factors were considered” into engineering evidence that can be reviewed and maintained.

Minimum viable cognitive analysis

Not every project can perform full-scale CTA and CWA. A constrained effort can focus on high-consequence decisions: a small set of difficult-incident interviews, a basic work-domain constraint model, a decision-requirements matrix, and simulation-based verification of one or two critical scenarios. Even this limited analysis can produce stronger design inputs than a generic usability test alone.

Change management and cognitive regression

Cognitive requirements evolve. New automation, organizational change, faster data flow, or a different user population can redistribute expertise and workload. Major releases should therefore ask not only about functional regression but also about cognitive regression. Which relationship that used to be visible must now be reconstructed mentally? Which new automation closed an old feedback loop? Which fast path hides context that is needed during exceptions?

What success looks like

Success in cognitive systems engineering is not a favorable interface rating. More meaningful measures include earlier detection of critical state, fewer incorrect mental models, shorter context-recovery time, preserved core tasks in degraded mode, reduced unnecessary coordination, and closed feedback after action. Measures should be selected from the actual operational risk rather than from a generic usability checklist.

Practical analysis sequence

A useful starting sequence for a complex operational system is:

1. Identify work objectives and stable constraints
2. Select cognitively difficult decisions
3. Elicit expertise and difficult incidents with CTA
4. Model the work domain with CWA
5. Define information and decision requirements
6. State situation-awareness objectives
7. Design interface and automation around those requirements
8. Validate nominal and degraded modes
9. Measure human and technical performance together
10. Convert real incidents into new requirements

Example cognitive requirement

Weak requirement:

The system shall display an alarm.

Stronger requirement:

For an active alarm, the operator shall be able to determine
which entity is affected, when the condition began, whether it
is still active, which higher-level service objective is at risk,
and which two primary signals can confirm the condition within
the same working context.

The second statement constrains design more strongly and creates a verifiable cognitive objective.

Decision-requirement matrix

A function can be analyzed through a compact matrix:

Decision    : What must the practitioner judge or choose?
Cue         : Which signals and relations are meaningful?
Context     : Which historical or concurrent information is needed?
Uncertainty : What is unknown, estimated, or ambiguous?
Time        : How old is the information and how much decision time exists?
Consequence : What is the cost of a wrong decision?
Action      : Which authorized action follows the decision?
Feedback    : How is successful action confirmed?

This does not replace functional requirements; it complements them with cognitive work requirements.

Design-review questions

• Does the display expose only current values, or also meaningful work-domain relations?
• Can the user determine how fresh a critical value is?
• Can an expert move quickly in routine work while still drilling into unexpected cases?
• If automation becomes unavailable, does the human retain the mental model needed to continue safely?
• Are verified records and model-generated interpretations visually and semantically distinct?
• After an interruption, can the practitioner recover the record, step, and context that were active?
• Are alert relationships visible, or only a count of alerts?
• Are capacity and safety margins visible before they are exceeded?

Validation strategy

Cognitive requirements should not be validated only through satisfaction surveys. CTA-derived scenarios, controlled simulations, situation-awareness measures, fault injection, degraded-mode testing, and post-incident studies can be combined. This complements model-, property-, and resilience-oriented methods in Software Test Engineering.

Conclusion

Cognitive systems engineering does not postpone human factors until a usability review at the end of development. Human behavior, automation, information flow, organization, and technical infrastructure are treated as parts of the same system from the requirements stage onward.

Cognitive Task Analysis exposes expertise and difficult decisions. Cognitive Work Analysis models work-domain constraints and alternative strategies beyond the current procedure. Naturalistic Decision Making explains how experienced practitioners act under time pressure and uncertainty. Situation awareness requires interfaces to support comprehension and projection rather than merely display data. Ecological Interface Design seeks to make system constraints perceptually available. Resilience engineering places adaptive capacity at the center of operation under unexpected conditions.

Used together, these approaches shift the objective away from treating the human as the weak link and toward designing a work system in which people and technology jointly behave in a more intelligible, controllable, adaptive, and reliable manner.

References

• Beth Crandall; Gary Klein; Robert R. Hoffman. Working Minds: A Practitioner's Guide to Cognitive Task Analysis. MIT Press, 2006. https://mitpress.mit.edu/9780262033510/working-minds/

• Caroline E. Zsambok; Gary Klein (eds.). Naturalistic Decision Making. Lawrence Erlbaum Associates, 1997.

• Erik Hollnagel; Jean Pariès; David D. Woods; John Wreathall (eds.). Resilience Engineering in Practice: A Guidebook. Ashgate, 2011. https://www.routledge.com/Resilience-Engineering-in-Practice-A-Guidebook/Hollnagel-Paris-Wreathall/p/book/9781472420749

• Gary Klein. Sources of Power: How People Make Decisions. 20th Anniversary Edition. MIT Press, 2017. https://mitpress.mit.edu/9780262534291/sources-of-power/

• Jens Rasmussen; Annelise Mark Pejtersen; L. P. Goodstein. Cognitive Systems Engineering. Wiley, 1994. https://www.wiley-vch.de/en/areas-interest/engineering/cognitive-systems-engineering-978-0-471-01198-9

• Kim J. Vicente. Cognitive Work Analysis: Toward Safe, Productive, and Healthy Computer-Based Work. Lawrence Erlbaum Associates, 1999. https://www.routledge.com/Cognitive-Work-Analysis-Toward-Safe-Productive-and-Healthy-Computer-Based/Vicente/p/book/9780805823974

• Kim J. Vicente; Jens Rasmussen. “Ecological Interface Design: Theoretical Foundations.” IEEE Transactions on Systems, Man, and Cybernetics, 22(4), 589–606, 1992. DOI: https://doi.org/10.1109/21.156574

• Mica R. Endsley. “Toward a Theory of Situation Awareness in Dynamic Systems.” Human Factors, 37(1), 32–64, 1995. DOI: https://doi.org/10.1518/001872095779049543

• Mica R. Endsley; Daniel J. Garland (eds.). Situation Awareness Analysis and Measurement. Lawrence Erlbaum Associates, 2000. https://www.routledge.com/Situation-Awareness-Analysis-and-Measurement/Endsley-Garland/p/book/9780805821345

• Nancy G. Leveson. Engineering a Safer World: Systems Thinking Applied to Safety. MIT Press, 2012. https://mitpress.mit.edu/9780262016629/engineering-a-safer-world/