Skip to main content

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. Runs that reach Cloud use the same manifest shape. The dashboard reads the manifest and evidence package; production support for remote execution is determined by the adapter’s support metadata, not by the presence of an installed wrapper.

Data boundary

Three rules:
  1. The CLI uploads manifest fields, metric numbers, log lines, and any artifact paths the recipe marks commit. Nothing else.
  2. Secrets stay outside the manifest. The CLI keyring (or ~/.worldflux/credentials.toml with --allow-plaintext) holds the API key. The audit payload never carries it.
  3. API keys travel as Authorization: Bearer wfx_… headers, scoped to one workspace, expirable.
If a recipe writes a secret into a log line, the CLI does not strip it. That is yours to handle.

Pre-flight

Before the first sync:
The doctor commands print one line per check. Lines starting with error: block runs.

Pass --json from CI

The human-readable format is not stable across versions. The JSON envelope is.

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 and worldflux sync re-tries from the same client_run_id.