TRUSTBOUNDARY™

PHYSICAL AI SAFETY STANDARD

TB-PAS 1.0

Establishing an AI-to-Actuator Safety Boundaryfor Humanoid Robots and Physical AI

WHITE PAPER

Working Draft for Public Comment  |  Version 1.0  |  July 2026

Published by TrustRobotics

“No inference without validation. No validation without evidence. No actuation without authority. No continued authority outside the authorized physical envelope.”

Document Status and Important Notice

This white paper explains the technical rationale, architecture, conformance model, and intended industry role of the TrustBoundary Physical AI Safety Standard (TB-PAS 1.0) working draft. The normative TB-PAS specification remains the controlling source for conformance requirements. Where this white paper simplifies or illustrates a requirement, the normative specification controls.

TB-PAS is a private technical specification. It is not an ISO, IEC, IEEE, ANSI, ASTM, governmental, or regulatory standard. It does not replace applicable law, machinery-safety requirements, functional-safety engineering, cybersecurity requirements, product certification, workplace rules, or sector-specific obligations.

Standards statuses stated in this paper are current as of July 27, 2026 and are included for contextual comparison. Implementers should verify the latest editions, regional adoptions, and application-specific requirements before relying on any external standard.

Contents

• Executive Summary

• 1. The Safety Problem Created by Physical AI

• 2. The Existing Standards Landscape and the Missing Runtime Layer

• 3. TB-PAS 1.0 at a Glance

• 4. Part 1 — Terminology and Architecture

• 5. Part 2 — Mandatory Action Pipeline

• 6. Part 3 — Validation Classes

• 7. Part 4 — Humanoid Physical Action Safety Profile

• 8. Part 5 — Physical-Authority Token

• 9. Part 6 — Test and Certification Requirements

• 10. Implementation Patterns

• 11. Representative Use Cases

• 12. Certification, Governance, and Adoption Roadmap

• 13. Open Standard and Intellectual-Property Principles

• Conclusion

• References

• Appendix A — Core Principles

• Appendix B — Public-Comment Questions

Executive Summary

Artificial intelligence is moving from generating information to generating physical behavior. A language model can now initiate a mission, a vision-language-action model can select a manipulation, a world model can predict a route, and a learned controller can command a humanoid body. Once an inference can cause motors, brakes, grippers, tools, energy systems, or mobility subsystems to move, AI safety becomes a physical-authority problem.

Traditional robot safety remains essential, but it was largely developed around machines whose intended motions, control structures, hazards, and operating environments could be bounded during design and integration. Physical AI changes this assumption. The action may be generated at runtime, revised by a model, conditioned on uncertain perception, distributed across cloud and edge systems, or changed after deployment. The robot may produce a physically plausible action that is nevertheless unsafe, unauthorized, contextually invalid, socially unacceptable, or inconsistent with the state that was evaluated moments earlier.

TB-PAS 1.0 defines an implementation-neutral architecture for that boundary. It requires interception of AI-generated candidate physical actions; normalization into a testable action representation; deterministic and, where required, predictive validation; action-specific release authorization; machine-verifiable enforcement at the actuator boundary; continuous monitoring; authority revocation; and transfer to protected minimum-risk actions when ordinary AI authority is unavailable or unsafe.

Figure 1 — The TB-PAS mandatory action pipeline.

The initial standard is organized into six parts:

TB-PAS is intended to complement established standards, not displace them. ISO robot standards can establish product and application safety requirements; IEC functional-safety standards can govern safety-related control functions and integrity; ISO/IEC AI standards can govern organizational risk management; IEEE standards can define ethical, ontological, transparency, and fail-safe frameworks. TB-PAS supplies a missing product-runtime layer: whether a particular AI-generated physical action should receive actuator authority in the present context.

1. The Safety Problem Created by Physical AI

1.1 From information outputs to physical consequences

A conventional information system can produce an incorrect answer without directly changing the physical world. A Physical AI system can convert an incorrect or contextually invalid output into movement, contact, force, momentum, heat, pressure, electrical energy, tool operation, or access to restricted space. The safety consequence is no longer confined to information quality.

Physical AI also compresses the distance between model inference and actuation. The same model stack may interpret a human request, perceive a scene, select an action, produce a trajectory, and update that action while the robot is moving. This creates safety risks at the precise point where software-generated intent becomes physical authority.

1.2 Why conventional command acceptance is insufficient

A motor controller ordinarily accepts commands that satisfy interface and electrical constraints. A robot controller may ensure that joint commands are syntactically valid and within fixed limits. Those checks remain necessary, but they do not establish that the action was evaluated as a whole, that its predicted consequences are acceptable, that the relevant context remains valid, or that the source model is authorized to cause the action.

For example, a joint trajectory can remain within every individual joint limit while causing the humanoid to lose balance, strike a nearby person, crush an object, violate a public-space rule, or continue using stale environmental assumptions. Safety therefore requires more than command validity. It requires action validity and context-bound physical authority.

1.3 The five recurring failure modes

1.4 Safety as a transfer-of-authority decision

TB-PAS treats the transition from AI inference to actuation as a formal transfer of authority. The AI action generator may propose. The TrustBoundary evaluates. The authorization engine grants, modifies, delays, or denies. The actuator firewall enforces. The execution monitor determines whether the authority remains valid. The safety-action controller acts when ordinary AI authority is denied or revoked.

2. The Existing Standards Landscape and the Missing Runtime Layer

2.1 TB-PAS is designed as a complementary layer

Physical AI systems will continue to require conventional safety engineering. A TrustBoundary cannot substitute for safe mechanical design, protective systems, risk assessment, electrical design, verified safety functions, cybersecurity, or operational controls. The intended role of TB-PAS is narrower and technically specific: governing the runtime grant and continued enforcement of physical authority for AI-generated actions.

2.2 The missing question

Existing frameworks can answer many essential questions: Was the machine designed safely? Are collaborative contact limits controlled? Is a safety function implemented with adequate integrity? Does the organization manage AI risk? Does the robot fail safely after anomalous behavior?

2.3 A layered standards model

3. TB-PAS 1.0 at a Glance

Figure 2 — Reference logical architecture. Functions may be allocated across software, firmware, processors, motor controllers, networks, or independent hardware.

3.1 Design principles

3.2 Implementation neutrality

TB-PAS does not require a particular neural architecture, model provider, operating system, processor, bus, motor controller, or robot form factor. A conforming implementation may be software-only for lower-risk use, may rely on a protected safety controller, may enforce tokens inside motor controllers, or may distribute validation across robots and infrastructure. The standard focuses on observable interfaces, evidence, and outcomes.

3.3 Risk-proportionate assurance

Not every action requires the same validation burden. A low-energy internal camera adjustment may require deterministic bounds. Walking beside a child, carrying a heavy object, using a sharp tool, or operating in public space may require predictive, tactile, multi-agent, and independently enforced validation. TB-PAS therefore uses progressive validation classes and action-category declarations rather than a single undifferentiated certification claim.

4. Part 1 — Terminology and Architecture

4.1 A vocabulary for physical authority

Common vocabulary is not merely editorial. It determines what engineers design, what test laboratories measure, what insurers underwrite, what regulators can require, and what manufacturers can claim. TB-PAS Part 1 introduces terms that make the AI-to-actuator boundary testable and commercially interoperable.

4.2 Required logical roles

4.3 Non-bypassable coverage

A standard action path is insufficient if maintenance, remote, debug, update, emergency, simulation-transfer, or alternate communication paths can command actuators without equivalent controls. Part 1 therefore requires identification and documentation of all physical command paths. Any exception must be independently justified and protected as a safety-action path, not silently treated as a bypass.

5. Part 2 — Mandatory Action Pipeline

Figure 3 — Minimum observable sequence required by Part 2.

5.1 Generate

The AI action generator produces or selects a candidate physical action. The candidate can originate from a language model, vision-language-action model, world model, policy, motion planner, cloud service, human command interpreted by AI, or multi-agent process. At this stage the output has no final actuator authority.

5.2 Intercept

Every in-scope candidate action must cross the TrustBoundary. Interception should occur before an actuator-control endpoint accepts the action and should cover direct commands, trajectories, force profiles, tool operations, body-region commands, and mission-level outputs that are automatically translated into physical execution.

5.3 Normalize

Different AI systems express action differently. Normalization converts the output into an evaluation-ready representation containing the action identity, source, target body region or actuator, trajectory or control parameters, timing, assumptions, intended outcome, and relevant context. Normalization makes heterogeneous models testable through a common boundary.

5.4 Predict

Where the action category or risk requires TB-V2 or higher, the system estimates future physical consequences. Prediction can include collision, balance, support, force, contact, object motion, shared occupancy, energy, infrastructure state, public-space authorization, or other prospective outcomes. The standard does not mandate a particular predictive method, but it requires declared validity, uncertainty handling, and evidence.

5.5 Evaluate

The validator set applies applicable deterministic limits, predictive consequences, contact conditions, multi-agent states, infrastructure permissions, policy rules, and integrity checks. The authorization engine must use the required evidence set rather than allowing the AI generator to select only favorable results.

5.6 Authorize

The TrustBoundary can authorize the original action, authorize a constrained or modified version, delay pending additional evidence, decompose the action, reroute it, substitute a minimum-risk or approved alternative, or deny it. Authorization produces a machine-verifiable physical-authority token or equivalent protected handle.

5.7 Enforce

The actuator firewall verifies the authorization before physical execution. It rejects commands lacking valid authority, commands outside the actuator or body-region scope, expired or replayed tokens, altered tokens, mismatched action versions, and parameters exceeding the execution envelope.

5.8 Monitor

Physical authority is not irrevocable. The execution monitor checks whether the robot, action, environment, integrity state, and timing remain within the assumptions and limits used for authorization. Material changes trigger revalidation, constrained continuation, or revocation.

5.9 Revoke or complete

On successful completion, the authorization is consumed or closed and evidence is recorded. When authority is revoked, the ordinary AI action stops receiving physical authority and the system executes a context-appropriate protected response. A humanoid may need to stabilize, kneel, lower a payload, assume a protective posture, or perform a controlled fall rather than simply lose power.

6. Part 3 — Validation Classes

Figure 4 — Progressive validation classes TB-V1 through TB-V5.

6.1 TB-V1 — Deterministic Constraint Validation

TB-V1 checks fixed limits, permissions, and prohibited conditions. Representative controls include joint range, maximum torque, maximum velocity, geofence, payload limit, prohibited object, human-clearance requirement, source authorization, action whitelist, and operating-mode rules. TB-V1 is the minimum baseline for a general TB-PAS conformance claim.

6.2 TB-V2 — Predictive Physical Validation

TB-V2 evaluates future physical consequences. A system may use world models, learned dynamics, collision prediction, balance prediction, force prediction, trajectory simulation, digital twins, or heterogeneous combinations. TB-V2 is especially important where a fixed rule cannot capture the interaction among body configuration, environment, timing, and action sequence.

6.3 TB-V3 — Contact and Tactile Prediction

TB-V3 addresses contact-rich behavior: grasping, object transfer, tool use, human contact, fragile objects, high-force manipulation, dexterous hands, slip, entrapment, unexpected resistance, and contact-location constraints. It connects tactile and force evidence to the authorization and monitoring process rather than treating contact sensing only as post-event feedback.

6.4 TB-V4 — Multi-Agent and Infrastructure Validation

TB-V4 expands the safety context beyond one robot. It evaluates nearby robot actions, shared occupancy, common-object state, peer conflicts, reservations, infrastructure permissions, access rights, network or service state, and public-space authorization. A single robot’s local action can be unsafe because of another agent’s planned motion or because a permission has expired.

6.5 TB-V5 — Independent Safety Authority

TB-V5 requires logically or physically independent enforcement, protected execution, non-bypassable actuator gating, fail-closed behavior for ordinary AI authority, and independent minimum-risk actions. Independence may be established through protected processes, privilege separation, separate processors, motor-controller enforcement, cryptographic verification, electrical isolation, or physically independent hardware—provided that the declared threat model and tests are satisfied.

6.6 Class selection by action category

7. Part 4 — Humanoid Physical Action Safety Profile

Figure 5 — TB-PAS-H1 adds humanoid-specific whole-body and public-interaction requirements.

7.1 Why humanoids need a dedicated profile

Humanoids combine active balance, whole-body momentum, long reach, dexterous manipulation, expressive head and gaze behavior, human-scale operation, and potential access to spaces built for people. A safety decision limited to one joint or one arm can miss whole-body consequences. A stop command can itself cause collapse. Social and public-space behavior can become safety relevant because people interpret humanoid approach, gaze, following, reaching, and hand presentation as intentional conduct.

7.2 Whole-body stability

The validator should evaluate support polygon, predicted center of mass, angular momentum, foot contact, terrain condition, recovery-step availability, fall direction, payload effect, and nearby persons or objects. A manipulation that is locally feasible may be globally unsafe because it shifts the support condition or consumes the robot’s recovery capacity.

7.3 Fall-consequence management

A humanoid can satisfy a nominal balance controller yet still present unacceptable consequences if recovery fails. TB-PAS-H1 therefore treats fall direction, likely impact region, human strike risk, object crush risk, self-damage, safe kneeling, protective arm placement, energy dissipation, and controlled fall as prospective validation and minimum-risk issues.

7.4 Manipulation and whole-body coupling

Lifting, pushing, pulling, tool use, and object transfer couple the hands to the torso, legs, support surface, object, and nearby people. The standard requires cross-body evaluation whenever a candidate action can materially alter balance, support, load path, reachable space, or fall consequences.

7.5 Human social space

Humanoid safety is affected by approach velocity, passing distance, gaze direction, head orientation, hand presentation, unexpected reaching, following behavior, doorway and elevator interactions, and operation near children or vulnerable persons. These requirements are not an attempt to regulate personality. They establish measurable physical-behavior constraints for human-scale robots operating in shared space.

7.6 Public-space authority

A humanoid should not ask only whether it can physically enter or traverse a space. The TrustBoundary can evaluate whether the robot is authorized, insured, supervised, capable, reserved, paid, and permitted under the applicable mission, premises, infrastructure, or jurisdictional conditions. Expiration of public-space authority becomes a revocation condition requiring a safe route, exit, stop, wait, or request for assistance.

8. Part 5 — Physical-Authority Token

Figure 6 — The physical-authority token binds validation to enforceable execution.

8.1 Why a token is necessary

A Boolean “safe” signal is too weak for heterogeneous Physical AI systems. It can be detached from the action that was evaluated, reused after the context changes, presented to a different actuator, or replayed after completion. The physical-authority token carries the scope and conditions of authorization to the enforcement point.

8.2 Minimum information model

8.3 Token lifecycle

1  Issue. The authorization engine produces the token only after required validation and policy conditions are satisfied.

2  Verify. The actuator firewall verifies integrity, identity, scope, timing, replay controls, and action match.

3  Execute. The actuator accepts only commands covered by the execution envelope.

4  Monitor. The system tests continuing validity of robot state, environment, action, evidence, and timing.

5  Refresh or revoke. Material changes require updated validation or immediate withdrawal of authority.

6  Consume and close. Completion, expiration, or revocation prevents later replay and closes the evidence record.

8.4 Security and interoperability

The token can be serialized as a signed message, protected memory object, capability handle, secure bus transaction, motor-controller authorization, or other machine-verifiable representation. TB-PAS defines required semantics and behavior rather than one wire format. A future interoperability profile can standardize schemas, cryptographic suites, timing classes, and actuator interfaces.

9. Part 6 — Test and Certification Requirements

Figure 7 — Conformance is a lifecycle, not a one-time demonstration.

9.1 Testable safety, not aspirational safety

A standard becomes commercially meaningful when a laboratory, integrator, insurer, customer, or regulator can determine whether the system passes. TB-PAS Part 6 therefore requires declared scope, initial conditions, candidate action, injected fault or hazard, required TrustBoundary response, maximum response time, permitted fallback action, audit evidence, and objective pass/fail criteria.

9.2 Core scenario families

9.3 Certification claims

9.4 Evidence package

• system and subsystem identification;

• hardware, software, model, validator, policy, and token versions;

• declared operating domain and action categories;

• validation-class mapping and timing deadlines;

• test procedures, injected faults, raw results, logs, and pass/fail determinations;

• known exclusions, external dependencies, degraded modes, and minimum-risk actions;

• cybersecurity assumptions affecting token and boundary integrity;

• material-change criteria and recertification triggers.

9.5 Recertification

A certification claim should be re-evaluated after material changes to the AI action generator, validator set, safety controller, actuator interface, token format, policy set, operating domain, body configuration, sensor suite, public-space authorization model, or minimum-risk behavior. Field incidents and near misses should feed the renewal process.

10. Implementation Patterns

10.1 Software TrustBoundary

A software-only implementation can intercept actions in the robot operating system or middleware, normalize commands, call validators, issue protected software authorizations, and enforce them in a privileged actuator-dispatch layer. This pattern can support TB-V1 and TB-V2 where the threat model and consequence severity permit logical independence.

10.2 Protected safety-controller implementation

A separate processor or protected execution environment can perform validation, token issuance, or enforcement independently from the generative AI compute domain. This improves resistance to software compromise and supports stronger TB-V5 claims.

10.3 Actuator-local enforcement

Motor controllers, joint controllers, brake controllers, tool controllers, and power electronics can verify action-bound authorization and enforce local torque, velocity, range, contact, timing, and revocation conditions. Actuator-local enforcement reduces the possibility that an upstream compromise can bypass the boundary.

10.4 Distributed and multi-agent implementation

TB-V4 may distribute validation evidence across peer robots, shared world models, facilities, access-control systems, elevators, chargers, vehicles, public infrastructure, and remote services. The authorization engine should distinguish missing or stale evidence from affirmative permission and should not infer authority from silence.

10.5 Independent minimum-risk controller

For high-consequence systems, the safety-action controller should remain capable of stabilization or controlled safe behavior even when the ordinary AI generator, network, or main compute stack fails. The protected controller should have only the authority necessary to reduce risk, not unrestricted mission authority.

10.6 Example allocation table

11. Representative Use Cases

11.1 Humanoid factory assistant

A humanoid retrieves parts, carries loads, uses tools, and works near people. TB-V1 limits speed, force, work zones, payload, and tool permissions. TB-V2 predicts balance and collision. TB-V3 evaluates grasp and handover contact. TB-V4 coordinates shared aisles and equipment. TB-V5 enforces authorization at motor controllers and preserves independent stabilization.

11.2 Service humanoid in a public building

The robot navigates lobbies, elevators, doorways, and crowded spaces. The H1 profile governs approach, passing, gaze, unexpected reaching, and vulnerable-person operation. Public-space authorization binds the robot’s mission, access rights, supervision, insurance, reservations, and operating domain to physical authority.

11.3 Warehouse mobile manipulator

A mobile manipulator executes model-generated picks and routes. TB-PAS binds each pick and trajectory to object identity, payload, aisle state, human occupancy, gripper limits, and validity period. A changed pallet or worker location invalidates stale authorization before execution continues.

11.4 Care and medical-support robot

The system operates near vulnerable people, transfers objects, supports movement, or handles sensitive equipment. TB-V3 evaluates contact and force, while authorization policy can require caregiver or clinician approval for defined actions. Degraded sensing causes reduced authority rather than continued operation based on optimistic inference.

11.5 Multi-robot cooperative lift

Two or more robots share a load. No robot can validate its action solely from local state. TB-V4 evaluates common-object state, peer timing, force contribution, shared occupancy, communication health, and fallback behavior. Loss of one robot’s authority triggers a coordinated minimum-risk response.

12. Certification, Governance, and Adoption Roadmap

12.1 Stage 1 — Public technical specification

Publish TB-PAS 1.0 as an open working draft with normative “shall” requirements, informative rationale, conformance classes, test scenarios, version history, patent notice, and public-comment procedure. The current Parts 1–6 working draft establishes this baseline.

12.2 Stage 2 — Reference schemas and implementation

Publish candidate-action, physical-authority-token, validation-evidence, and revocation schemas together with a reference middleware implementation and test harness. The reference implementation can be open source even where particular optimized or safety-certified implementations are proprietary.

12.3 Stage 3 — Industry working group

Create a balanced working group including humanoid manufacturers, actuator suppliers, robot operating-system developers, functional-safety engineers, testing laboratories, insurers, researchers, premises operators, worker representatives, accessibility experts, and public-interest participants. Governance should include conflict-of-interest disclosure, recorded issue resolution, version control, and transparent change proposals.

12.4 Stage 4 — Conformance testing and certification marks

Develop laboratory procedures, standardized fault-injection tools, timing classes, evidence formats, test fixtures, and certification marks. Initial certification may be performed by TrustRobotics-approved laboratories, with a transition toward independent accreditation and mutual recognition.

12.5 Stage 5 — Formal standards submission

After implementation evidence and industry participation mature, submit appropriate portions to a recognized standards-development organization. Runtime architecture, authorization tokens, interoperability, and validator interfaces may fit an IEEE pathway; robot-safety profiles may fit ISO/TC 299 work; test methods may fit ASTM or other performance-oriented venues. The submission strategy should preserve compatibility with existing safety standards and formal patent-disclosure obligations.

12.6 Version governance

13. Open Standard and Intellectual-Property Principles

A credible safety standard must be implementable, testable, and transparent. It must also be candid about intellectual property. TrustRobotics should distinguish the open normative interface from patented implementation technologies and avoid implying that implementation is unrestricted where a license may be required.

Conclusion

Physical AI changes the safety problem from controlling a predesigned machine to controlling the runtime transfer of physical authority from an AI process. A system can satisfy traditional command syntax and fixed joint limits while still executing an unsafe, stale, unauthorized, socially unacceptable, or physically consequential action. Safety therefore requires an explicit boundary between AI-generated intent and actuator authority.

TB-PAS 1.0 proposes that boundary. It introduces a shared vocabulary, a mandatory action pipeline, progressive validation classes, a humanoid-specific profile, an action-bound physical-authority token, and testable certification requirements. It does not replace existing robot, machinery, functional-safety, cybersecurity, or AI-governance standards. It supplies the missing runtime mechanism that connects those requirements to each AI-generated physical action.

The immediate objective is practical: invite manufacturers, engineers, laboratories, insurers, researchers, and public-interest stakeholders to implement the working draft, challenge its assumptions, improve its testability, and help establish a common safety boundary before general-purpose Physical AI becomes broadly deployed.

References

Standards descriptions and development statuses were verified against official ISO, IEC, and IEEE Standards Association sources as of July 27, 2026.

Appendix A — Core Principles

Appendix B — Questions for Public Comment

1  Comment question. Are the defined logical roles sufficiently implementation-neutral for software, firmware, hardware, cloud-edge, and distributed robot architectures?

2  Comment question. Does the candidate-action definition capture mission-level outputs that automatically produce physical execution?

3  Comment question. What minimum timing classes should be standardized for locomotion, manipulation, contact, and emergency revocation?

4  Comment question. What evidence should be mandatory when predictive models are uncertain, non-deterministic, or continuously updated?

5  Comment question. How should independent validation be demonstrated when the validator and AI action generator share compute, data, or model components?

6  Comment question. Which token fields must be interoperable across robot operating systems, actuator vendors, and facilities?

7  Comment question. What cryptographic and replay-protection profiles are practical for hard real-time actuator systems?

8  Comment question. Which humanoid fall and unsafe-power-removal scenarios should be mandatory for TB-PAS-H1 certification?

9  Comment question. How should public-space authority represent insurance, supervision, reservation, payment, premises, and jurisdictional permissions?

10  Comment question. What material changes should automatically trigger partial or full recertification?

11  Comment question. How should field incidents, near misses, and blocked-action regeneration be reported without exposing sensitive personal or proprietary data?

12  Comment question. What governance and patent-licensing commitments are necessary for broad manufacturer and open-source adoption?

Technical comments should identify the relevant TB-PAS part, requirement or term; describe the problem; provide a proposed resolution; and, where possible, include an implementation example or test scenario.

TRUSTBOUNDARY™

PHYSICAL AI SAFETY STANDARD — TB-PAS 1.0

Working Draft White Paper for Public Comment

TrustRobotics

July 2026

The normative TB-PAS 1.0 specification controls conformance. This white paper is explanatory and does not constitute certification, legal advice, regulatory approval, or a representation of compliance with any external standard.