# Robotics training, without the fog

> How inference, simulation, evaluation, training, and sim-to-real fit together.

Audience: Product, robotics, and platform teams
Updated: 2026-08-02
Page: /docs/robotics-training

## Three different loops

*Do not use inference, evaluation, and training interchangeably.*

| Loop | What changes | What it answers |
| --- | --- | --- |
| Inference | Nothing; a fixed policy produces actions or predictions | What does this brain do on these inputs? |
| Simulation + evaluation | Initial state, seed, or bounded run parameters | How well does this fixed brain perform under a defined evaluator? |
| Training | Model parameters, optimizer state, curriculum, or recipe | Can data or rollouts produce a better candidate? |

A common robotics training job repeatedly resets a simulator, observes state, asks the current policy for an action, advances the physics, records reward or supervision, and updates the model. Checkpoints make the process resumable. A separate evaluation job freezes the candidate and measures it on a controlled seed/task distribution.

## The evidence chain

1. Capture or generate immutable data and identify its source, transforms, splits, calibration, and rights.
2. Run a versioned training entrypoint and publish checkpoints plus environment and recipe identity.
3. Freeze a candidate Brain Package with its weights, normalization, runtime contracts, and tests.
4. Evaluate the candidate using hidden or isolated evaluator inputs that candidate code cannot rewrite.
5. Record authoritative metrics, trajectory, media, environment, cost, and attestation.
6. Compare or fork the result in Arena; promote toward hardware only through a separate supervised gate.

## Common builder workflows

*Map the work to HIM’s small job model.*

| Workflow | HIM jobs | Typical outputs |
| --- | --- | --- |
| Batch policy regression | Inference → evaluation | Predictions, latency, pass/fail metrics |
| RL in MJX or Brax | Checkpointed training → simulation evaluation | Orbax/PyTorch checkpoints, learning logs, fixed-seed scores |
| Isaac Lab motion tracking | Training → play/evaluation → render | Checkpoint/export, trajectory, evaluator metrics, video |
| Imitation learning | Dataset validation → training → held-out evaluation | Dataset lineage, checkpoint, task metrics |
| Reward/curriculum tuning | Training recipe forks → common evaluation | Recipe lineage and comparable results |
| Sim-to-sim portability | Same Brain Package → two simulator adapters | Adapter-specific environment evidence and metric deltas |
| Sim-to-real nomination | Verified simulation result → supervised deployment candidate | Safety checks, bundle identity, explicit operator approval |

## How HIM fits your stack

- HIM standardizes packages, jobs, evaluators, artifacts, verification, lineage, and visibility.
- You keep the model architecture, simulator tasks, reward function, native commands, datasets, checkpoints, cluster, and experiment tracker.
- A simulator adapter maps native robot signals and episode semantics into a declared contract. It does not force a universal observation or action space.
- A robot adapter maps the exact Booster, Unitree, or future robot version. Vendor behavior never becomes a product-level conditional.