Sarcos Technology and Robotics: Engineering Exoskeletons Where Industrial Safety Standards Meet Military Requirements

Sarcos Technology and Robotics occupies a narrow and technically demanding slice of the robotics market. The Salt Lake City company builds full-body powered exoskeletons and teleoperated robotic systems — hardware designed to amplify human physical capability in environments where that capability is otherwise dangerously insufficient or entirely inaccessible. Its Guardian XO full-body exoskeleton targets industrial workers doing sustained heavy lifting. Its Guardian XT teleoperated system targets remote manipulation in defense, energy, and infrastructure contexts.

That product portfolio sounds coherent until you examine the systems engineering requirements it generates. Sarcos is simultaneously building Class II medical-adjacent wearable devices, industrial safety equipment, and defense platforms — sometimes in the same physical system. The requirements management challenge that creates is not a software configuration problem. It reflects a genuine gap in how the engineering discipline currently handles human-machine systems where the human is not the operator of the machine but a structural and sensing component of it.

The Dual-Standard Environment

ISO 13482 governs the safety requirements for personal care robots — the international standard most directly applicable to powered exoskeletons used in non-medical industrial contexts. It defines hazard categories, contact force limits, and the behavioral constraints robotic systems must satisfy when physical contact with humans is unavoidable by design. The standard was developed with assistance devices and rehabilitation robots in mind, but it is the closest applicable framework for a full-body powered exoskeleton worn by an industrial worker.

Military performance requirements occupy a different register entirely. Defense contracts for platforms like the Guardian XT impose requirements around payload capacity, operational tempo, communications latency tolerance, environmental survivability (temperature ranges, vibration profiles, ingress protection), and — critically — mean time between failures in the field, where maintenance support is constrained or absent.

These two frameworks do not cleanly compose. ISO 13482 places upper bounds on forces a robot may apply to a human body. Defense performance requirements place lower bounds on the forces a robotic system must sustain or generate to accomplish the mission. In a pure industrial exoskeleton, you optimize toward the ISO ceiling. In a defense teleoperations system, you optimize toward the performance floor. Sarcos builds hardware that must simultaneously respect both, which means maintaining a requirements architecture capable of surfacing conflicts between them before they become hardware integration failures.

The practical implication is that a single Sarcos system component — a joint actuator, a control loop gain parameter, a structural frame section — may be governed by requirements originating in three or four distinct standards bodies simultaneously. Tracking which requirement owns a given design decision, and what changes upstream in a standard revision would force re-evaluation of that decision, is not a problem a well-maintained spreadsheet solves.

The Guardian XO: When the Operator Is Part of the System

The Guardian XO is Sarcos’s industrial exoskeleton product. It is a battery-powered, full-body suit that enables a worker to lift and maneuver loads up to 90 kilograms repetitively over a multi-hour shift without accumulating the physiological fatigue that makes such work unsustainable or unsafe without augmentation.

The systems engineering framing for the Guardian XO runs into an immediate definitional problem: what is the system boundary? In conventional industrial machinery, the operator is outside the system. The machine has defined input interfaces — controls, switches, levers — and the safety analysis concerns what happens when the human interacts incorrectly with those interfaces. ISO 13482 shifts this substantially, because contact between the machine and human is continuous and intentional. But the deeper challenge is that the human wearing the Guardian XO is not just contacting the machine at the interface boundary. The human’s skeletal structure, joint mechanics, balance responses, and musculature are load-bearing elements of the combined system.

This forces requirements decomposition into territory most systems engineering methodologies handle awkwardly. A structural requirement on the hip actuation assembly is not fully specified by the mechanical loads the actuator must transmit. It also depends on the range of human hip morphology the system must accommodate, the neuromuscular response latency of a human operator reacting to an unexpected load, and the fatigue profile of the human musculoskeletal system under sustained augmented operation. None of those human factors are fixed parameters. They vary across the user population, change within a single shift, and interact with each other in ways that are not fully modeled.

The requirements management consequence is that the Guardian XO development program must maintain live bidirectional traceability between biomechanical performance envelopes — derived from human factors testing and ergonomic research — and the mechanical and electrical specifications governing the hardware. When a human factors study revises the safe cumulative load exposure limit for a specific joint, that revision should propagate automatically through the requirements hierarchy and flag every design specification that was derived from the previous limit. In document-based requirements management, that propagation is manual, slow, and depends entirely on an engineer recognizing the dependency exists.

The Guardian XT: A Different Architecture, Shared Hardware Roots

The Guardian XT is a teleoperated robotic system, not a wearable exoskeleton. The human operator wears a haptic interface — Sarcos calls it the Master Controller — and the robot’s twin arm assembly mirrors and amplifies the operator’s movements at a safe distance. It is designed for environments where direct human presence is too hazardous: radiological cleanup, high-voltage electrical work, subsea operations, forward operating base maintenance tasks in contested territory.

Despite sharing mechanical heritage with the Guardian XO program, the Guardian XT presents a substantially different requirements architecture. The operator is no longer physically coupled to the robot’s structural loads. Biomechanical limits still govern the Master Controller interface design, but the dominant requirements tension shifts from human-load-bearing to latency, fidelity, and operational availability.

Force feedback latency in teleoperated systems with haptic feedback is a safety-relevant parameter, not just a user experience parameter. If the Guardian XT encounters a mechanical stop and the force feedback to the operator’s hands is delayed by more than the operator’s neuromuscular response time, the operator will overload the joint before the feedback signal reaches them. The safety requirement on haptic feedback latency is therefore derived from human neurophysiology — specifically, the 100–200 millisecond range of proprioceptive feedback loops — rather than from any industrial standard. Writing and tracing that requirement demands that the systems team maintain an explicit link between a communications system specification and a human physiology literature reference.

Defense applications add the further constraint that communications links may be degraded or intermittent. The Guardian XT must therefore have defined safe-state behaviors for operation under degraded feedback conditions, and those safe-state behaviors themselves carry ISO 13482 implications if a human operator is nearby during a safe-state transition. The requirements web connecting communications performance, hazard analysis, and operator interface behavior is dense, and the connections run across discipline boundaries that conventional organizational structures — electrical, mechanical, software, safety — often don’t bridge automatically.

Human-Machine Interface Requirements as a Category Problem

Both the Guardian XO and Guardian XT highlight a structural gap in how systems engineering typically handles human-machine interface requirements. HMI requirements in most methodologies are treated as derived, late-stage specifications: you define the system, then specify how the human interacts with it. For exoskeletons and haptic teleoperations systems, this ordering is wrong. The human interaction modality is not downstream of the system architecture; it is a primary design constraint that governs what architectures are feasible.

This inversion has practical consequences. Standard requirements traceability practice links requirements downward from stakeholder needs to system requirements to subsystem specifications to component parameters. In Sarcos’s domain, that hierarchy contains bidirectional dependencies. A subsystem specification — peak joint torque, for example — constrains and is constrained by a stakeholder need (lift 90 kg repetitively), but it is also constrained by a human factors parameter (maximum safe knee joint moment under sustained loading) that lives at the same level of the requirements hierarchy as the stakeholder need, not below it.

Modern graph-based requirements management handles this more naturally than hierarchical document structures, because a graph can express the dependency between a human factors limit and a mechanical specification without forcing one to be formally upstream of the other. Document-based tools — and most legacy requirements management platforms are fundamentally document-based under their interface layer — resist this because they are built around the assumption that the requirements hierarchy is a tree, not a network.

The Verification Problem

Verification of requirements for human-augmentation systems introduces another layer of complexity. Many of the performance requirements for both Guardian products can be verified through standard test methods: actuator torque output is measurable, frame stiffness under load is measurable, power consumption per duty cycle is measurable.

Human factors requirements are not verified the same way. Verifying that the Guardian XO does not impose unsafe cumulative joint loads across a representative user population over a representative shift profile requires human subject testing under controlled conditions. That verification activity is expensive, slow, and produces probabilistic evidence rather than binary pass/fail results. The requirements management challenge is not just writing the requirement — it is maintaining traceability from the requirement to a verification method that is appropriate for it, and flagging when a downstream design change invalidates a previously completed verification activity.

If a control software update changes the Guardian XO’s load distribution strategy, does it invalidate prior human factors testing? The answer depends on the nature of the change and the sensitivity of the human factors parameters involved. Making that determination automatically requires the requirements management system to carry enough context about the verification methods and the design decisions they covered to reason about dependency. That is a capability well beyond what static document management provides, and it is where modern requirements tooling — platforms designed around live traceability graphs rather than requirement documents — provides concrete operational value.

Tools built on graph-based models, where each requirement node carries explicit links to its verification activities, its source assumptions, and its downstream design parameters, enable that kind of change impact analysis to run automatically when a design change is proposed. Flow Engineering’s approach to connected traceability, for example, is built around exactly this kind of dependency graph, which makes it architecturally suited to the kind of cross-disciplinary requirements networks that exoskeleton development generates.

Where the Industry Stands

Sarcos is not unique in facing these challenges. Any company developing powered exoskeletons, prosthetics with active control, or teleoperated systems with haptic feedback confronts the same underlying requirements management problems. The human is in the system. The standards frameworks were not written for that. The verification methods are expensive and probabilistic. The dependency networks run across discipline and organizational boundaries.

What Sarcos’s profile illustrates clearly is that these are not process problems solvable by better discipline within existing tools. The requirement for bidirectional traceability between biomechanical envelopes and mechanical specifications, the need for requirements graphs rather than requirements trees, the challenge of maintaining verification coverage across probabilistic human factors data — these demand tooling architectures that most enterprise requirements management platforms were not designed to provide.

The exoskeleton market is small today, but the requirements management patterns it exposes are relevant to any system where a human being is a load-bearing or sensing component of the architecture. As human augmentation technology scales — in defense, in industrial automation, in medical robotics — the gap between what legacy requirements management tools provide and what these programs actually need will grow more visible. Sarcos is building in that gap right now.