The workflow directory

A workflow is not a row in a settings screen. It is a directory, and everything the workflow is made of lives inside it:

SOP.md                  the written procedure
codification/           the steps, once the workflow has been codified
references/             the files the workflow works from

Every change writes a new version of the whole directory. Version 6 is one snapshot of all three parts together, and every run points at exactly one version.

One version number, not three

The written procedure, the code and the reference files share a single counter. That is deliberate. When the SOP had its own version history and the files had none, a workflow could sit at code v3 and procedure v7, describing two different jobs, with nothing to show they disagreed.

Now there is nothing to disagree. Rewrite the SOP and the files stay put, but the version number moves for the whole directory. Swap a price list and the same thing happens. "What did this workflow look like at v6" has one answer.

Three things mint a version

Only three actions create a new version:

1. A reference file change. An upload, a replacement, a deletion, or keeping a file that a run produced.
2. Confirming an interview. Codification, a repair, or a revision.
3. Promoting a pending SOP revision.

A change that produces byte-identical content mints nothing. Re-upload the same spreadsheet and the directory is unchanged, so the history stays quiet. Publish the same SOP twice and the second publish promotes nothing.

Stage is read from the directory

A workflow is either agentic or codified, and you never set that flag yourself. It is read from the version: a directory with a step registry under codification/ runs through the interpreter, and a directory without one runs as an agent working from SOP.md.

This matters when a workflow steps back to learning. Demotion does not flip a label and leave the steps sitting there. It writes a new version with the code stripped out, so the thing the engine would run and the thing the console shows you are the same thing.

A run keeps the version it started on

When a run starts, it pins one version and works from that directory for its whole life, including after a pause for an approval that lasted three days. Replace a reference file mid-run and the run that is already going keeps the file it started with. A step's code was written against the file that shipped with it, so handing it a different one halfway through would be a quiet way to break a workflow.

Three things deliberately resolve live instead:

• Connections. A credential is identity, not procedure. Rotate a password and the next run uses the new one immediately.
• Your own model key, for the same reason. Work that queued behind a broken key drains as soon as you fix it.
• The text extracted from your reference files, which is fetched fresh at start and at every resume so an interrupted run and its resume build an identical agent.

What the directory does not hold

Some things are deliberately outside it:

• Credentials. Connections are referenced by name and resolved per run. No key is ever written into a version.
• The model and reasoning effort the workflow runs on. Those are runtime settings, so changing the model does not mint a version or put a live workflow through the adapt-or-reset question.
• Run records. A run's history is already durable in its own right. When an interview needs to read past runs, they are rendered fresh rather than stored a second time.
• Files a run wrote that you have not kept. A run can write output files, and they stay quarantined until you promote one. Until then no later run sees it, which is what stops one run from steering the next.

Seeing the history

The console lists every version of a workflow, newest first, with the SOP text as it read at that version. Test runs of an unpublished draft appear there too, labelled v1.1, v1.2 and so on: real directories a run can pin, kept out of the version counter so that testing a draft can never publish it by accident.

Version-to-version diffs and downloading a directory are not available.