Where the model lives
The model lives on whatever machine you trust to hold the data. WorldFlux watches the run from the side, picks up the manifest, and uploads it. That is the whole boundary.| Source | What you do | What WorldFlux sees |
|---|---|---|
| Local script | worldflux init, drop your code into run.py, worldflux run. | Manifest, metrics, logs, committed artifacts. |
| Experimental runtime wrapper | Use only when the installed wrapper and adapter metadata say the path is supported for your run. | Whatever the wrapper returns in RuntimeResult; unsupported wrappers should be treated as local experiments, not hosted WorldFlux compute. |
| External model | worldflux import lerobot:<model_id> to pull it into the catalog. | The imported adapter shows up in worldflux curated list. |
| External dataset | worldflux import lerobot-dataset:<id> to download. | The dataset id is referenced from the recipe. |
Data boundary
Three rules:- The CLI uploads manifest fields, metric numbers, log lines, and any artifact paths the recipe marks
commit. Nothing else. - Secrets stay outside the manifest. The CLI keyring (or
~/.worldflux/credentials.tomlwith--allow-plaintext) holds the API key. The audit payload never carries it. - API keys travel as
Authorization: Bearer wfx_…headers, scoped to one workspace, expirable.
Pre-flight
Before the first sync:error: block runs.
Pass --json from CI
What changes when you sync
Nothing on disk. The CLI POSTs to FastAPI and exits. The next time the dashboard loads, the run shows up in the workspace’s runs table. Failed uploads leave the local manifest untouched andworldflux sync re-tries from the same client_run_id.