Robotics training, without the fog
How inference, simulation, evaluation, training, and sim-to-real fit together.
Three different loops
| 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
- Capture or generate immutable data and identify its source, transforms, splits, calibration, and rights.
- Run a versioned training entrypoint and publish checkpoints plus environment and recipe identity.
- Freeze a candidate Brain Package with its weights, normalization, runtime contracts, and tests.
- Evaluate the candidate using hidden or isolated evaluator inputs that candidate code cannot rewrite.
- Record authoritative metrics, trajectory, media, environment, cost, and attestation.
- Compare or fork the result in Arena; promote toward hardware only through a separate supervised gate.
Common builder workflows
| 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.