campaigns

Campaigns visible to the caller (owner, org member or creator), newest first. No campaign is public: a campaign holds its owner's budget and runs.

C3. A campaign is the unit of the founder's training loop: a task on a robot repo the caller can see, a budget, an optional declared root checkpoint, and rounds. Its task picks the default gate battery for every round (stand → the posture battery stand, walk / omni → watch while training and c_matrix for the band scan, recovery → recovery, custom → smoke). The three rules — one variable per round, resume only from a PASS checkpoint, a FAIL ends the lineage — are enforced on every round and cannot be switched off; a signed-in person may override one on one round, with a reason (createRoundWithOverride). Creating spends nothing: key:write.

key:write, with two exceptions enforced in the handler: raising budget_usd or raising per_run_limit_usd (C3b) is a person's decision (a signed-in session; a key of any scope is 403). Together they are what lets an agent run rounds without asking — an agent that could raise either would have no limit at all. A key may lower them, rename the campaign, or stop it.

C3. The spec — one declared change (a summary and the resolved-config keys it covers), a hypothesis, what is not being done, tripwires, gates with their predictions, an iteration cap — is locked here and never edited; a gate added later is shown and not counted. Then the three rules are checked, in code, before anything is spent:

• One variable. The change the recipe makes, predicted against the parent checkpoint's run (its resolved config, and its recipe), must lie inside the declared keys (a declared key covers itself and every path under it). run.* and a template's own bookkeeping never count. A round that stacks a sibling's change (same parent checkpoint) on its own is more than one variable. When the run's resolved config arrives, the same diff is recomputed on what it actually trained on; an undeclared key found then makes the round confounded.

• Resume only from PASS. parent must be the campaign's declared root, or a checkpoint of one of its rounds whose verdict at that step is pass.

• A FAIL ends the lineage. No checkpoint of a round whose verdict is fail or confounded, or whose lineage was stopped, may be a parent.

A violation is 422 with one errors[] entry per rule (type is rule.one_variable, rule.resume_from_pass or rule.fail_ends_lineage, msg names the keys or the verdict) and nothing is recorded. Only a signed-in person may override a rule, with a reason, through createRoundWithOverride; no key of any scope can.

Budget: the round's run is priced with estimateRun; when its maximum would take the campaign past budget_usd (spent from the ledger, plus what in-flight rounds may still spend) the answer is 409 naming the numbers — the request is well-formed, the campaign has no money left for it. A priced run's own budget_usd is capped at what remains, so the hub stops it there. Then the run is created through createRun's own path (so executor: modal, C1's parent_checkpoint_step and C2's gate behave exactly as there), with the campaign's task-aware gate when the recipe names none. Spends compute: key:train.

Dry run (K3). ?dry_run=true runs every check above on the same body and records nothing: 200 with a RoundPreview — the three rules as verdicts (the 422's own entries, never a second implementation), the variables against the parent, the run's price with the campaign's remaining budget as its cap, every published checkpoint of the parent run with whether it may be a parent and the rule's sentence when not, whether the template reads each hyperparameter, and — when the parent run published no checkpoint at all (every imported run today) — why it cannot be fine-tuned. A malformed body, an unknown parent and a campaign that cannot afford the round answer as createRound would. A web fine-tune is a round, so this is its preview before the spend.

C3. createRound, plus override: {rules, reason}. Session only: no API key of any scope may override a rule, so an agent can propose a round and never waive the rules it would break. rules must name exactly the rules this round violates (a rule named but not broken is 422: an override record says what was waived, never more), and reason is recorded with who and when on the round as an override chip. A round created with a one_variable override reads confounded whatever its gates say, and nothing resumes from it without another override. Budget, scope and every other check are createRound's.

The verdict is the round's locked gates evaluated on the measured results at step (default: the chosen step — the one a decision named, else the measured checkpoint with the most counted gates passing, the earliest on a tie). Measurements come from the round's band scan at that step, else from the gate its run got while training. The hub's own 0.85–1.15 band verdict for the same rollout is returned beside it (evaluation.band) as a measurement, never as the verdict.

C3. The operation's floor is key:write and each action has its own scope, enforced in the handler (x-action-scopes): stop is key:write (ending a lineage spends nothing); iterate is key:train (it says "train the next round from step", which an agent may propose inside the campaign's budget); shortlist and done are session only — the two human gates, which no key of any scope, and therefore no agent, can pass. shortlist records the chosen checkpoints (candidates, steps of this round's run) and the A/B controls (any visible checkpoint, usually the parent), each with its verdict at that step; it starts nothing. C4: it plans the real-robot session (createTrialSession) — one trial per run, the control first and last, a run sheet each — and, when the device is known (device_id, or the only one of the owner's that accepts every contract) and no agent's shortlist follow-up will, files one consent request per trial; a person approves each on the consent page. iterate refuses a step whose verdict is not pass (the resume rule, stated before the next round is written). done closes the campaign. C3b: shortlist is refused (422, rule.separates_from_control) when the round's control — the checkpoint it started from, measured in its own band scan — also passes every locked gate, unless the person sends override naming that rule with a reason. Every decision is recorded with who, when, how and the verdict it was taken on. AG1: when an agent session's shortlist decision waits on this round, a shortlist here answers it (the note is reason), and the hub then runs the 20-seed band scan on the picks (or waits for the round's own scan when it already covers them) and files one device consent request per pick that still passes the locked gates, the note as each request's reason — never approved here (M13).

C3. A round's spec is locked when it starts; what someone learns afterwards may still be worth measuring (the founder added a stand tilt gate to a round that had started). The gate is evaluated and shown beside the locked ones with added_after_lock_at set and counted: false: it never changes the verdict.

active — rounds may start; waiting — active, and a round's review waits on a decision (Campaign.waiting says which); done — a person closed it (decideRound {action: done}); stopped — stopped by updateCampaign. Neither done nor stopped takes new rounds.

K3 — createRound?dry_run=true: what createRound would decide on this body, recording nothing.

RoundCreate plus the person's override.

One gate of a round's spec: metric op threshold over cells, with the value predicted for it written down when the spec was locked. counted and added_after_lock_at are set by the hub.

What the campaign trains, which picks its rounds' default gate battery (C3 — the C1 × C2 run judged a stand policy on a walking battery): stand → stand (upright, drift, tilt, joint asymmetry) while training and for the band scan; walk and omni → watch while training, c_matrix for the scan; recovery → recovery for both; custom → smoke for both. C3b: the stand battery is the zero-command cell plus three pushes calibrated to separate a trained stand from a network that outputs ~0 (lateral ±6 N·s and backward 4 N·s at 8 s, all scored on posture).

A checkpoint of a run — checkpoints/step_<step>/ of its output model repo.

Which rules the hub enforces on this campaign's rounds. All three are always true: they cannot be switched off for a campaign, only overridden on one round by a signed-in person with a reason.

The gate a round's run gets when its recipe names none, and the band scan it gets when it finishes — picked by the campaign's task.

Money, from the ledger: spent_usd sums the terminal rows of the campaign's round runs; reserved_usd is what rounds still training may yet spend (their estimateRun maximum); remaining_usd = budget_usd − spent − reserved, never below 0. Gate and scan rollouts are counted, not priced (the hub does not bill sim time).

What waits on a person, and since when.

C4 — the checkpoint a person promoted after a real-robot trial.

One row of a campaign's round timeline.

The founder's per-round spec, locked when the round starts (C3). locked_at / locked_by are set by the hub; nothing in it is ever edited afterwards.

The band scan the hub queues when the round's run finishes (default: the campaign's gate_defaults.scan_battery × scan_seeds, on the run's own executor).

The one-variable rule's arithmetic. basis: planned — computed at the start from the recipe against the parent checkpoint's run; resolved — recomputed on the run's own resolved config once it arrived; none — the round trains from scratch, so there is nothing to diff. changed lists every counted key that moved (bookkeeping excluded), undeclared those outside the declared change.

One published checkpoint of the parent run, judged as a parent of this round would be (resume_from_pass, fail_ends_lineage).

Whether the template reads what the recipe sets. accepted: null — the hub does not know which hyperparameters this template reads (a trainer run by path). Only ppo_isaac takes overrides (Hydra config paths); a name the template does not read would be ignored by the trainer, so it is listed in ignored.

training — the run is queued or running; scanning — the run ended and its band scan is being measured; review — measured, waiting on a decision; decided — a decision was recorded; failed — the run ended without a single checkpoint to judge.

The round's locked gates at the step: pass — every counted gate PASSes; partial — some do; fail — none does; confounded — the one-variable rule was broken (overridden at the start, or an undeclared key found in the resolved config), whatever the gates say; pending — nothing measured yet. An unmeasured gate never passes.

Where the round resumed from — a checkpoint and, when it has one, the round that produced it.

AG1 — the round's locked gates at one checkpoint (C3's evaluation, at every measured step, not only the chosen one).

C3b — the control: the checkpoint the round started from, measured in the round's own band scan (same battery, seeds and conditions) and judged by the round's locked gates, beside the candidate. A parent control is its own rollout on the parent's model repo (it carries no run_id of this round, so it never enters the band); an untrained control is the scan's step-0 row. When it passes every locked gate the candidate passes — all of them, when the candidate passes all — separates is false, the round carries the warning "the gates do not separate candidate from control", and shortlisting it needs a person's override with a reason.

C4 — a real-robot session of this round's checkpoints, as the campaign row prints it.

shortlist (session) — the checkpoints for a real-robot trial; iterate (key:train) — train the next round from step; stop (key:write) — end this lineage; done (session) — close the campaign.

What a gate reads from the measured cells at a step. Per listed cell: alive (seeds upright, a count), alive_rate (upright / seeds), tracking (measured / commanded on axis, or every commanded axis), pass (1 when the hub's band rule PASSes the cell, else 0), and the posture metrics (the median over the cell's seeds): tilt_max_deg, asym_max_deg, drift_m, and — on a push cell (C3b) — recover_s, the seconds from the push until the base stayed within 3° of upright and under 5 cm/s to the end (a seed that never settled counts the whole window left after the push). Every listed cell must satisfy the comparison. Over the checkpoint: pass_rate (PASS cells / cells, of the listed cells or all), and tracking_gap — |ratio₁ − ratio₂| of exactly two listed cells (the founder's left–right turn gap).

The ONE change this round makes: a summary a person reads, and the resolved-config keys it covers (a key covers itself and every path under it, so env.events.push_robot covers env.events.push_robot.params.velocity_range.x[0]). One conceptual change may span several keys.

The three rules the hub enforces on every round (the founder's own): one_variable — one declared change per round, diffed against what the parent checkpoint was trained on; resume_from_pass — a round resumes only from a checkpoint whose verdict is PASS, or from the campaign's declared root; fail_ends_lineage — no checkpoint of a FAIL, confounded or stopped round is ever a parent, nor (C4) a checkpoint whose real-robot trial a person stopped (setTrialVerdict {stop}). C3b adds a fourth, checked when a round is shortlisted rather than when it starts: separates_from_control — a candidate whose round's control (the checkpoint the round started from, measured in its own band scan) passes every locked gate the candidate passes cannot be shortlisted, because its gates cannot tell what it learned from what it began with; a person may override it with a reason (RoundDecisionCreate.override).

What the round expects and how to read it if it is wrong. test, when given, is evaluated and shown like a gate but never counted: a checkpoint can pass while its round's hypothesis fails, and the page keeps the two apart.

The hub's 0.85–1.15 band rule on the same rollout — a measurement shown beside the verdict.

parent — the parent checkpoint a resumed round started from (the parent run's own checkpoints/step_<step>/); untrained — for a round from scratch, the step-0 checkpoint its own run published (the weights before training, or after the trainer's first update where that is what it saves, as rsl_rl's model_0.pt is).

planned — the run has not ended, so nothing is queued yet; measuring — its rollout is queued or running; measured — the locked gates were evaluated on it; unavailable — it cannot be measured (reason says why: the template published no step-0 checkpoint, the scan was skipped, its rollout failed, …).

open — trials still to run; needs_verdict — a candidate waits on a person; decided — every candidate has a verdict (or never ran).

One trial as a session strip or a campaign row prints it.

A gate's result at a step: PASS / FAIL, unmeasured (the cells or the metric are not in the measurement — never a pass), or not_counted (a gate added after the lock; its measured value is still shown).

candidate — a checkpoint on trial, which takes a person's verdict; control — the checkpoint the robot already runs (usually the round's parent), run first and last to bracket the candidates. A control is measured, never judged.

Derived on every read from the consent request, the approval, the driver's events, the log and the verdict — never stored. unfiled (no consent request yet), awaiting_approval, denied, approved (issued, the device has not started), running, refused (the device refused it before starting), expired (the window passed unused), needs_verdict (a candidate that ran and has no verdict), measured (a control that ran), decided, withdrawn (not filed: its checkpoint failed the scan it was waiting on).

promote — this checkpoint becomes the campaign's policy on the robot; iterate — back to sim, the next round drafted from the notes; stop — this checkpoint's lineage ends, like a FAIL.