Interactive tasks

Interactive tasks let the agent drive the simulator live, one transition at a time, over the gym-over-gRPC protocol. The agent explores freely during development, then hands control to the evaluator for a scoring session on hidden seeds. This is the counterpart to batch tasks, where the agent instead writes a submission and lets the evaluator run its native pipeline at full speed.

Every interactive task runs inside an OFFLINE (no-network) sandbox against an independent evaluator container. The container hosts one simulator and one domain metric behind an AleEnv gRPC service. The authoritative metric is ALWAYS computed by that evaluator — never self-reported by the agent.

The exploration loop

During development the agent iterates on its policy by driving episodes itself:

1. CreateEnv then GetSpec to obtain observation/action shapes and metadata.
2. Reset to start an episode (the agent may pass its own seed here, for reproducible debugging).
3. Step repeatedly, feeding actions and reading observations, rewards, and termination flags.
4. Repeat, adjusting the policy, checkpoints, or code between episodes.

This loop is fully under the agent's control and runs locally on the runner. Nothing here is scored — it exists so the agent can implement the paper's method (reproduction genre) or optimize the target metric (open genre) before requesting an official evaluation.

Scoring sessions

When the agent is ready, it calls StartEvalSession. The harness's env is the only one marked official=true, and the official evaluation runs on hidden seeds drawn by the evaluator:

• Seeds are NEVER sent to the agent.
• Any client-supplied Reset seed is ignored for the duration of an eval session.
• The evaluator runs its configured scoring episodes, computes the domain metric, and holds the result.

The harness — not the agent — reads the outcome via GetEvalResult over its OWN gRPC connection, using a docker-exec loopback client. The agent has no evaluator exec access and cannot observe or influence the hidden seeds. Each hidden seed is persisted only as a commitment, SHA256(seed || run_id || evaluator-secret), so the seed never appears in the trajectory or the submission bundle in raw form.

The raw metric returned here is then fed to scoring: normalized against the release paper target, capped, adjusted by any zero-target safety penalties, and — for reproduction-genre tasks — gated by the fail-closed faithfulness judge.

No seed fishing

A Reset issued in the middle of an active eval session aborts the current scoring episode rather than restarting it on a fresh, observable seed. This closes the "seed fishing" loophole: an agent cannot probe a scoring episode, decide the draw looks unfavorable, and reset until it gets an easy seed. The evaluator drives episode boundaries during a session; a mid-session Reset is a discard, not a retry.

Interactive tasks in v0.5

Six of the eleven v0.5 tasks run in interactive mode. Paper targets, versions, and step/time budgets are not published in v0.5 — they are synced from the release manifest at run time.

The remaining v0.5 tasks run in batch mode (ego_swarm, barn_dwa, anymal_flat, go1_joystick), while edmp reads its mode from the task config.

Where the website fits

All interactive episodes — exploration and scoring — happen locally on the runner; the site is NOT a benchmark runner. The website only receives the encrypted submission bundle afterward and re-derives the score from the evaluator's recorded EvalResult, without ever holding the hidden seeds. See verification levels for what that recomputation does and does not prove.