Antioch and Workbench

Integration contract

Use the XR1 cookbook for the executable procedure and pinned inputs. The operator module at npa/src/npa/workflows/xr1_antioch/operator.py invokes the installed Antioch CLI from an operator-owned Antioch project. Its commands are assets, runtime, source, collect, fetch, publish, and compare. The antioch command wraps native CLI arguments; exec launches attached remote argv through the pinned SDK interpreter. Both resolve the NPA credential before launching.

The training stage is the workflow.xr1.finetune toolRef in workflows/partners/antioch/xr1-antioch-finetune.yaml. It runs on Nebius and publishes checkpoints to S3. Antioch collection, transfers, and closed-loop evaluation are operator CLI/SDK steps around that YAML. Do not describe the entire loop as one submitted workflow. The NPA CLI has no separate Antioch subcommand.

Authentication

1. Inspect the installed CLI/SDK version and run the cookbook's operator antioch --antioch-project <owned-directory> -- auth whoami --json privately. This reports identity and credential source without printing the token, but organization, API, and user details still belong outside Git and public recordings. The tested XR1 adapter requires antioch-sim==0.4.236.
2. Store a personal access token as tokens.ANTIOCH_TOKEN in ~/.npa/credentials.yaml, honoring NPA_CONFIG_DIR when configured. Use the existing atomic 0600 credential writer. A secret-injected ANTIOCH_TOKEN can be saved through npa configure --save-env-credentials; this imports all supported credentials present in the environment and reports names only. Never request the token in chat or put its value in command arguments, shell history, committed files, workflow parameters, or recordings.
3. Resolve environment ANTIOCH_TOKEN before the NPA file value. With neither, retain the native CLI browser-login fallback (antioch auth login). Browser access and refresh credentials stay in Antioch's own auth store; never copy them into the personal-access-token field. When a personal access token is supplied, native login, logout, and organization switching refuse. Managed Antioch workspaces use their managed credentials first. If the identity is wrong, resolve the intended account before operating; do not silently switch organizations or remove credentials.
4. Use npa/src/npa/clients/antioch.py to supply the resolved credential only to local Antioch client subprocesses. The saved token is excluded from the generic token map, process-wide credential export, and shared worker env. Bare Antioch commands do not read the NPA store; use the operator wrapper when that stored token is required. Never add it to training YAML or S3. Verify access to the intended Antioch organization and project, an owned antioch.yaml, a compatible engine, and available simulator capacity. A token authenticates the caller; it does not provision these prerequisites.
5. Configure Nebius and S3 separately through the selected NPA project. Follow skills/atomic/health-preflight/SKILL.md before provisioning or GPU submit, and the applicable model/software access procedure. An Antioch token does not grant Nebius access. Keep both providers' credentials on the operator; only the Nebius training worker needs the configured S3 credential delivery.

Procedure and data contract

1. Use an isolated checkout and private operation directory. Confirm command help locally before creating sessions or submitting work:

   npa/.venv/bin/python -m npa.workflows.xr1_antioch.operator --help
   npa/.venv/bin/python -m npa.cli.main workbench workflow validate-spec \
     workflows/partners/antioch/xr1-antioch-finetune.yaml
   

2. Seal disjoint training, validation, and test seeds before collecting data. Stage the pinned XR1 base model, processor, source, and split manifest in a new run-scoped Nebius S3 prefix. Preserve checksums and revision identities.

3. Initialize an owned Antioch project and use the cookbook's Isaac Sim 6.0.1 engine and SDK 0.4.236. Preserve the project's generated ID. The measured simulator uses one RTX PRO 6000; the verified trainer uses eight Nebius RTX PRO 6000 GPUs. Prefer that tested configuration. B200 requires a separately built and verified runtime; it is not a drop-in target for the SM120 wheel.

4. Use source and fetch to bring approved inputs into Antioch, then collect physical demonstrations. Preserve synchronized RGB from all three cameras, state, issued actions, outcomes, split membership, and timestamps. Keep failed demonstrations as evidence and exclude them from behavior cloning.

5. Use publish to return demonstrations to Nebius S3. The transport passes signed GET/PUT requests over stdin to the Antioch worker and verifies hashes after complete downloads/readbacks. It does not copy static S3 keys into the simulator. Source archives contain allowlisted package Python files and the split manifest, excluding project authentication files.

6. Validate, plan, and submit the training YAML using the cookbook and skills/atomic/submit-workflow/SKILL.md. Training reads the S3 dataset, computes normalization from successful training episodes, fine-tunes the native XR1 action policy, and publishes model/optimizer state and metrics. Select the checkpoint using validation loss; keep test outcomes sealed.

7. Fetch the selected checkpoint and matching normalization back into Antioch. Evaluate base and trained policies on identical held-out scenarios, with physical success checks and all failures retained. Use publish and compare to return native videos, measured outcomes, and paired statistics to Nebius S3. Do not claim real-robot transfer from this simulated result.

Long runs and evidence

The ordinary Antioch CLI execution deadline interrupted the measured evaluation. For a full cohort, use the cookbook's operator exec command with the pinned interpreter. It supplies NPA credentials to the attached SDK adapter at npa/src/npa/workflows/xr1_antioch/attached_exec.py. It removes the overall execution deadline while retaining cancellation and the remote exit code. Do not silently upgrade the SDK: the adapter uses versioned CLI internals. Resume only missing trials after verifying retained outputs and unchanged inputs; preserve interrupted attempts separately.

Verify native video decoding, frame counts, simulation clocks, object sizes, and complete SHA-256 readbacks. A manifest, terminal screenshot, or successful upload alone does not establish robot learning. Report paired success counts, the selected checkpoint, failures, and actual GPU types/counts. The measured reference improved from 0/32 to 8/32; it is a narrow, low-success simulated task. See committed evidence.

Record actual transfers, execution, and native camera playback when requested. Keep raw video paths outside Git. Distinguish live connection footage from playback of durable results if the original session is no longer available. Signed URLs are bearer credentials too: exclude them, raw auth output, and private infrastructure identifiers from recordings, commits, and PR text. Use skills/atomic/protect-nebius-infra-details/SKILL.md before publishing.

Publish and fully verify artifacts before releasing an Antioch session. Follow skills/atomic/teardown-and-cost/SKILL.md to cancel jobs before destroying owned Nebius compute. Retain the requested durable S3 evidence.

Verify changes

npa/.venv/bin/python -m pytest \
  npa/tests/clients/test_antioch.py \
  npa/tests/guardrails/test_skills_index.py \
  npa/tests/guardrails/test_develop_skills.py -q

The client tests verify credential precedence, private persistence, isolation from worker exports, CLI/SDK invocation, and collection/transfer delivery. The registry verifies the operator/transport files and parses the training workflow. For implementation changes, also run the XR1 tests under npa/tests/workflows/ and the applicable live validation; do not substitute this documentation smoke for execution evidence.