Using the app

Open Midcore, click Robotics on the activity rail. You’re now looking at a section list with nineteen entries. This page walks through the ones you’ll touch most often when you build, evaluate, and operate a τ₀-WM-driven robot. The order below mirrors a typical workflow — design, ground in data, train, deploy, watch.

Designer

Where a virtual robot is born. The Designer lists every robot you’ve created, lets you spin up new ones from a template catalogue (5-finger humanoid, 6-DOF arm, quadruped, drone, subsea ROV, and so on), and exposes per-link property editing for the physical particulars.

What you do here when integrating τ₀-WM:

1. Click + New.
2. From the template picker, choose Dual-arm Franka FR3 (τ₀-WM ready). This template ships with the action-space contract baked into its metadata.
3. Give the robot a name. Click create.
4. In the detail view you’ll see new sections: τ₀-WM state (renders the live 14-channel state + 2-channel gripper vector that would ship to the policy server), 3D viewport, I/O, Structure (per-link properties + part palette), and a Physics preview.

Intake

The data on-ramp. The top card — LeRobot demo capture — is what you reach for when starting a new dataset to fine-tune on. You name the dataset, pick the robot type, set the FPS, and click create. From that point each captured frame appends to the current episode; close the episode at the end of an attempt, finalise the dataset when you’re done.

See capture discipline for the practical mistakes that cost the most.

Training

The top card is τ₀-WM fine-tune. The dataset selector reads from Intake-created datasets that have been finalised. Pick a cloud provider, accept (or override) the 16 × H100 / 26 h default, watch the live cost estimate, click submit. Below the form: a list of running and completed jobs with progress bars + last log line. When the job lands a checkpoint URI, the Register in Vault button binds it to your active project.

Brain

The autonomy decision pipeline. At the very top sits the Policy gateway panel, which lists every configured policy provider (τ₀-WM, ACVS, future pi-zero / OpenVLA) with name, version, endpoint, RCS and LAR capability badges, license, and reachability pill.

Each provider row has a Ping infer button that round-trips a synthetic observation. The result is your “the wire is wired” check — latency, RCS, chunk count, all in one line. Below the policy panel: the existing pipeline-stage tiles and recent decisions list.

Command

Pick a robot from the left list. The right panel splits into two halves: the legacy fleet command buttons (goto, return-to- home, abort mission, e-stop) and the new Manipulate card.

The Manipulate card is the RCS-gated commit surface:

1. Type a natural-language prompt (“fold the towel on the left”) into the textarea.
2. Click Propose action. The policy server runs one inference round-trip. The card renders the returned RCS value and a state badge:

3. State	Meaning	Execute button
   ready	RCS ≥ γ (default 0.6).	Green Execute.
   gated	γ > RCS ≥ hard floor (default 0.2).	Amber Force-confirm; explicit operator override required.
   blocked	RCS < hard floor.	No execute button. Proposal is still recorded on the audit ledger.

4. Click execute (or force-confirm, depending on the state). The chunk is committed to the robot’s controller, and a commit-receipt record is appended to the audit log alongside the original proposal.

Telemetry

Fleet-level health metrics plus three new tiles that matter the moment you’re running a 5.5 B-parameter policy: Policy p95 (rolling 95-percentile inference latency), GPU (utilisation percentage), and VRAM (used in GB). Any tile reading — means the policy server isn’t reachable; that’s your first diagnostic.

Safety

Three layers, top to bottom:

1. System status banner — nominal / degraded / critical based on active faults.
2. Emergency stop — two-stage e-stop button (click to arm, click within 4 seconds to commit). Wraps the actual e-stop call in an operations envelope so it surfaces on the Pulse log.
3. Reward-trajectory guardrail — uses ACVS to forecast the dense reward of a proposed action chunk. If the minimum predicted reward sits below a configurable safety threshold, the chunk is blocked before commit. This is a learned safety predicate; pair it with hard limits, not in place of them.

Simulation

The top of the screen now hosts ACVS imagined rollouts. Supply a prompt + state + gripper state + N candidate action chunks; the card asks ACVS to imagine each future and renders the per-candidate reward bars sorted by peak reward. The starred row is the j* selection, the same one LAR would pick during Command-time rectification.

Twin

The digital twin’s read-only view of every robot’s mirror state — last sync timestamp, drift between physical and twin, snapshot id, divergence summary. The new ACVS prediction card here predicts the next-horizon trajectory; the divergence between predicted and observed becomes a leading indicator of physical anomaly.

Integrations — Inference editor

Under Integrations → Inference, the top of the editor now lists policy providers separately from the legacy inference-gateway models. For each provider you see name, version, RCS / LAR capability, license badge, endpoint, and pre-release flag.

This is where an administrator confirms what the robotics section can call: τ₀-WM if the policy server is reachable; ACVS once weights land; future pi-zero / OpenVLA the moment their adapters register.

Maestro slash commands

From anywhere in the app, the Cmd+K spotlight (or typing / in the Maestro chat) surfaces four robotics actions:

End-to-end: a single coherent workflow

Tying it all together, here’s what a customer’s complete workflow looks like:

1. Designer → create a dual-arm Franka FR3 (τ₀-WM ready). Confirm the τ₀-WM state panel renders sensible numbers.
2. Brain → Ping infer → confirm the policy server is reachable and responding.
3. Intake → capture ~200 episodes of your target task.
4. Training → submit a fine-tune. Wait the budgeted 26 hours.
5. Register the resulting checkpoint in the Vault as the active checkpoint.
6. Command → Manipulate → queue a small evaluation batch. Watch the RCS scores.
7. Safety reward guardrails stay armed; Telemetry tells you when GPU pressure is high; Pulse shows every executed chunk.
8. The audit log holds the whole chain — dataset → fine-tune → checkpoint → every proposal → every commit.