Skip to content

Pioneer Flow

Pioneer Flow is the visual work system inside Pioneer. A Flow connects blocks that acquire data, transform it, use models or Scripts when appropriate, and produce inspectable results and execution evidence.

Canvas, draft, and saved Flow

These terms name different things:

  • Canvas is the visual workspace.
  • A draft is the current editable Canvas state and can contain unsaved changes.
  • A saved Flow is a durable definition with an ID, monotonic revision, and executable fingerprint.
  • An execution runs one immutable snapshot and records its own run identity and provenance.

An open draft can differ from the saved Flow it was loaded from. Applying a change to one does not silently update the other.

Block concepts

Blocks have explicit configuration, inputs, outputs, and execution behavior. Current block families include data sources, deterministic transforms, model work, native Scripts, validation or quality work, and outputs.

Topology and configuration are separate:

  • topology says which blocks exist and how ports connect;
  • configuration says how each block behaves; and
  • validation checks whether the current combination is structurally executable.

A bounded source preview is inspection, not execution of the full Flow.

A trustworthy workflow

  1. Build the draft on Canvas.
  2. Validate topology and block configuration.
  3. Inspect current state and relevant source evidence.
  4. Save deliberately when you want a durable Flow revision.
  5. Run an identified saved snapshot with the required authority.
  6. Diagnose an explicit run from its outcome, stages, failure anchor, approvals, and bounded output.
  7. Propose a guarded change without applying it.
  8. Apply only after explicit human approval and a live guard recheck.
  9. Rerun only with separate run authority.
  10. Verify by comparing the explicit baseline and post-change runs.

Keep lifecycle steps separate

Validation is not execution. Proposal evaluation is not apply. Draft apply is not save. Saved apply is not run. A completed run is not automatically a verified repair.

Inspecting and diagnosing

Start with the narrowest evidence that can answer the question:

  • Canvas for current topology, configuration, validation, and selection;
  • Executions for what actually ran and the durable outcome;
  • Chat for bounded inspection, evidence-grounded diagnosis, and structured proposals; and
  • Logs for operational detail after run evidence has identified the area to inspect.

Run diagnosis should name one run ID. Pioneer does not silently choose “latest” when a claim needs stable provenance.

Repairs and stale state

Flow proposals retain the target's current fingerprint and, for saved Flows, its revision. If either guard changes before apply, Pioneer stops the operation as stale. It does not automatically rebase a model's proposal onto new state.

For the approval boundaries around this workflow, read Human Authority.

Task guides