Towards Trustworthy Embodied Intelligence: A Systems Framework and Graded Trustworthiness Levels

T0No Trustworthy
T1Constrained
T2Partially
T3Conditionally
T4Highly
T5Sustained Trustworthy

TL;DR

A robot that finishes the task is not the same as a robot you can deploy. We define trustworthy embodied intelligence as sustained safe success: reliably executing specified tasks under environmental and system variation while keeping risk within acceptable bounds. We organize the mechanisms that support it into four interdependent layers — model, system, evidence, and deployment — and propose a non-normative T0–T5 hierarchy that grades how strongly, and over what scope, a trustworthiness claim can be justified and maintained.

Three claims run through the report:

Task completion is not trustworthiness. Success rate conflates safe success with success achieved through unsafe behavior. Evaluation must separate them.
Trustworthiness is a property of a deployed system, not a model. Robust perception does not ensure safe planning; a stable controller may faithfully execute an unsafe objective; formal guarantees hold only under their stated assumptions.
Every claim is bounded. A claim applies to a specific ⟨system version, task, embodiment, operating domain, authority, evidence⟩ tuple — never to a model family or a product in the abstract.

Why this matters now

Vision–language–action models, robot foundation models, world models, tactile perception, and whole-body control have expanded what embodied systems can do in manipulation, navigation, and human interaction. That progress changes the consequences of error. In a digital system, a bad prediction degrades information quality. In an embodied system, it produces unsafe motion, unintended contact, equipment damage, or physical harm.

Laboratory and simulation evaluations constrain object sets, workspace, task duration, communication, and human interaction. Deployment does not. Systems meet distribution shift, sensing and actuation degradation, communication delay, software change, and unanticipated human behavior. The gap is worst in long-horizon, contact-rich tasks, where an early perception or grounding error propagates across subtasks and only becomes visible after contact has occurred or recovery options have narrowed.

There is also no universally safe response. Stopping immediately can itself be hazardous when a robot is balancing, bearing a load, or in physical contact — the correct answer is a task-dependent minimum-risk transition, not an emergency stop.

Consequences of untrustworthy embodied intelligence across the four layers — Figure 1 — Potential consequences of untrustworthy embodied intelligence. Each layer asks one question: can the model understand the situation, can the system execute the plan, can the evidence support the claims, will it work in the real world? Failures land in one of two buckets — unable to execute (task failure, poor robustness, unreliable execution) or unsafe process (unsafe success, collision risk, unauthorized actions).

Definition: sustained safe success

Trustworthy embodied intelligence = the sustained capacity to execute specified tasks reliably under environmental and system variation while maintaining risk within acceptable bounds.

Two jointly necessary primary objectives:

Objective	What it requires
Task capability	Adequate success, quality, efficiency, timeliness, robustness, and generalization over the intended task distribution
Safety	Behavior consistent with safety preferences (ranking feasible behaviors by relative risk) and safety constraints (non-negotiable conditions for admissible execution)

They are not substitutable: high average success can hide rare severe failures, while indiscriminate refusal precludes useful work.

Five supporting properties make the objectives achievable and checkable: reliability (continuity and correctness of service), physical controllability (can available sensing, actuation, and control authority preserve or recover admissible states), governability (can authorized humans or supervisors observe, constrain, interrupt, degrade, recover, or transfer execution), evaluability (are claims measurable, traceable, and conditioned on explicit assumptions), and deployability (do those claims survive operation, maintenance, updates, and environmental change).

The four-layer framework

We take autonomous driving as an engineering analogue — driving/robot simulators for modeling, progress/task-completion objectives, vehicle-safety/contact-safety constraints, constrained optimization and safe learning, road testing and real-robot deployment, and fallback — and abstract the assurance principles that transfer. The analogy is informative but incomplete: general-purpose embodied systems must interpret open-ended instructions, handle objects of uncertain physical properties, manage changing contact, and lack a universally safe stopping response.

Engineering analogy between autonomous driving and embodied intelligence — Figure 2 — Engineering analogy between autonomous driving and trustworthy embodied intelligence across environment modeling, objective, safety definition, constrained optimization, real-world validation, and fallback.

The resulting architecture has four layers. They are functional responsibilities, not software modules, and no layer is self-sufficient.

Layer	Verb	Responsibility	Representative mechanisms
Model	Propose	Generate task-competent action proposals with calibrated uncertainty and explicit safety preferences	Grounded perception, affordance and capability reasoning, TAMP, constrained RL, world models, governable output interfaces, calibrated deferral
System	Execute	Realize authorized actions dependably; contain residual failures	Multi-rate integration, timing contracts, fault detection/isolation, collision reflexes, force limits, hardware interlocks, fail-safe brakes, minimum-risk transitions
Evidence	Substantiate	Determine which bounded claims are justified	Formal / statistical / empirical / operational evidence, staged evaluation, fault injection, adversarial testing, assurance cases
Deployment	Govern	Keep the claim valid during use	Runtime admission, boundary and assumption monitoring, authority and least privilege, intervention, incident response, change control and revalidation

Cross-layer contracts are the load-bearing idea. Proposals flow downward only together with their preconditions, uncertainty, and active constraints. Execution state, system health, and timing validity flow upward so decisions are never made on stale assumptions. Time is a first-class property: maximum data age, command lifetime, monitor period, stopping time, and response latency must be explicit, and execution is restricted when those bounds are violated.

The four-layer framework for trustworthy embodied intelligence — Figure 3 — The four-layer framework. The model layer proposes actions; the system layer realizes and constrains them physically; the evidence layer justifies bounded claims; the deployment layer maintains claim validity during operation. Arrows denote the cross-layer exchange of proposals, feedback, authority, claims, and field data — all converging on sustained safe success.

Three recurrent cross-layer problems

Semantic–physical gap — abstract instructions omit relevant geometric, dynamic, or contact constraints.
Action–consequence gap — the same command produces different physical consequences depending on state, so admissibility cannot be judged from the command alone.
Cross-layer non-compositionality — individually capable, reliable, or verified components fail to compose into a trustworthy system because their assumptions, interfaces, or constraints are incompatible.

Measuring it: safe-success rate

The primary joint outcome is the safe-success rate:

SSR = N(task completed ∧ no unacceptable violation) / N(evaluated trials)

It must be read together with its four component outcomes:

Outcome	Meaning
Safe success	Task completed without an unacceptable violation
Safe failure	Task not completed, but safety and recoverability preserved
Unsafe success	Task completed via a safety, procedural, semantic, or authority violation
Unsafe failure	Task failed and produced unacceptable risk or harm

Safe failure should be split further into justified intervention and unnecessary interruption — frequent refusal preserves safety while making the system operationally useless. Because averages cannot characterize tail risk, reports should include scenario-conditioned results, exposure, violation severity, worst observed outcome, and intervention burden. A high-energy contact and a minor safety-filter activation must not be weighted equally.

Four complementary forms of evidence

Evidence	What it supports	Main boundary
Formal	Verified properties under explicit models	Model and assumption fidelity
Statistical	Probabilistic risk and reliability claims	Sampling and distribution validity
Empirical	Observed behavior under controlled tests	Test and scenario coverage
Operational	Behavior under real deployment exposure	Observed exposure and reporting coverage

No type suffices alone, and heterogeneous results should not be aggregated into a single score. Absence of recorded harm may reflect limited exposure, conservative use, or chance — not acceptable risk.

Staged evaluation

Realism, exposure, and physical consequence should increase gradually: specification and formal analysis → offline model evaluation → simulation and digital twins → software/hardware in the loop → controlled physical evaluation → bounded pilot deployment. The process is iterative, not sequential: physical failures update simulation scenarios, virtual testing prioritizes physical experiments, and field observations trigger regression testing.

Evaluation stage	Requirements	Model behavior	Closed loop	Timing & integration	Physical interaction	Field exposure
Specification & formal analysis	✓	△	△	△	–	–
Offline model evaluation	△	✓	–	△	–	–
Simulation & digital twins	△	✓	✓	△	△	–
Software / hardware in the loop	△	△	✓	✓	△	–
Controlled physical evaluation	△	△	✓	✓	✓	–
Bounded pilot deployment	△	△	✓	✓	✓	✓

✓ primary coverage · △ supporting or partial coverage · – no direct coverage

T0–T5: Levels of Trustworthy Embodied Intelligence

Binary “trustworthy / untrustworthy” labels are useless for embodied systems. We propose six levels describing progressively stronger and more sustained forms of justified trustworthiness. Requirements are cumulative.

Concentric T0 to T5 levels of trustworthy embodied intelligence — Figure 5 — The proposed T0–T5 levels. Higher levels represent progressively stronger and more sustained claims, with T5 emphasizing maintenance of a claim under governed changes in users, sites, equipment, facilities, weather, lighting, and environment.

Level	Name	What is substantiated	Illustrative case
T0	No Trustworthy EI	No substantiated deployment claim. Demos may look strong, but task selection, resets, teleoperation, assistance, failure rates, or unsafe intermediate behavior are unreported or under-evaluated	Prototypes, selective demo videos
T1	Constrained	Narrow, largely predefined behavior under independent physical limits on position, speed, force, energy, workspace, and e-stop; continuous human supervision	Guarded industrial sequence in a restricted cell
T2	Partially	Selected or composed bounded skills, observable and governable via authority boundaries and runtime monitoring; can stop or enter a controlled condition, but timely human fallback is part of the assurance strategy	Monitored skill-level autonomy
T3	Conditionally	Responsibility for a complete task loop within a validated boundary, including recovery from specified deviations; must detect when assumptions no longer justify continuation and degrade or request help in time	Warehouse pick-and-place within validated workspace, payloads, object classes
T4	Highly	Multiple tasks or skill combinations within a validated domain; autonomously handles a defined set of foreseeable failures without depending on immediate human response; loss of planner, model, network, or a noncritical sensor must not disable local protection	Extended operation in a carefully specified domain
T5	Sustained	Justified trustworthiness is maintained as tasks, configurations, models, and conditions evolve, via a governed process that retains, restricts, or revokes capabilities based on continuing evidence	Governed fleet under traceable updates and assurance review

Five assessment dimensions

A level is assessed jointly across: (1) capability adequacy, (2) safety and residual risk, (3) system assurance, (4) evidence sufficiency, (5) deployment governance.

A TEI level cannot exceed the least adequately supported safety-critical dimension. High capability cannot compensate for uncontrolled physical risk, and restrictive safeguards cannot compensate for failing to deliver the intended service.

Transition logic

T0 → T1 — from demonstrated capability without a claim, to reproducible behavior under explicit physical constraints
T1 → T2 — from predefined behavior, to partially trustworthy autonomous skills with runtime monitoring, authority boundaries, and defined responses to known failures
T2 → T3 — from individual skills, to conditional trustworthiness of a complete task loop within a validated boundary
T3 → T4 — from reliance on timely human fallback, to autonomous handling of defined foreseeable failures
T4 → T5 — from a stable validated configuration, to sustained trustworthiness under governed change

Levels can also be downgraded when evidence expires, monitoring becomes unavailable, incidents go unresolved, or the configuration or operating domain changes. A TEI level describes the currently justified strength of a bounded claim, not permanent maturity.

How T0–T5 relates to existing taxonomies

AgiBot G1–G5 (capability)	SAE L0–L5 (driving automation)	Proposed TEI T0–T5 (justified claim)
—	L0 No driving automation	T0 No Trustworthy EI
G1 Basic automation	L1 Driver assistance	T1 Constrained
G2 Reusable atomic skills	L2 Partial driving automation	T2 Partially
G3 Data-driven skill learning	L3 Conditional driving automation	T3 Conditionally
G4 General operation model	L4 High driving automation	T4 Highly
G5 End-to-end embodied model	L5 Full driving automation	T5 Sustained

Row alignment is illustrative only — the three hierarchies classify fundamentally different properties. A system built on a highly general model may remain at T1 or T2 if monitoring, fallback, evidence, or change control are insufficient. Conversely, a narrowly capable industrial system may support a T4 claim inside a tightly constrained, extensively validated domain.

Not a certification scheme. Domain-specific profiles must define the task and operating-domain boundary, quantitative capability and safety thresholds, mandatory safeguards and fallback functions, required evaluation scenarios and evidence strength, monitoring and incident-reporting obligations, and the conditions for reassessment, downgrade, suspension, or renewal.

Runtime governance in practice

Figure 4 — Runtime governance between model-level action proposals and physical execution. The left column is the governed path: proposal with uncertainty and preconditions → runtime admission → authorized command → system-level protection → safe success or safe failure. The right column is the hazard path: adversarial input, corrupted belief, unsafe proposal, missed admission, and undetected hazard, each of which must be caught by a different layer.

Runtime admission decides whether a requested capability may execute right now, checking task and capability compatibility, system identity/configuration/health, environmental and interaction conditions, permissions and supervision, availability of monitoring/protection/fallback, and the validity of the supporting evidence. Decisions may allow, restrict, deny, or escalate — and admission is not a startup check, because its assumptions must stay monitored throughout execution.

Monitoring must attach to actionable criteria. Each monitored condition specifies the assumption being watched, the signal and update rate, the threshold indicating loss of validity, the required response and its deadline, and the authority responsible for resolving the event. Gradual degradation matters as much as sudden violation: repeated replanning, rising uncertainty, longer task duration, frequent safety-filter activation, declining grasp quality, or increasing intervention frequency all signal shrinking margins before any single event counts as a failure.

Human control must be effective, not nominal. An e-stop or takeover interface protects no one if the operator lacks information, training, physical access, or time. Rapid hazards — contact, balance, collision — belong to automatic local protection; humans are better at ambiguity, authorization, ethical judgment, recovery selection, and high-consequence decisions that allow response time. Authority transfer must be explicit and logged: who controlled execution, when it changed, on what information, and whether the recipient actually assumed control.

The assurance loop:

validate → deploy → monitor → diagnose → restrict or update → revalidate

The loop does not recertify everything after every observation. It connects each change and incident to the specific claims, assumptions, and tests it affects.

Research roadmap

Five levels, from the ground up: infrastructure and data (robot hardware, multimodal sensors, human data, web-scale data, simulation environments, digital twins) → foundation models (VLMs, VLA models, world models, video generation, physics simulation) → trustworthy learning (safe RL, constrained planning, reward and cost modeling) → evaluation and verification (benchmarks, robot evaluation, simulation benchmarks, adversarial testing, formal verification, robustness evaluation, safety certification) → physical-intelligence applications (household, industrial, autonomous driving, medical, humanoid robots, general agents).

Cross-cutting directions: safety, continual learning, long-horizon planning, explainability, human alignment, scalable deployment.

Future research roadmap and standards alignment — Figure 6 — Research roadmap spanning infrastructure and data, foundation models, trustworthy learning, evaluation and verification, and physical-intelligence applications, with cross-cutting directions on top and alignment to existing safety and AI-governance standards on the right.

Existing robot-safety, functional-safety, intended-functionality, and AI-governance standards already cover parts of this stack, but no single framework spans learned intelligence + physical interaction + evaluation + lifecycle governance. That gap is the standardization target.

Selected open problems

Layer	Open direction
Model	Grounded safety specifications; actionable uncertainty that stays calibrated across interfaces; long-horizon safe success (cumulative risk, recoverability, delayed consequences); assurance under fine-tuning and online adaptation
System	End-to-end timing assurance from inference to physical stopping margin; fault coverage under open-world interaction; adaptive protection with bounded risk; assurance-preserving reconfiguration
Evidence	Risk-oriented scenario coverage (causal diversity, not trial count); compositional evidence; sim-to-real validity rather than visual realism; long-term and cross-embodiment evaluation infrastructure
Deployment	Runtime boundary recognition with enough lead time; proportionate intervention between full autonomy and shutdown; measurable human authority; cross-organizational responsibility across providers, integrators, deployers, and operators

Contributors

Project Leaders — Xinyu Yang, Tianxing Chen

Corresponding Authors — Wenbo Ding, Ping Luo, Qi Xiong

Core Contributors — Honghao Su, Chenze Yu, Zhangzheng Tu, Minxuan Wang, Yue Chen, Yuxiao Huo

Contributors — Lingfeng Zhang, Yan Huang, Yan Qin, Shaolong Zhu, Qiwei Liang, Hekun Tian, Shujia Liu, Guangyu Chen, Junhao Gong, Zixuan Li, Wenwei Lin, Zijian Lin, Wenxuan Zhu, Eric J Chen, Yue Yuan, Qize Yu, Jiaqi Liang, Haowen Yan, Hengfei Zhao, Weijie Wan, Zikun Xiao, Junyuan Tang, Baijun Chen, Kai-Chong Lei, Kaixuan Wang, Kailun Su, Zanxin Chen, Yao Mu, Renjing Xu, Chuqiao Lyu

Affiliations: Xspark AI · Tsinghua University · MMLab@HKU · Peking University · SJTU · HKUST (GZ)

Correspondence: sparklab@xsparkai.com

Citation

@misc{yang2026trustworthyembodiedintelligencesystems,
      title={Towards Trustworthy Embodied Intelligence: A Systems Framework and Graded Trustworthiness Levels},
      author={Xinyu Yang and Tianxing Chen and Honghao Su and Minxuan Wang and Chenze Yu and Zhangzheng Tu and Yue Chen and Yuxiao Huo and Lingfeng Zhang and Yan Huang and Yan Qin and Shaolong Zhu and Qiwei Liang and Hekun Tian and Shujia Liu and Guangyu Chen and Junhao Gong and Zixuan Li and Wenwei Lin and Zijian Lin and Wenxuan Zhu and Eric J Chen and Yue Yuan and Qize Yu and Jiaqi Liang and Haowen Yan and Hengfei Zhao and Weijie Wan and Zikun Xiao and Junyuan Tang and Baijun Chen and Kai-Chong Lei and Kaixuan Wang and Kailun Su and Zanxin Chen and Yao Mu and Renjing Xu and Chuqiao Lyu and Qi Xiong and Ping Luo and Wenbo Ding},
      year={2026},
      eprint={2607.26121},
      archivePrefix={arXiv},
      primaryClass={cs.RO},
      url={https://arxiv.org/abs/2607.26121},
}

If you are working on embodied assurance, evaluation infrastructure, or deployment governance and would like to collaborate, get in touch at sparklab@xsparkai.com.