[Proposal] Adopt Isaac Lab-Arena task evaluation and composition patterns alongside Task Program

[yuecideng]

Proposal

Record an architectural comparison between EmbodiChain Task Program and Isaac Lab-Arena, and track the Arena patterns that could improve EmbodiChain's task authoring, evaluation, and experiment organization.

Preserve Task Program as the declarative orchestration and execution layer for expert demonstrations. Build on the existing environment, evaluation, randomization, and recording facilities to make task objectives and benchmark experiments reusable across expert programs, learned policies, and replay.

This is a design and prioritization issue. Component names below are conceptual, not proposed final APIs. Implementation should be split into focused follow-up issues.

Motivation

EmbodiChain already provides typed Semantic Calls, Atomic Skills, robot/scene contracts, effect verification, segment acceptance, RL evaluation, and reusable deployment components. Arena provides useful patterns for organizing reusable task goals, physical progress, environment variations, and multi-run policy evaluations.

The main opportunities are to:

• Compare different action sources against the same physical task objective without requiring the same solution steps.
• Distinguish execution completion, physical task outcome, and demonstration/data acceptance in reports.
• Reuse physical predicates and measurements while preserving their consumers' different lifecycle and authority.
• Organize reproducible evaluations across tasks, embodiments, backends, policies, and controlled variations.
• Improve task discovery and provide a path from generated scenes to validated runnable deployments.

Related discussions:

• [Proposal] Organize task environment as an example gallery #106: task example gallery and discoverability.
• [Proposal] Add declarative expert programs for atomic-action demonstrations #471: declarative expert programs above the atomic-action system.
• [Proposal] Decouple RL task-state evaluation from expert-demo segment and task acceptance #567: separation of step-wise task state, segment acceptance, and program acceptance. This proposal must preserve those boundaries; it does not reopen or replace that work.

Additional context

1. Architectural comparison

The systems operate at different abstraction levels. Arena's Task primarily describes goals and contributes environment/reset/evaluation configuration. Task Program orchestrates executable Semantic Calls and lowers them into Atomic Skills.

Dimension	EmbodiChain Task Program	Isaac Lab-Arena	Implication
Primary concern	How to orchestrate and execute a task	What constitutes the task and how to evaluate it	Use the approaches together
Action generation	Semantic Calls, grounding, Atomic Skills, execution runtime	Actions generally come from a separate policy, teleoperation, or replay source	Retain the existing expert execution path
Sequential composition	Execute calls in a declared order	Require subtask success in a declared order	Execution order and goal order need distinct semantics
Parallelism	Resource claims, command timing, state-write conflicts, safety validation, fail-fast barriers	Order-independent task composition and vectorized evaluation	Unordered goals are not concurrent command execution
Completion	Runtime results, effect assurance, post-policies, and segment validators	Physical success/failure predicates and composite completion	Preserve separate authorities and report them explicitly
Generated input	Bounded AST, strict decoding, trusted integration, restricted MLLM frontend	Validated environment graph specifications and environment generation	Reuse validated declarative boundaries for different outputs
Reuse	Programs, embodiments, bindings, and execution policies	Scenes, embodiments, task types, environment definitions, and experiments	Extend existing composition rather than add another runtime

Example: placing a banana and then a cube in a bowl.

• A Task Program can execute Pick(banana) -> Place(banana) -> Pick(cube) -> Place(cube) and manage execution and acceptance.
• An Arena-style sequential objective observes the required physical outcomes in order, while allowing the policy to choose how to achieve them.
• A benchmark should not require a learned policy to reproduce the expert program's internal call sequence unless that sequence is explicitly part of the task definition.

Task Program strengths to retain

• Explicit skill/resource/transport contracts, grounding, execution, and recovery.
• Provider-independent compilation and an immutable compiled representation.
• Bounded declarative input and a trusted-host boundary for model-generated programs.
• Existing Gym-owned stepping, reset, recording, and lazy DemoSegment lifecycle.
• Explicit verified versus projected effect assurance.

Costs and gaps to address

• The scene/profile/integration/policy/program model has an authoring and debugging cost.
• A program naturally describes a solution; it is not automatically a solver-independent benchmark definition.
• Existing effect monitoring and segment acceptance should be complemented by reusable physical goal/progress evaluation for other action sources.
• Program position or emitted-action progress does not measure physical task progress.
• Cross-task, cross-policy experiment organization can build on existing evaluation facilities.

Arena semantics to examine rather than copy blindly

• Composite tasks can remember that a child succeeded earlier; final-state persistence requires an explicit requirement. A placed object falling out later must be handled according to the benchmark contract.
• Python and graph-YAML environment definitions do not have identical capabilities.
• Placement generation may permit best-loss fallback layouts that fail required checks. Such layouts must not silently enter evaluations that require valid initial states.
• Arena is coupled to Isaac Lab and its simulation/configuration APIs. Reuse architecture and backend-independent algorithms where appropriate, with EmbodiChain-specific adapters.

2. Candidate modules and components

Candidate	Existing EmbodiChain foundation	Proposed increment	Priority
Solver-independent task objectives	compute_task_state(), task-specific metrics, measured evidence	Reusable declarations of goal entities, success/failure conditions, and metrics, optionally attached to a deployment	Highest
Physical predicates and progress tracking	Effect evidence, execution metadata, segment validation	Shared measurements plus per-environment physical milestones, temporal conditions, and progress events	High
Experiment / Run organization	evaluate_episodes(), run manifests, external Policy Profiles, reports	Named runs selecting deployments, action sources, seeds, variation settings, and reporting configuration	High
Variations and sensitivity analysis	EventManager, randomization functors, scoped seeding	Discoverable variation definitions, actual sampled-value logging, scope metadata, and outcome analysis by condition	High
Task catalog and gallery	list-task, registered tasks, packaged deployment discovery	Task descriptions, deployment-specific capabilities, previews, runnable references, and validation provenance; coordinate with #106	High
Relational placement and validation	Scene Engine, workspace sampling, affordance sampling, motion/collision facilities	Multi-object relations, candidate generation, staged validation, and optional valid-layout pools	Medium-high
Affordance contracts	Existing grasp/support/container and articulation semantics	Extend object capabilities and reuse their measurements across action grounding and objective evaluation	Medium
Environment graph authoring	Scene graphs, physical components, semantic integration, Task Program input validation	A validated path from generated scene and task intent to a concrete runnable deployment	Medium
Policy/action-source adapters	RL inference, external Policy Profiles, Task Program bridge	Explicit observation/action compatibility and experiment adapters for heterogeneous action sources	Medium

Task objectives and predicates

Introduce a reusable objective/evaluation contract only where it improves on existing task-specific implementations. Initially adapt through existing environment hooks instead of requiring a large new Task class hierarchy.

Shared physical measurements may support multiple consumers, but keep these contracts distinct:

1. Step-wise environment state and benchmark evaluation.
2. Skill effect monitoring and execution recovery.
3. One-shot segment acceptance after actions and post-policies finish.
4. Authoritative program/demo completion.
5. Dataset persistence decisions.

In particular, preserve #567: do not call segment validators on every step, do not make compute_task_state() mutate program state, and do not require expert-only programs to implement RL evaluation or pass a second mandatory completion gate. Independent physical benchmark evaluation should be opt-in and reported separately.

Predicate semantics should distinguish current truth, historical achievement, ordered achievement, sustained truth, and required final state. State and resets must be isolated per environment. projected symbolic effects must not be reported as measured physical success.

Experiments, variations, and provenance

A Run should reference an existing concrete deployment and an action source; an Experiment should group Runs. Reuse current rollout and report machinery.

Record the resolved configuration, code/asset provenance where available, seeds, actual variation samples, physical task outcomes, execution outcomes, and data-acceptance outcomes. Distinguish world-shared changes from per-environment and per-episode changes. A backend choice should select a supported deployment rather than bypass file-owned physics constraints.

Retain Task Program's bridge and segment lifecycle. Experiment integration does not require reducing it to a stateless get_action(obs) interface.

Placement and generated environments

Separate candidate generation from acceptance. Apply inexpensive geometry/relation checks before more expensive IK/collision checks. Workspace reachability alone does not establish collision-free motion or task feasibility. Rejected candidates and best-effort fallbacks need explicit status and provenance.

Keep physical scene generation, semantic binding, task objectives, and executable programs as distinct artifacts. Reuse their existing owners and validators instead of introducing an all-purpose configuration that bypasses those boundaries.

3. Suggested first vertical slice

Use the existing repeated_pick_place task to validate the architecture:

• Define an optional solver-independent physical placement objective with explicit temporal/final-state semantics.
• Evaluate Task Program execution and replay against the same objective without changing authoritative program completion or segment acceptance.
• Report execution completion, physical success, and data acceptance separately.
• Add a small set of controlled variation conditions and record their actual sampled values.
• Verify per-environment state/reset isolation and reproducibility under a documented configuration.
• Add a learned-policy adapter when an appropriate policy is available, reusing the same objective.

Follow-up work can add named multi-run experiments, broader predicate coverage, relational placement, and generated deployment validation. Cluster orchestration and a broad replacement of the current task/configuration system are outside the initial scope.

4. Reference implementation surfaces

EmbodiChain baseline reviewed: c101a8051d5b6241a01c3bf5936c7fba9ed540ff.

• embodichain/lab/task_program/{language,compiler,runtime,semantics,integrations}/
• embodichain/lab/gym/envs/task_program/bridge.py
• embodichain/lab/gym/envs/{embodied_env,demo}.py
• embodichain/lab/gym/envs/managers/event_manager.py and managers/randomization/
• embodichain/learning/rl/evaluation.py and policy_evaluation/
• embodichain/lab/sim/motion/workspace/ and atomic_actions/affordance_sampling.py
• embodichain/gen_sim/ and embodichain/cli/list_task.py

Arena references use the release/0.3.0 documentation/source; these observations are architectural, not runtime or performance qualification:

• Environment definition and Python/YAML boundaries
• Task design
• Composite and sequential task semantics
• Predicates and progress tracking
• Experiments
• Variations
• Sensitivity analysis
• Placement validation

Checklist

• I have checked that there is no similar issue in the repo (required). Related issues [Proposal] Organize task environment as an example gallery #106, [Proposal] Add declarative expert programs for atomic-action demonstrations #471, and [Proposal] Decouple RL task-state evaluation from expert-demo segment and task acceptance #567 are linked above; this issue records the cross-framework comparison and incremental adoption roadmap.