Flows and runs

A flow is a versioned description of a journey through your application: the steps, the targets each step resolves to, and what the flow is meant to produce. It lives as JSON in the workspace and is checked against a canonical schema.

A run is one execution of a flow against one environment. It produces artefacts — frames, markup, audio, rendered video — and a record of what happened.

The separation is what makes the refresh loop work. The flow is stable across releases; the run is what changes when the product does.

Not every flow is recorded

A browser journey is one source of a flow, not the only one. A slide deck becomes one (ff deck), so do pictures and clips you already have (ff media), and a flow file can be written by hand against the schema. Those flows have no browser in them at all — their steps show an asset rather than act on a page — so they compose without one.

The file is the common shape. ff publish saves one as a flow, uploading any picture it names by path along the way. See Flow files.

A run is governed by default

ff run replays an approved flow, uploads every artefact to the control plane, verifies checksums, and emits run and output URLs.

What it does not do is publish. The output of a run is a draft that a person reviews. See Review and approval.

Watching one

ff status <run-id>

Runs are queued per organisation, which is why the control plane surfaces them centrally: a render waiting behind a colleague's is invisible from the flow you happen to be looking at.

Capture and render are separate stages

Capture needs a browser and your environment. Rendering — composing video, synthesising narration — needs neither, and is far slower and more expensive.

Keeping them separate means a re-render never re-drives your application, and a capture failure never burns a video-generation bill.