The Machine That Must Explain Itself

Trust Begins Before the Robot Moves

When two people carry a heavy object together, communication rarely begins with speech. Posture, gaze, grip force, direction of movement, and changes in pace reveal intention. Each person continuously predicts what the other is about to do and adjusts accordingly.

Humanoid robots enter this deeply human communication space. Their physical form invites people to interpret their movement as purposeful, even when the motion is merely the output of trajectory planning. A turn of the head may be read as attention. An arm movement may be interpreted as an intention to reach. A pause may appear to signal hesitation, although it could indicate a network delay, an unresolved perception state, or a thermal limitation.

The robot therefore communicates whether its designers intend it to or not.

Research in human–robot interaction distinguishes between predictable motion and legible motion. Predictable motion follows the trajectory an observer expects once the goal is known. Legible motion helps the observer infer the goal before it has been reached. These properties can differ: the shortest and most efficient trajectory is not always the one that communicates intention most clearly Reference 01 – Legibility and Predictability of Robot Motion.

For a humanoid sharing an unstructured workspace, motion planning consequently has two objectives. It must produce a technically valid trajectory, and it must make that trajectory interpretable to nearby people. A small reduction in theoretical motion efficiency may create a larger improvement in coordination, confidence, and safety.

Operational Transparency, Not Artificial Conversation

Explainability is often framed as a verbal capability: the robot is asked why it performed an action and generates a human-readable response. This may be useful for supervisors, engineers, or service technicians, but it is only one layer of transparency.

A worker standing near a moving robot cannot wait for a detailed explanation. The immediate questions are simpler.

This suggests a hierarchy of explanation. Millisecond-level interaction depends on motion, force, light, sound, and safe-state behaviour. Second-level interaction may use concise status indicators or a local display. Minute-level diagnosis may expose event histories, sensor confidence, degraded modes, and corrective actions. Engineering analysis can then access detailed logs, software versions, network traces, and safety events.

The purpose is not to expose all internal data. Too much information can be as dangerous as too little. Operational transparency means selecting the information that enables the person to make a safe and informed decision.

The NIST AI Risk Management Framework similarly notes that transparency should address how a human operator is informed when an AI system causes or detects a potentially adverse outcome. It also cautions that transparency alone does not make a system accurate, secure, private, or fair Reference 02 – Artificial Intelligence Risk Management Framework 1.0.

The Trust Chain

A humanoid robot’s trust chain begins long before information reaches a display. Each layer depends on the integrity of the layer beneath it.

Sensing: What Does the Robot Believe?

Cameras, radar, inertial sensors, joint-position sensors, torque sensors, tactile arrays, and proximity detectors build the robot’s representation of its body and surroundings. The human operator should not need to inspect every sensor value, but the system must distinguish between a confident observation, an uncertain estimate, and unavailable information.

This requires more than a perception algorithm. It requires signal integrity, time synchronisation, plausibility checking, sensor diagnostics, and known failure behaviour. A robot that reports a confident conclusion from degraded or temporally misaligned sensors creates false reassurance.

State Estimation: What Does the Robot Know About Itself?

State estimation must continuously cover joint position, velocity, contact state, balance, payload, thermal condition, available energy, and communication health. These states determine what the robot can safely do next.

A low battery, overheating actuator, drifting encoder, blocked joint, or intermittent communication link may not demand an immediate emergency stop. It may require reduced speed, restricted movement, task handover, or controlled withdrawal. The transition into such degraded modes must be visible and understandable.

Intent Generation: What Is the Robot Trying to Do?

AI planning converts a task objective into a sequence of actions. This is the layer most commonly associated with intelligence, but it should not hold unrestricted authority over motion. The intended action must remain inside a defined operational envelope containing safety, force, speed, workspace, tool, and human-proximity constraints.

Intent must also be expressed early enough for a person to react. A robot that signals a turn only after beginning to rotate is technically reporting its action, but not meaningfully communicating intent.

Real-Time Control: Will Motion Match Intention?

The control system converts trajectories into deterministic motor commands. Semiconductor performance is central here. Microcontrollers, position-sensor interfaces, gate drivers, current sensors, power switches, and real-time communication devices collectively determine whether the robot’s physical movement corresponds to its declared plan.

Timing variation, packet loss, sensor drift, or actuator saturation can create a gap between intended and actual motion. A trustworthy architecture detects this divergence and prevents the human-facing interface from continuing to display an intention that the machine can no longer execute reliably.

Functional Safety: What Must Never Be Allowed?

Functional safety provides an independent constraint on behaviour. It monitors critical conditions and brings the robot into an appropriate risk-reduced state when necessary. For humanoids, that state may be context dependent. Instantly removing torque could cause a robot to fall, drop a load, or destabilise a person it is supporting.

Safety communication must therefore indicate more than “running” or “stopped.” It may need to distinguish normal operation, limited-speed collaboration, controlled pause, task handover, safe retreat, stabilised hold, and emergency response.

The 2025 editions of ISO 10218-1 and ISO 10218-2 address the safe design of industrial robots and the integration of robot applications and cells. Their scope reinforces an important principle: robot safety is not determined by the robot alone. It emerges from the complete application, its integration, and its operating environment Reference 03 – ISO 10218-1:2025; Reference 04 – ISO 10218-2:2025.

Diagnostics and Interface: What Does the Human Need to Know?

Only after the preceding layers have established reliable state information can the robot communicate meaningfully. The interface should prioritise consequence and action rather than internal component names.

“Joint-drive communication timeout” may be useful to a service engineer. A nearby worker may instead need to know: “Left arm unavailable—robot holding position—keep clear until load is secured.” Both descriptions refer to the same event, but they support different decisions.

Calibrated Trust Is Better Than Maximum Trust

The design objective should not be to make people trust robots as much as possible. Excessive trust produces complacency, over-reliance, and delayed intervention. Insufficient trust causes workers to avoid the system, duplicate its work, or override useful automation.

The objective is calibrated trust: the human’s confidence should correspond to the robot’s actual capability in the current situation.

A robot should communicate confidence without pretending to possess certainty. It should acknowledge when a command is ambiguous, when an object classification is unstable, when localisation quality is deteriorating, or when a task exceeds its validated operating conditions. A request for assistance is not evidence of weak autonomy. It is evidence that the autonomy boundary has been engineered honestly.

The European approach to trustworthy AI places human agency and oversight among its central principles. Under the EU AI Act, the specific legal obligations depend on a system’s intended purpose and risk classification; not every humanoid application is automatically a high-risk AI system. Nevertheless, transparency and meaningful human oversight are becoming explicit design considerations rather than optional interface features Reference 05 – Ethics Guidelines for Trustworthy AI; Reference 06 – AI Act Regulatory Framework.

The Semiconductor Architecture of Understandable Behaviour

The user experiences trust at the system level, but the evidence supporting it is generated close to the physical process.

The relevant design metric is not simply compute performance. It is the latency and integrity of the full trust chain: from a physical event, through sensing and interpretation, to a safe control response and an understandable human signal.

A robot that detects a person in 20 milliseconds but communicates its intention one second later has a technically fast perception system and a practically slow collaboration system. A robot that records a fault but cannot distinguish its cause from its consequence possesses data without useful explanation.

When Explanation Becomes Infrastructure

As humanoid fleets grow, transparency will extend beyond the individual robot. Supervisors will need to understand which robots are operating normally, which are degraded, which require human confirmation, and whether repeated interventions reveal a systematic problem. Training teams will need event patterns that identify skill gaps. Safety engineers will require traceable evidence. Maintenance teams will need component-level diagnostics. Workers will need immediate and locally understandable cues.

The same event will therefore require several explanations, all generated from a consistent source of truth.

This creates a new architectural requirement: explainability must be designed into data models, control states, diagnostic codes, security policies, and semiconductor monitoring paths. It cannot be added later as a conversational layer over an opaque machine.

The humanoid robot of the Physical AI era will not earn trust by resembling a person or speaking fluently. It will earn trust by behaving consistently, revealing uncertainty, respecting human authority, and making its next action understandable before that action begins.

The machine that works beside us must therefore become the machine that can explain itself.