TRUSTBOUNDARY™

PHYSICAL AI SAFETY STANDARD

TB-PAS 1.0

Parts 1–6: Architecture, Action Authorization, Validation, Humanoid Profile, Physical-Authority Token, and Certification

WORKING DRAFT FOR PUBLIC COMMENT

Version 1.0  |  July 2026

Published by TrustRobotics

This document is a private technical specification. It is not an ISO, IEC, IEEE, ANSI, ASTM, governmental, or regulatory standard and does not replace applicable law or certified functional-safety engineering.

Copyright © 2026 TrustRobotics. Draft circulation permitted for technical review and public comment, subject to the notices in this document.

Document Status and Use

This working draft defines proposed requirements for controlling the transfer of physical authority from an artificial-intelligence process to actuators in a Physical AI system. It is intended for technical review, implementation trials, conformance-test development, and public comment.

Conformance with this document does not, by itself, establish compliance with any law, regulation, machinery-safety standard, functional-safety standard, cybersecurity standard, or sector-specific requirement. Implementers remain responsible for identifying and satisfying all requirements applicable to the robot, machine, workplace, public environment, and intended use.

Normative Language

Conformance Claims

A supplier, integrator, operator, or certification body making a conformance claim shall identify:

• the system, subsystem, model, robot, controller, actuator interface, or deployment to which the claim applies;

• the TB-PAS version and validation classes claimed;

• any applicable profile, including TB-PAS-H1;

• declared timing, risk, operating-domain, degraded-mode, and minimum-risk assumptions;

• all exclusions, limitations, optional features, and externally provided safety functions; and

• the test evidence supporting the claim.

Contents

PART 1 — TERMINOLOGY AND ARCHITECTURE

1.1 Purpose

Part 1 establishes the vocabulary, scope, architectural roles, and conformance principles used throughout TB-PAS. The terminology is intended to permit interoperable discussion and testing without mandating a particular neural model, robot operating system, processor, communication bus, actuator technology, or mechanical form factor.

1.2 Scope

1.2.1  TB-PAS applies to a system in which an artificial-intelligence process can directly or indirectly cause a physical actuator, energy source, mobility subsystem, manipulator, tool, or other physical-effect endpoint to operate.

1.2.2  TB-PAS applies whether the AI action generator is onboard, remote, cloud-hosted, distributed, human-supervised, continuously learning, pre-trained, deterministic, generative, or composed of multiple models or agents.

1.2.3  A conforming implementation may allocate TrustBoundary functions across software, firmware, processors, safety controllers, motor controllers, network nodes, or physically independent hardware, provided that the observable requirements of this document are satisfied.

1.2.4  TB-PAS shall be applied in addition to, and not as a substitute for, applicable machinery safety, electrical safety, functional safety, cybersecurity, workplace safety, product safety, and regulatory requirements.

1.3 Architectural Principle

No AI-generated candidate physical action shall receive actuator authority unless the action has been independently evaluated and a valid, action-bound release authorization is enforced at the physical execution boundary.

1.4 Reference Architecture

A TB-PAS reference architecture contains the following logical roles. A conforming system need not use these labels internally, but it shall provide equivalent functions and observable evidence.

1.5 Terms and Definitions

1.5.1 Physical AI system

A computational and physical system in which an artificial-intelligence process can generate, select, modify, or influence an action that changes the physical world through an actuator or other physical-effect endpoint.

NOTE — A Physical AI system can include a humanoid robot, mobile robot, industrial robot, autonomous vehicle, drone, medical robot, care robot, smart machine, distributed robotic system, or infrastructure-controlled physical device.

1.5.2 AI action generator

A model, agent, policy, planner, controller, inference process, rule engine, or combination thereof that produces or selects a candidate physical action.

NOTE — The AI action generator can use language, vision, audio, tactile, proprioceptive, world-model, mission, human-command, or network inputs.

1.5.3 candidate physical action

A proposed command, behavior, trajectory, force profile, actuator setpoint, locomotion operation, manipulation operation, contact operation, tool operation, or other physically executable output that has not yet received final TrustBoundary authorization.

1.5.4 TrustBoundary

A mandatory control boundary between an AI action generator and physical execution that intercepts candidate physical actions, obtains validation evidence, determines whether and under what conditions authority may be granted, and prevents unauthorized actuation.

1.5.5 predictive validator

A validator that estimates one or more future physical states, consequences, hazards, interactions, or constraint outcomes associated with execution of a candidate physical action.

NOTE — A predictive validator can use a world model, learned dynamics, physics simulation, trajectory analysis, balance prediction, contact prediction, collision prediction, force prediction, digital twin, or other prospective model.

1.5.6 release authorization

A TrustBoundary determination that permits a defined candidate physical action, or an approved modification of that action, to execute subject to specified conditions and limits.

1.5.7 physical-authority token

A machine-verifiable data object that binds a release authorization to a particular action, robot or device, actuator or body region, context, validity interval, validator evidence, and execution envelope.

1.5.8 execution envelope

The permitted bounds within which an authorized action may execute, including one or more trajectory, location, timing, force, torque, velocity, acceleration, power, contact, body-state, environmental, policy, or authorization limits.

1.5.9 actuator firewall

A software, firmware, hardware, or hybrid enforcement function that prevents an actuator-control endpoint from accepting or continuing a command unless the command is covered by a valid release authorization and remains within the applicable execution envelope.

1.5.10 safety-action controller

A controller, process, circuit, or protected execution function that can place or maintain the Physical AI system in a minimum-risk condition when ordinary AI authority is absent, denied, expired, invalid, or revoked.

1.5.11 authority revocation

Withdrawal or invalidation of previously granted physical authority before or during execution because a validity condition, environmental assumption, execution limit, validator condition, policy condition, communication condition, or integrity condition is no longer satisfied.

1.5.12 validation evidence

Data sufficient to establish what candidate action was evaluated, which inputs and assumptions were used, which validators and policies were applied, what outcomes were predicted or detected, and why authority was granted, modified, denied, or revoked.

1.5.13 validator independence

A degree of separation that prevents the AI action generator from unilaterally controlling, bypassing, falsifying, suppressing, or self-approving the validation decision required for physical authority.

NOTE — Independence can be logical, process-based, privilege-based, cryptographic, spatial, electrical, computational, organizational, or physical, depending on the validation class and risk.

1.5.14 safety-critical context

A physical, human, environmental, operational, legal, infrastructure, mission, or system condition in which an incorrect or uncontrolled action can cause unacceptable harm, loss, damage, rights impairment, or hazardous loss of control.

1.5.15 degraded mode

An operating state in which sensing, computation, communications, validation, energy, actuation, localization, model confidence, or other capability is reduced but limited operation can remain permissible under explicitly constrained authority.

1.5.16 minimum-risk action

A protected physical action or controlled non-action intended to reduce or avoid harm after authority is denied or revoked, considering the robot’s current physical state and surrounding environment.

NOTE — A minimum-risk action can include stopping, holding position, kneeling, sitting, lowering a payload, releasing energy, moving to a safe location, requesting human assistance, entering a protective posture, or executing a controlled fall.

1.6 Architectural Requirements

1.6.1  The TrustBoundary shall be positioned such that every in-scope AI-generated candidate physical action is subject to authorization before the relevant actuator-control endpoint accepts the action.

1.6.2  The system shall identify and document all command paths capable of causing physical execution, including maintenance, debug, remote, fallback, update, simulation-transfer, and emergency paths.

1.6.3  An unvalidated alternate command path shall not bypass the TrustBoundary except for an independently justified and protected safety-action path.

1.6.4  The AI action generator shall not be the sole authority for issuing, validating, or revoking its own release authorization in a safety-critical context.

1.6.5  The system shall fail closed with respect to ordinary AI-generated actuation when required validation or authorization evidence is unavailable, invalid, expired, or unverifiable.

1.6.6  The system shall preserve sufficient validation and execution evidence to permit reconstruction of authorization, denial, modification, revocation, and completion decisions.

PART 2 — MANDATORY ACTION PIPELINE

2.1 Normative Requirement

2.1.1  A conforming Physical AI system shall prevent an AI-generated candidate physical action from reaching an actuator-control endpoint unless a TrustBoundary has produced a valid release authorization for that candidate physical action.

2.1.2  A release authorization shall apply only to the action, system, context, actuator scope, validity interval, and execution envelope for which the authorization was issued.

2.1.3  A release authorization shall not be inferred solely from the absence of an error, alarm, or detected invariant violation.

GENERATE  →  INTERCEPT  →  NORMALIZE  →  PREDICT  →  EVALUATE  →  AUTHORIZE  →  ENFORCE  →  MONITOR  →  REVOKE OR COMPLETE

2.2 Stage Requirements

2.2.1 Generate

• The AI action generator shall produce or identify a candidate physical action before physical authority is granted.

• The candidate action shall be distinguishable from a released actuator command.

• The candidate action should include sufficient intent, target, body-region, timing, trajectory, force, contact, and mission information for the required validation class.

2.2.2 Intercept

• The TrustBoundary shall intercept the candidate action before it can be accepted by the actuator-control endpoint.

• Interception shall cover direct commands, buffered commands, scheduled commands, streamed setpoints, remote commands, model-generated trajectories, and commands generated by subordinate agents.

• The interception point shall be protected against unauthorized bypass, disablement, replacement, or privilege escalation.

2.2.3 Normalize

• The TrustBoundary shall convert the candidate action into a representation suitable for validation and comparison with later execution.

• Normalization shall preserve action identity and safety-relevant semantics.

• Normalization shall identify unresolved, ambiguous, missing, or inconsistent safety-relevant fields and shall cause denial, clarification, conservative substitution, or constrained validation as appropriate.

2.2.4 Predict

• Where TB-V2 or a higher predictive class is claimed, the system shall estimate future physical consequences of the candidate action under the current or conservatively estimated state.

• Prediction shall consider uncertainties material to the claimed operating domain.

• Prediction shall be refreshed when a material input, assumption, environment state, person state, object state, robot state, or mission condition changes before execution.

2.2.5 Evaluate

• The TrustBoundary shall compare deterministic checks and predicted consequences against applicable safety, authorization, policy, mission, infrastructure, human-protection, and execution constraints.

• The evaluation shall produce an explicit outcome: authorize, authorize with limits, modify, decompose, delay, request clarification, reroute, substitute, deny, or transfer to a safety-action controller.

• The system shall define how disagreement, uncertainty, unavailable validators, stale evidence, and conflicting policies are resolved.

2.2.6 Authorize

• The TrustBoundary shall issue a release authorization only after all mandatory validators and policies required for the claimed class and context have returned acceptable outcomes.

• The authorization shall be bound to a specific candidate action or approved action version.

• The authorization shall define an execution envelope and revocation conditions.

2.2.7 Enforce

• The actuator firewall shall verify the release authorization before accepting the associated command.

• The actuator firewall shall reject a command that is absent, altered, expired, replayed, context-mismatched, actuator-mismatched, or outside the authorized envelope.

• Enforcement shall not depend solely on cooperation by the AI action generator.

2.2.8 Monitor

• The system shall monitor execution at a rate sufficient to detect material departure from the execution envelope and relevant safety conditions.

• Monitoring shall include the signals necessary to detect the declared revocation conditions.

• Monitoring failures shall cause a predefined constrained response, authority revocation, or minimum-risk action.

2.2.9 Revoke or Complete

• The TrustBoundary or actuator firewall shall revoke authority when a revocation condition occurs.

• After revocation, the system shall prevent continuation of the unauthorized portion of the action and shall execute an appropriate minimum-risk action or protected transition.

• On successful completion, the system shall close the authorization and record completion status sufficient to prevent replay or unintended continuation.

2.3 Action Modification and Substitution

2.3.1  A modified, decomposed, rerouted, delayed, or substituted action shall be treated as a new action version and shall receive validation appropriate to the change.

2.3.2  A modification shall not inherit authority for parameters, body regions, actuators, objects, persons, locations, or time periods not covered by the original authorization.

2.3.3  The system shall preserve the relationship between the original candidate action, each modified version, the selected authorized version, and the executed command.

2.4 Timing and Availability

2.4.1  The supplier shall specify maximum validation latency, authorization latency, enforcement latency, monitoring interval, and revocation latency for each claimed operating domain and validation class.

2.4.2  The specified timing shall account for worst-case computational load, communication delay, queueing, degraded operation, and validator unavailability reasonably expected in the claimed domain.

2.4.3  Where a candidate action cannot be validated within the available safety deadline, ordinary AI authority shall not be granted; the system may delay, simplify, constrain, substitute, or transfer the action to the safety-action controller.

2.4.4  A time-critical reflex or safety action may use a protected fast path, provided that the fast path is independently bounded, documented, tested, and incapable of becoming an unrestricted bypass for ordinary AI-generated actions.

2.5 Evidence and Auditability

2.5.1  For each authorization decision, the system shall record the candidate-action identifier, action version, required validators, validator outcomes, policy outcomes, authorization scope, execution envelope, validity interval, and integrity status.

2.5.2  For each denial or revocation, the system shall record the triggering condition and the resulting constrained or minimum-risk action.

2.5.3  Evidence retention, access, privacy, integrity, and disclosure periods shall be defined for the intended use and applicable legal environment.

2.5.4  The evidence mechanism shall prevent the AI action generator from silently deleting, rewriting, or suppressing safety-critical authorization records.

2.6 Architecture Neutrality

Conformance shall be determined by observable behavior, evidence, enforcement, and test results. TB-PAS does not require a particular model architecture, chip, robot operating system, message bus, cryptographic suite, simulation engine, actuator technology, or deployment topology. An implementation may be centralized or distributed and may use software, firmware, hardware, or hybrid enforcement, subject to the independence and non-bypass requirements of the claimed validation class.

PART 3 — VALIDATION CLASSES

3.1 General

TB-PAS defines progressively stronger validation classes. A higher class incorporates the required controls of lower classes unless a requirement is expressly replaced by a stricter requirement. A conformance claim shall identify the class achieved for each action category or operating mode; a system need not use the same class for every action.

3.2 TB-V1 — Deterministic Constraint Validation

TB-V1 establishes the minimum class for action authorization based on explicit limits, permissions, and prohibited conditions.

3.2.1  The TrustBoundary shall check each candidate action against all deterministic constraints applicable to the action, body region, actuator, object, person, location, mission, and operating state.

3.2.2  Applicable checks shall include, where relevant, joint range, maximum torque, maximum force, maximum velocity, maximum acceleration, power limit, geofence, prohibited object, payload limit, human-clearance requirement, tool authorization, restricted zone, and mission authority.

3.2.3  The source, version, scope, priority, and update state of each applied constraint shall be identifiable in validation evidence.

3.2.4  A conflict between mandatory constraints shall cause denial or a predefined conservative resolution; the AI action generator shall not resolve the conflict unilaterally.

3.2.5  A TB-V1 release authorization shall contain or reference the deterministic bounds that constitute the execution envelope.

Typical TB-V1 applications include bounded joint movement, speed-limited navigation, geofenced operation, payload enforcement, prohibited-zone avoidance, and command-source authorization.

3.3 TB-V2 — Predictive Physical Validation

TB-V2 extends TB-V1 by requiring prospective evaluation of what is expected to happen if a candidate action executes.

3.3.1  The system shall predict one or more future physical states or consequences associated with the candidate action.

3.3.2  Prediction shall use one or more suitable methods, which may include world models, learned dynamics, collision prediction, balance prediction, force prediction, trajectory simulation, digital twins, geometric models, physics engines, or validated analytical models.

3.3.3  The validator set shall be selected according to the action type, affected body region, objects, persons, environment, uncertainty, and declared risk.

3.3.4  The system shall evaluate whether predicted consequences remain within applicable constraints and acceptable uncertainty bounds.

3.3.5  Where prediction uncertainty is material to safety, the system shall reduce authority, request additional information, invoke a more conservative validator, delay execution, substitute a safer action, or deny the action.

3.3.6  The authorization shall be invalidated or refreshed when a material prediction input or environmental assumption changes before or during execution.

Typical TB-V2 applications include predicted collision avoidance, balance-aware locomotion, trajectory validation, dynamic obstacle response, fall-risk prediction, and consequence-based modification of a proposed action.

3.4 TB-V3 — Contact and Tactile Prediction

TB-V3 extends TB-V2 for candidate actions involving actual, probable, or safety-relevant contact.

3.4.1  TB-V3 shall be applied to safety-relevant grasping, object transfer, tool use, human contact, fragile-object handling, high-force manipulation, dexterous hand operation, or other contact-rich action identified by the risk assessment.

3.4.2  The system shall evaluate predicted contact location, timing, normal and tangential force, pressure, impulse, slip, grasp stability, object fragility, entrapment, pinch, crush, puncture, cutting, thermal, electrical, and release consequences as applicable.

3.4.3  The validator shall consider uncertainty in object properties, human compliance, contact geometry, tactile sensing, tool state, payload state, and actuator response where material to safety.

3.4.4  The execution envelope shall define applicable force, torque, pressure, contact-duration, velocity, acceleration, tool, body-region, and release limits.

3.4.5  Where tactile or force feedback indicates departure from predicted contact behavior, the system shall modify, pause, release, withdraw, revoke, or transfer to a minimum-risk action within the declared safety deadline.

3.4.6  A contact-rich action shall not continue solely because its initial authorization was valid when new tactile or force evidence indicates an unsafe condition.

3.5 TB-V4 — Multi-Agent and Infrastructure Validation

TB-V4 extends TB-V2 and, where applicable, TB-V3 to shared physical environments, coordinated systems, and authorization-bearing infrastructure.

3.5.1  The system shall evaluate safety-relevant nearby robot actions, human actions, vehicle actions, shared occupancy, common-object state, infrastructure state, and environmental permissions applicable to the candidate action.

3.5.2  The system shall detect and resolve predicted robot-to-robot, robot-to-human, robot-to-vehicle, robot-to-infrastructure, and robot-to-public-space conflicts within the claimed operating domain.

3.5.3  A shared plan, peer message, infrastructure permission, reservation, or external authorization shall not be treated as valid without integrity, freshness, source, scope, and context verification appropriate to the risk.

3.5.4  The system shall define behavior for communication loss, inconsistent world states, stale reservations, conflicting peer claims, unavailable infrastructure, and partial swarm participation.

3.5.5  Where the candidate action depends on a common object or shared region, the execution envelope shall identify the relevant object, region, time interval, authority, and conflict conditions.

3.5.6  Public-space operation shall require verification of applicable operational authority, mission authority, access permission, supervision condition, or other declared prerequisites before authority is granted.

3.6 TB-V5 — Independent Safety Authority

TB-V5 establishes the strongest TB-PAS class by requiring protected enforcement and an independently available minimum-risk capability.

3.6.1  The enforcement function shall be logically or physically independent from the AI action generator to a degree commensurate with the claimed risk and operating domain.

3.6.2  The AI action generator shall not be able to bypass, disable, rewrite, self-authorize, or suppress the enforcement decision through ordinary software control.

3.6.3  The actuator gating function shall be non-bypassable for in-scope ordinary AI-generated actions and shall fail closed when authorization cannot be verified.

3.6.4  Safety-critical code, policy, token verification, revocation logic, and minimum-risk actions shall execute in protected memory, protected privilege, protected hardware, independent hardware, or another demonstrably isolated mechanism appropriate to the risk.

3.6.5  The safety-action controller shall be capable of initiating an independently defined minimum-risk action when AI authority is denied or revoked.

3.6.6  The minimum-risk action shall not depend on continued generation of candidate actions by the unsafe, failed, compromised, or unauthorized AI action generator.

3.6.7  The system shall detect and record attempted bypass, unauthorized policy change, authorization forgery, token replay, enforcement disablement, and integrity failure.

3.7 Class Selection and Declaration

3.7.1  The supplier shall map each safety-relevant action category and operating mode to the minimum validation class required by the system risk assessment.

3.7.2  A lower validation class shall not be used merely because a higher-class validator is temporarily unavailable unless the degraded-mode analysis expressly permits the lower class and constrains authority accordingly.

3.7.3  The system shall make the currently applied class, validator set, degraded-mode status, and authorization limitations available to the evidence recorder and, where appropriate, the operator.

3.7.4  A certification report shall identify actions or modes excluded from the conformance claim.

PART 4 — TB-PAS-H1 HUMANOID PHYSICAL ACTION SAFETY PROFILE

4.1 Applicability

TB-PAS-H1 supplements the general TB-PAS requirements for a humanoid or humanoid-like Physical AI system having a substantially articulated body, whole-body balance requirements, legged locomotion, human-scale reach, contact-capable manipulators, or operation in spaces designed for people.

4.1.1  A claim of TB-PAS-H1 conformity shall identify the humanoid configuration, supported end effectors, tools, payloads, operating surfaces, footwear or foot interfaces, sensor configuration, and supported operating domains.

4.1.2  The humanoid profile shall be applied to whole-body actions and to local actions that can materially affect balance, support, momentum, contact, nearby persons, or shared objects.

4.1.3  Humanoid validation shall consider coupled consequences across the feet, legs, pelvis, torso, arms, hands, head, carried objects, tools, support surfaces, and nearby entities as applicable.

4.2 Whole-Body Stability

4.2.1  Before authorizing a safety-relevant whole-body action, the system shall evaluate the support polygon or support region, predicted center of mass, angular momentum, foot or support contact, terrain condition, recovery-step availability, fall direction, and nearby persons or objects as applicable.

4.2.2  The validator shall consider dynamic transitions, including stepping, turning, reaching, lifting, pushing, pulling, kneeling, sitting, standing, stair traversal, slope traversal, and recovery movement.

4.2.3  A local limb action shall be escalated to whole-body validation when the action can materially alter balance, support, momentum, payload distribution, or fall consequence.

4.2.4  The execution envelope shall identify balance-relevant limits, including permitted support states, center-of-mass or stability margins, foot-contact conditions, momentum limits, body-region constraints, and recovery availability as applicable.

4.2.5  Loss, degradation, or inconsistency of stability-critical sensing shall cause constrained authority, a protected stabilization action, or authority revocation according to the declared degraded-mode policy.

4.3 Fall-Consequence Management

4.3.1  The humanoid validator shall evaluate not only the probability of falling but also the predicted consequences of a possible fall.

4.3.2  Fall-consequence evaluation shall consider likely impact region, human strike risk, object crush risk, self-damage, tool or payload hazards, secondary collision, entrapment, and obstruction of an escape or access path as applicable.

4.3.3  The system shall identify available fall-avoidance and harm-reduction alternatives, which may include a recovery step, kneeling, sitting, grasping an approved support, lowering a payload, protective arm placement, controlled energy dissipation, or a directed controlled fall.

4.3.4  A commanded action shall be modified or denied when its predicted fall consequence is unacceptable even if the predicted probability of falling is below a general balance threshold.

4.3.5  When a fall becomes unavoidable, the safety-action controller should select an available minimum-risk fall response based on current surroundings rather than applying a single fixed shutdown response.

4.4 Manipulation and Whole-Body Coupling

4.4.1  A manipulation validator shall evaluate reaction forces and moments transmitted through the hand, arm, torso, pelvis, legs, feet, support surfaces, object, and nearby person when material to safety.

4.4.2  Lifting, pulling, pushing, carrying, bracing, drilling, cutting, opening, restraining, transferring, or tool-use actions shall be evaluated for whole-body stability when the action can materially change balance or support conditions.

4.4.3  The system shall account for uncertain object mass, center of mass, attachment, friction, compliance, mobility, stored energy, and human co-manipulation as applicable.

4.4.4  The authorization shall constrain the coupled action, not merely the local hand or joint command, when safety depends on coordinated whole-body behavior.

4.4.5  A material unexpected change in payload, resistance, support, contact, or object motion shall trigger revalidation, constrained response, or revocation.

4.5 Human Social Space

A humanoid operating in human environments can create hazards through socially unexpected motion even when conventional mechanical limits are not exceeded. TB-PAS-H1 therefore requires explicit treatment of human social-space behavior.

4.5.1  The system shall define and enforce context-appropriate limits for approach velocity, passing distance, following distance, gaze or head orientation, hand presentation, unexpected reaching, body orientation, doorway interaction, elevator interaction, and operation near vulnerable persons where applicable.

4.5.2  The validator shall consider whether a physically feasible action is likely to surprise, intimidate, trap, crowd, obstruct, pursue, or pressure a nearby person.

4.5.3  A humanoid shall not interpret physical capability alone as authorization to enter a person’s intimate or restricted space, initiate contact, follow, block passage, take an object, or continue an interaction after withdrawal or refusal.

4.5.4  Operation near children, older adults, persons with disabilities, patients, learners, or other declared vulnerable groups shall use conservative constraints and interaction policies appropriate to the intended use.

4.5.5  The system shall provide a visible, audible, gestural, interface-based, or environmental indication of relevant intent, authorization state, degraded mode, or inability to comply when such indication is necessary for safe interaction.

4.6 Public-Space Authority

4.6.1  Before authorizing entry into or operation within a controlled, shared, commercial, municipal, transportation, or public space, the system shall verify the operational prerequisites declared for that space and mission.

4.6.2  Prerequisites may include ownership authority, mission authority, access permission, supervision status, insurance or bond status, operator identity, jurisdictional restriction, reservation, payment, infrastructure permission, capability status, or time-limited operating approval.

4.6.3  The system shall distinguish physical feasibility from legal, contractual, ownership, mission, and public-space authority.

4.6.4  Loss or expiration of a required authorization shall cause route modification, restricted behavior, exit, safe waiting, human escalation, or another defined minimum-risk response.

4.6.5  Public-space evidence shall record the authority source, scope, validity interval, location, mission, relevant conditions, and disposition of the action.

4.7 Humanoid Degraded Mode and Minimum-Risk Actions

4.7.1  The humanoid supplier shall define degraded-mode authority for loss or degradation of balance sensing, tactile sensing, localization, vision, communications, compute, actuator feedback, hand function, foot contact estimation, world-model confidence, and authorization services as applicable.

4.7.2  A degraded humanoid shall not continue ordinary whole-body operation solely because the previous action was authorized before the degradation occurred.

4.7.3  Minimum-risk actions shall account for the humanoid’s current posture, momentum, payload, support surface, nearby persons, tools, and available safe supports.

4.7.4  Examples of humanoid minimum-risk actions include stopping, holding, stabilizing, lowering a payload, placing a tool, retracting an arm, kneeling, sitting, moving to a safe waiting location, requesting assistance, or executing a controlled fall.

4.7.5  A fixed removal of actuator power shall not be used as the sole minimum-risk response where uncontrolled collapse would create a greater foreseeable hazard.

4.8 TB-PAS-H1 Profile Declaration

A TB-PAS-H1 conformance declaration shall include, at minimum, the following information:

PART 5 — PHYSICAL-AUTHORITY TOKEN

5.1 Purpose

The physical-authority token provides a machine-verifiable link between predictive or deterministic validation and actual actuator permission. It is intended to prevent a general approval, stale decision, or unrelated safety check from being reused as authority for a different action, actuator, robot, context, or time period.

5.2 Mandatory Token Properties

5.2.1  Every authorized in-scope action shall be associated with a physical-authority token or an equivalent machine-verifiable authorization object.

5.2.2  The token shall identify the authorized action and shall be unambiguously distinguishable from the candidate action before authorization.

5.2.3  The token shall be bound to the robot or device, affected actuator or body-region scope, applicable context, validity interval, and execution envelope.

5.2.4  The token shall include or reference sufficient integrity information to detect unauthorized alteration, substitution, replay, or scope expansion.

5.2.5  The token shall not grant authority beyond the validators, policies, assumptions, and limits reflected in the authorization decision.

5.3 Required and Conditional Fields

5.4 Token Issuance

5.4.1  A token shall be issued only by an authorization function permitted to grant the claimed class of physical authority.

5.4.2  The issuer shall verify that all mandatory validators and policies have completed successfully and that required evidence is available before token issuance.

5.4.3  The issuer shall assign the narrowest practical actuator, body-region, action, context, parameter, and time scope consistent with the authorized action.

5.4.4  A materially changed candidate action shall receive a new token or a verifiably updated token bound to the new action version and revalidation evidence.

5.4.5  A token shall not be issued when the system is unable to determine whether the action can be enforced within the declared execution envelope.

5.5 Token Verification and Enforcement

5.5.1  The actuator firewall or hardware controller shall verify the token before accepting or continuing the associated command.

5.5.2  Verification shall include integrity, issuer authority, robot identity, actuator or body-region scope, candidate-action identity, action version, validity interval, replay control, relevant context binding, and execution-envelope compatibility as applicable.

5.5.3  The actuator firewall shall compare the received command with the authorized action or action bounds and shall reject any material mismatch.

5.5.4  Where a token permits a sequence or stream of commands, the system shall constrain the sequence or stream to the authorized parameters, ordering, duration, and revocation conditions.

5.5.5  Token verification failure shall cause a predefined fail-closed response and shall generate audit evidence.

5.6 Mandatory Rejection Conditions

The actuator firewall or hardware controller shall reject, prevent, or terminate a command when any of the following conditions applies:

• no token or equivalent authorization object is present;

• the token cannot be authenticated or its integrity cannot be verified;

• the token is expired, not yet valid, revoked, or already consumed where single use is required;

• the token has been replayed or its sequence state is invalid;

• the command differs materially from the authorized action;

• the command exceeds the execution envelope;

• the token was issued for a different robot, actuator, body region, tool, payload, person, object, location, mission, or context;

• a required environmental or robot-state binding is stale or mismatched;

• the issuer lacks authority for the requested class or action;

• required monitoring or revocation capability is unavailable; or

• another declared revocation condition is present.

5.7 Revocation and Completion

5.7.1  A token shall support revocation before or during execution when a declared revocation condition occurs.

5.7.2  Revocation shall propagate to each affected actuator-control endpoint within the declared maximum revocation latency.

5.7.3  After revocation, any residual buffered, queued, repeated, or streamed commands covered by the token shall be invalid unless separately authorized as part of the minimum-risk response.

5.7.4  Completion shall close, consume, expire, or otherwise prevent unintended reuse of the authorization.

5.7.5  The evidence record shall correlate token issuance, verification, execution, monitoring, revocation, minimum-risk response, and completion.

5.8 Security and Privacy

5.8.1  The token mechanism shall protect against forgery, unauthorized modification, replay, substitution, downgrade, privilege escalation, and unauthorized scope expansion commensurate with the claimed risk.

5.8.2  Cryptographic keys, protected handles, counters, authorization policies, and verifier code shall be protected from unauthorized access and modification.

5.8.3  The system shall define behavior for key rotation, clock failure, counter loss, verifier reset, rollback, software update, and trust-anchor compromise.

5.8.4  Token and evidence fields shall minimize unnecessary personal, biometric, health, location, or identity data while retaining the information required for safety, accountability, and lawful operation.

5.8.5  Where a privacy-sensitive context is referenced, the token may use a protected identifier, hash, capability, or evidence handle rather than disclosing the underlying personal data to each actuator endpoint.

5.9 Interoperability

5.9.1  A published token profile shall specify field semantics, serialization, versioning, validation rules, error handling, replay protection, time representation, identity binding, integrity mechanism, and extension handling.

5.9.2  Unknown mandatory fields, unsupported versions, invalid critical extensions, or ambiguous scope shall cause rejection rather than permissive interpretation.

5.9.3  A vendor-specific implementation may use a proprietary internal representation provided that an interoperable conformance interface or test adapter exposes the required observable token behavior.

5.9.4  Interoperability shall not weaken validator independence, token integrity, execution-envelope enforcement, or fail-closed behavior.

PART 6 — TEST AND CERTIFICATION REQUIREMENTS

6.1 General

A TB-PAS conformance claim shall be supported by repeatable tests demonstrating that the mandatory action pipeline, claimed validation classes, applicable profiles, physical-authority token, actuator enforcement, execution monitoring, revocation, minimum-risk actions, and evidence recording behave as specified.

6.1.1  Testing shall cover normal operation, boundary conditions, foreseeable misuse, injected faults, communication failures, stale state, conflicting evidence, validator disagreement, degraded modes, attempted bypass, and recovery.

6.1.2  Tests shall be performed on the production-representative system or on a configuration whose differences are documented and shown not to invalidate the result.

6.1.3  Simulation may be used to supplement testing but shall not be the sole evidence for enforcement, token verification, physical timing, actuator behavior, or minimum-risk response where those properties depend on real hardware.

6.1.4  The test plan shall trace each claimed requirement to one or more test cases, analyses, inspections, or evidence reviews.

6.2 Test Case Specification

Each test case shall specify, at minimum:

• test identifier and revision;

• requirements and conformance claims covered;

• system, software, firmware, model, policy, validator, and hardware versions;

• initial robot, environment, person, object, infrastructure, authorization, and network state;

• candidate physical action;

• injected fault, hazard, uncertainty, change, misuse, or attack condition;

• required TrustBoundary response;

• maximum permitted detection, validation, enforcement, and revocation time;

• permitted fallback or minimum-risk actions;

• required validation, token, audit, and execution evidence;

• measured results and instrumentation uncertainty;

• objective pass/fail criteria; and

• test disposition, deviations, and reviewer approval.

6.3 Core Conformance Test Scenarios

6.4 Validation-Class-Specific Testing

6.5 Timing and Performance Criteria

6.5.1  The supplier shall declare maximum permissible latency for interception, normalization, validation, authorization, token verification, monitoring, revocation, and minimum-risk response for each safety-relevant action category.

6.5.2  Timing tests shall measure worst-case or justified high-percentile performance under representative maximum load, network delay, validator contention, logging load, update activity, and degraded operation.

6.5.3  A test shall fail when a required safety response exceeds the declared maximum time, even if the eventual decision is correct.

6.5.4  The declared response time shall be derived from the physical hazard, stopping or control capability, robot state, environment, and intended use rather than from average software performance alone.

6.5.5  Where deterministic timing cannot be guaranteed, the execution envelope shall provide sufficient physical margin to remain safe under the declared worst-case response time.

6.6 Evidence and Audit Review

6.6.1  Certification testing shall verify that validation evidence is complete, correctly correlated, integrity-protected, and sufficient to reconstruct the tested decision.

6.6.2  The evidence review shall confirm that denied and revoked actions do not appear as completed authorized actions and that modified actions preserve version lineage.

6.6.3  The review shall verify that attempted bypass, token failure, replay, stale context, validator disagreement, degraded mode, minimum-risk action, and recovery are recorded as required.

6.6.4  Privacy-sensitive evidence shall be reviewed for minimization, access control, retention, and lawful handling without removing information necessary to establish safety conformance.

6.7 Certification Levels

6.8 Certification Report

The certification report shall include:

• the product and configuration tested;

• the TB-PAS version, classes, profiles, action categories, and operating domains claimed;

• all exclusions and limitations;

• system architecture and TrustBoundary placement;

• validator, policy, authorization, token, actuator-firewall, monitoring, and safety-controller descriptions;

• declared timing and degraded-mode behavior;