Source-linked AI summary

Bounded-Fidelity Sim-as-Demo-Stage: Mocap Handoff for Governance Benchmarks

Xue Qin, Simin Luan, Cong Yang, Zhijun Li

arXiv:2610.00008v1cs.ROcs.AI

TL;DR

For governance benchmarks, contact-force noise at robot handoffs can make audit chains diverge even when the governance behavior is the subject of evaluation. The paper brackets carry phases with mocap-based pose tracking, and reports byte-identical audit chains for every mocap replay while the contact-force baseline diverges on nearly every replay.

  • Problem

    Contact-force integration noise can introduce audit-chain divergence into governance demos, confusing evaluation of the governance behavior under test.

    Source: §1 · p. 2
  • Method

    The bounded-fidelity pattern uses a structured-intent-bracketed mocap handoff envelope to suppress contact physics during carry.

    Source: §1 · p. 2, §3.4.1 · p. 5
  • Results

    1000/1000 mocap replays produced byte-identical audit chains, while the contact-force variant had a 99.3% divergence rate.

    Source: §4.3 · p. 6
  • Takeaways & Limitations

    The pattern is intended for governance benchmarks but is harmful for sim-to-real validation, policy training, and contact-rich tasks.

    Source: §5.1 · p. 9, §6 · p. 10

    Audit-chain stability is necessary but not sufficient for governance benchmark reproducibility, and does not prove the bridge is correct.

    Source: §5.2 · p. 10

Abstract

from arXiv · show

Sim-to-real research pursues physics fidelity as a primary objective: simulators are judged by how closely they reproduce real-world contact dynamics. For governance benchmarking of LLM-driven robots, where the simulator demonstrates that an admission/policy/contract/audit pipeline behaves correctly, contact fidelity at object handoffs (grasp, carry, place) becomes a liability: contact-force integration noise injects audit-chain divergence that is structurally unrelated to the governance property under test. We propose bounded-fidelity sim-as-demo-stage, a design pattern that suppresses contact physics within explicitly bracketed handoff envelopes while preserving full dynamics elsewhere. The construction uses MuJoCo's mocap-body primitive driven by a 220-line Python adapter that the governance bridge invokes via structured intents. We formalise audit-chain stability as byte-equality of the hashed event log across replays and identify two structural envelope properties that imply it. Across N=1000 replays per posture, the mocap variant produces one distinct audit-chain hash (1000/1000 byte-identical; Wilson 95% CI [0.997, 1.000]); the contact-force baseline produces 584 distinct hashes (993/1000 diverged; CI [0.987, 0.998]). A timestep sweep (1, 2, 5, 10 ms) shows the divergence is structural, not a tuning artefact: it stays at 0.985 at every timestep. Envelope-edge timing jitter (+/-10 simulation steps, 1,400 replays) produces 0 divergence, and audit chains remain byte-equal across K in {1, 2, 3} sequentially handed-off objects (1,500 replays) with sub-linear per-pick-and-place overhead. The pattern gives benchmark designers audit-chain reproducibility at near-zero engineering cost; we also map where it is harmful (sim-to-real validation, policy training, contact-rich tasks) so it is not mis-deployed.

1 INTRODUCTION

The introduction argues that contact-force noise can alter a governance demo’s audit chain even when the governance pipeline is unchanged. It proposes bounded-fidelity simulation to make handoffs deterministic for governance benchmarks.

1 INTRODUCTION

  • Contact-force integration can make identical demos produce different grasp outcomes and audit events, obscuring whether a failure belongs to the governance bridge or simulator.The motivating example contrasts a clean run with a second run in which a spurious 87 N spike slips the cup and triggers a recovery event.Source: §1 · pp. 1–2
  • Bounded-fidelity sim-as-demo-stage suppresses contact physics at handoffs to prioritize deterministic governance behavior over physics realism.The proposed construction uses MuJoCo mocap bodies and a Python pose-tracking adapter, with structured intents bracketing handoffs.Source: §1 · p. 2
  • The paper contributes a handoff-envelope design and formal properties, evaluates audit-chain stability across replays and robustness tests, and maps appropriate and harmful use cases.The introduction identifies governance benchmarks, demos, regression tests, and tutorials as suitable settings, while flagging sim-to-real validation, policy training, and contact-rich tasks as harmful uses.Source: §1 · p. 2

2 RELATED WORK

The related work distinguishes simulation for transferable policy learning from simulation used to demonstrate governance behavior. It positions the contribution as applying a bounded kinematic/dynamic split at governance-relevant handoffs.

2 RELATED WORK

  • Sim-to-real research prioritizes faithful contact dynamics to reduce the reality gap and support behavioral-policy transfer to hardware.The passage names MuJoCo, PyBullet, and IsaacSim as simulators investing in contact dynamics, friction models, and rigid-body integrators.Source: §2 · p. 3
  • LLM-driven robotics makes structured intents explicit, and the handoff envelope brackets that intent layer.Source: §2 · p. 3
  • Governance benchmarks assess admission, contract enforcement, audit chains, and recovery behavior, whereas common embodied environments are tuned for policy training.Here the simulator serves as a stage for demonstrating governance behavior, not as a training environment.Source: §2 · p. 3
  • Seed determinism can fail at contact resolution, motivating the construction’s focus on grasp, handoff, and place.Source: §2 · p. 3
  • The contribution is not kinematic simulation itself, but bounded fidelity at governance-relevant handoffs within an otherwise full-dynamics scene.The passage contrasts this runtime-fidelity choice with existing kinematic/dynamic simulation approaches.Source: §2 · p. 3

3 THE BOUNDED-FIDELITY PATTERN

The pattern uses mocap pose tracking during a structured-intent-bracketed carry envelope while leaving ordinary scene dynamics intact outside it. Its formal account defines audit-chain stability and states structural conditions for preserving it.

3.1 Mocap-Body Handoff

  • A MuJoCo mocap body is externally pose-driven rather than controlled by the contact-force integrator, and the adapter writes its pose during handoff.The figure depicts the cup tracked to the gripper during carry, with normal dynamic behavior during approach and place.Source: §3.1 · pp. 3–4

3.2 The Handoff Envelope

  • The handoff envelope is the carry phase, opened by a grasp intent and closed by a place intent; the cup follows the gripper inside it and remains dynamic outside.The adapter runs in the bridge’s Python runtime and requires no MuJoCo plugin.Source: §3.2 · p. 4

3.3 What the Pattern Is and Is Not

  • The pattern suppresses contact physics only during governance-irrelevant handoffs, preserving full dynamics elsewhere rather than making the whole simulator kinematic.It is not free-flight carry motion: the cup remains pose-tracked to the gripper.Source: §3.3 · p. 4

3.4 Formal Account

  • The formal account specifies envelope state transitions, audit-chain stability, and two Hoare-style structural properties, with regression-test encoding rather than mechanised verification.Mechanised verification is explicitly out of scope.Source: §3.4 · pp. 4–5

3.4.1 State, Phases, and the Envelope

  • The demo state includes simulator state, object poses, and the audit-chain prefix; the envelope is the carry phase opened by grasp and closed by place.Source: §3.4.1 · p. 5

3.4.2 Audit-Chain Stability

  • Audit-chain stability means replay hashes match; operationally, the paper reports the fraction of replays matching the cohort’s modal hash.The chain is canonically serialized without wall-clock fields before hashing.Source: §3.4.2 · p. 5

3.4.3 Two Structural Properties

  • Within the envelope, a fixed grasp-time transform makes cup pose a deterministic function of gripper pose; audit-chain stability additionally assumes intent-indexed events and excludes wall-clock fields.The arguments are not mechanised proofs; the regression suite tests their structural dependencies across replays.Source: §3.4.3 · pp. 5–6

4 EXPERIMENTS

The experiments use a Python mocap adapter integrated with the governance bridge and define audit-chain stability by comparing canonicalized event-log hashes across replays. The implementation and metric establish the experimental setup described in this section.

4.1 Implementation

  • The ∼220-LOC MocapAdapter exposes enter, per-step update, and exit operations, invoked by the bridge after grasp gates pass and on place.The reference setup uses Python 3.11.7 and MuJoCo 3.1.4; the artifact includes the interface, hash function, phase-state contract, and replay summaries.Source: §4.1 · p. 6

4.2 Audit-Chain Stability Metric

  • Audit-chain stability is byte-equality of serialized event chains across same-script, same-seed replays, excluding wall-clock timestamps from the hash.The chain contains JSON-serializable events emitted as the governance bridge admits, gates, and dispatches intents.Source: §4.2 · p. 6

4.3 Quantitative Results

Across 1,000 replays per posture, mocap handoffs yielded identical audit chains while the contact-force variant diverged on nearly every replay; wall-clock medians were essentially equal.

4.3 Quantitative Results

  • 1000/1000 mocap replays had byte-identical audit chains, while the contact-force variant produced 584 distinct hashes and diverged in 993/1000 replays (Wilson 95% CI [0.987, 0.998]).The mocap variant’s single SHA-256 hash covered every replay.Source: §4.3 · p. 6, Table L · p. 6
  • Wall-clock medians were essentially the same at ∼3.41 s per replay under both postures.The passage attributes the divergence to the contact integrator rather than a cost of the bounded-fidelity construction.Source: §4.3 · p. 7
  • The mocap variant had no audit-chain exceptions, whereas the contact baseline diverged on nearly every replay.The observed contact-baseline divergence exceeded the authors’ earlier estimate of ∼30–40%, based on five manual measurements.Source: §4.3 · p. 7

4.4 Fidelity-Stability Trade-Off Across Timesteps

Across tested timesteps, contact-force divergence remained high while mocap stayed at one audit-chain hash. Boundary jitter across grasp and release edges also left the audit chain unchanged in all tested replays.

4.4 Fidelity-Stability Trade-Off Across Timesteps

  • 0.985 contact-variant divergence at every tested timestep, while mocap stayed at one hash; shrinking the timestep 10× did not make contact-force byte-stable.The tested timesteps were 0.001, 0.002, 0.005, and 0.010 s; the authors note a byte-stable regime might exist outside this range.Source: §4.4 · p. 7

4.5 Envelope-Precision Ablation

  • Across all seven boundary-jitter settings, all 1,400 replays produced a single audit-chain hash and 0.000 divergence (Wilson 95% CI [0.000, 0.018]).The result held for jitter on grasp and release edges; Table 2 summarizes the envelope-precision ablation.Source: Table L · p. 7, §4.5 · p. 7
  • The tested jitter robustness relies on deterministic tray placement and a nearly stationary end effector during release; concurrent arm retreat would test envelope precision more aggressively.The authors identify that moving-end-effector release scenario as a future ablation.Source: §4.5 · p. 7

4.6 Multi-Object Handoff

Across K = 1, 2, and 3 sequentially handed-off identical cups, every scale produced byte-identical audit chains across replays. Per-pick-and-place overhead remained below the adopted compositional-cost threshold, while heterogeneous-object generalisation remains untested.

4.6 Multi-Object Handoff

  • 1.000 byte-equal rate at every scale, with one distinct audit-chain hash across 500 replays per scale.The hashes differ across scales because object identity appears in grasp and place payloads; within each scale, all replays match.Source: §4.6 · p. 8, Table L · p. 8
  • At K = 3, the per-pick-and-place wall ratio was 1.0001× of K = 1, below the 1.2× compositional-cost threshold.Trial wall-clock time scaled linearly with K, as expected from sequential dispatch.Source: §4.6 · p. 8
  • The tested composition used three identical cups; heterogeneous shapes remain a follow-up rather than a blocker.The reported scale sweep covers K ∈ {1, 2, 3}.Source: §4.6 · p. 8

4.7 Cross-Machine Reproducibility

The canonical replays reproduced byte-for-byte across all 10 task cells on Ubuntu, spanning both the cross-OS comparison and a minor Python-version skew.

4.7 Cross-Machine Reproducibility

  • All 10 cells reproduced byte-for-byte across the macOS-to-Ubuntu comparison and minor Python-version skew.The reproduction covered the same 1,400 envelope-precision trials and 1,500 multi-object trials as the macOS baseline.Source: §4.7 · p. 9, Table L · p. 9

4.8 Scope: What We Are and Are Not Measuring

The evaluation measures audit-chain stability under handoff, not task success, hardware transfer, or broader scene and object generalisation.

4.8 Scope: What We Are and Are Not Measuring

  • The evaluation measures audit-chain stability under handoff, using a fixed demo script rather than held-out task-success testing.Task success rate on a held-out test set is not measured.Source: §4.8 · p. 9
  • Physical-hardware transfer is outside the evaluation, which is sim-only by design.Source: §4.8 · p. 9
  • The demo uses one cup, so object-shape generalisation and pile-up scenes with many dynamic objects are not measured.Source: §4.8 · p. 9

5 DISCUSSION

The applicability discussion separates governance-oriented uses, where audit-chain stability is the signal, from tasks that require contact behavior. It also states an adapter assumption and future work that would extend or formalize the current account.

5.1 Applicability Matrix

  • Governance benchmarks, investor demos, bridge regression tests, and tutorials are in scope; sim-to-real validation, policy training, and slip/grasp benchmarks are out of scope.Multi-skill demos are conditional: apply the pattern only to governance-irrelevant segments.Source: §5.1 · p. 9

5.2 When to Use, When Not to Use

  • The pattern is recommended for governance benchmarks, investor demos, bridge regression tests, and tutorials whose pedagogy centers on the governance pipeline.For these uses, audit-chain correctness or readability is the deliverable rather than manipulation-skill performance.Source: §5.2 · p. 9
  • Avoid the pattern for sim-to-real validation, manipulation-policy training, contact-rich tasks, and benchmarks measuring grasp robustness or slip resistance.Mocap handoff cannot establish whether a real gripper maintains its hold, and the policy receives no carry-phase contact-force signal.Source: §5.2 · p. 10
  • Adoption assumes a bridge-side adapter can identify handoff status from structured intents; direct simulator invocation without that layer cannot trivially use the pattern.Source: §5.2 · p. 10
  • Byte-stable audit chains support reproducible governance benchmarks but do not prove bridge correctness; a bridge bug may remain reliably wrong.Source: §5.2 · p. 10
  • Future work proposes testing heterogeneous objects, multi-robot handoffs, mechanized verification, and release scenarios with concurrent arm retreat and gripper opening.The current release-settle sweep holds the end effector approximately stationary.Source: §5.2 · p. 10

6 CONCLUSION

The conclusion argues that governance benchmarks should prioritize readable, reproducible audit chains over contact fidelity. It reports byte-identical mocap replay chains and identifies the pattern’s scope; the supporting data are openly available.

6 CONCLUSION

  • 1000/1000 replays yielded byte-identical audit chains with mocap-bracketed handoff, while the contact-force baseline diverged on 993/1000 replays of the same script under the same seed.Source: §6 · p. 10

CONFLICT OF INTEREST

DATA AVAILABILITY STATEMENT

  • The MocapAdapter implementation, canonical audit-chain hash function, sign-check scripts, and per-task aggregates are openly available under Apache License 2.0.Source: DATA AVAILABILITY STATEMENT · p. 10
Loading 2610.00008v1…