Versioning AI workflows: what to freeze so long-running cases don't drift

The version number didn't change. The payment did.

A commercial-claims workflow calculates a settlement, checks policy, gathers evidence and pauses while a senior adjuster reviews the recommendation. It runs as workflow version 12. A claim produces a $48,500 proposal. The adjuster sees the amount, claimant, coverage basis and evidence, and approves it. The case then waits for a separate release event before payment.

During the wait, nobody touches the workflow's steps. But several things it points to move on:

• the model alias settlement-model/approved now points to a newer deployment;
• claims-policy/current advances from revision 31 to 32;
• the settlement-release/latest mapping changes how a missing deductible defaults;
• the claims-manual retrieval index is rebuilt from an updated corpus;
• a feature that summarizes prior litigation cost changes its lookback window;
• the regional router moves the tenant to another inference environment.

When the release event arrives, the runtime resolves the same aliases again, recomputes the payload with the new mapping and feature, confirms it under the new policy, and pays. It sends $62,000. The approval record still says "approved", but it approved $48,500.

Every component can defend itself. Version 12 didn't change. The aliases resolved correctly. The new policy was valid. The mapping passed its tests. The payment service did what it was asked. What nobody can say is which version of the application actually ran.

Is a workflow version the same as an application version?

No. A workflow version identifies the diagram. An application version must identify everything that shapes behavior: contracts, mappings, policies, prompts, model rules, retrieval, tools, review screens and evidence.

Configuration management has long separated an agreed baseline from later changes and required a controlled process to change it. That idea still holds. What's different with AI applications is the size of the thing being baselined. It isn't a binary or a diagram. It's every artifact that changes what happens at a governed step.

That matters most when cases live a long time. A short request resolves its dependencies once. A paused case can cross several releases, policy changes, data revisions, model updates, approval expiries and environment moves before it does anything consequential.

So the question isn't "which workflow file did we deploy?" It's three questions: which application meaning was approved, which dependencies carried it out, and which current facts still had to be true when it acted?

What "frozen" should mean

"Frozen" is a useful word that gets overloaded. Taken literally, it suggests copying every input, record, credential, model response and policy into one permanent snapshot. That's neither practical nor wanted. Some facts have to stay current, because their validity changes over time.

A sound approach uses five binding modes instead of one universal freeze:

Each mode solves a different problem. An immutable definition stops silent edits. A pin stops an alias drifting. A governed selection rule keeps portability while limiting what can be picked. A recorded observation lets you reconstruct the past. A current-state recheck stops an old approval or policy decision being treated as valid forever.

Which parts of an AI workflow need a pinned version?

Anything whose change would alter the outcome: schemas, mappings, queries, policy references, prompt revisions, retrieval rules, sub-workflows, tools and the review screen the approver saw. Models get a pinned selection rule plus a record of what ran.

The version should have a stable, canonical form and a digest. A digest proves the definition hasn't changed since it was approved. It doesn't prove the application is correct or authorized. Schema identities should be explicit too: declaring the schema dialect and version stops two consumers validating the same payload under different rules.

A software bill of materials is a useful input, but it lists packages. It doesn't describe prompts, policies, mappings or review screens.

Models, prompts and policies

A model's marketing name or a mutable alias isn't a version. Bind the prompt and tool definitions, the output contract, the approved deployment class, the evaluation profile and the rule for choosing a target. Then record the actual endpoint or release each run used. If a provider can't expose an immutable identity, record the best release metadata available and treat silent provider drift as a named risk.

For policy, keep the revision that produced each decision. Separately, declare whether current policy is rechecked at resume or before the change. "Why was this allowed then?" and "May this happen now?" are different questions, and a consequential action often needs both answered.

Secrets never go in the published definition. The version binds the credential type and scope; the runtime resolves the secret and records only that it validated.

Data and features

Versioning data doesn't mean copying the database for every run. Depending on the stakes, keep the record version, effective time, document revision, query and feature definitions, point-in-time feature values, index revision, or a snapshot of the exact context given to the model. Revision identifiers on mutable records let you prove whether a record changed after the proposal was made. The point is to tell "the same customer" apart from "the same version of that customer's record".

Three moments that govern one run

Versioning gets clearer once you separate three moments:

1. Publication: what behavior is allowed? The definition is validated and frozen, with its dependency list, compatibility rules, required evidence and migration policy.
2. Start: what did this run resolve? The runtime resolves whatever is allowed to vary and writes down exactly what it picked.
3. Resume or commit: what must still be true? Before a paused case continues, or before a change reaches the outside world, the runtime rechecks authority, scope, policy, record revision, approval and any earlier uncertain action.

These three moments stop two opposite mistakes. One is resolving everything late, which makes the past impossible to reconstruct. The other is freezing a past authorization and treating it as valid forever. Zero-trust guidance points the same way: access depends on current identity, resource and environment, so yesterday's sign-in isn't today's authority.

Should a paused case resume on the latest version?

No. A running case stays on the version that started it. New publications govern new cases. Moving a live case forward is a deliberate migration, not a pointer update.

That doesn't mean every external dependency must stay online forever. It means the runtime keeps the case's application identity, what it resolved, and rules for what to do when a dependency is retired.

When an event or decision arrives after a long wait, a resume check decides whether continuing is still legitimate. It compares the waiting step, proposal and version identities; the proposal digest and the current record revision; the authority and policy conditions that must still hold; the approval's scope and expiry; whether bound dependencies are still available; whether something else has already changed the business state; and whether an earlier action is uncertain and needs reconciling first (see retries and idempotency).

The outcome is one of four: continue on the original version, continue after rechecking current facts, migrate under control, or stop and return for re-approval.

Migration is a business change

There are good reasons to move a running case to a newer version: a security fix, a retired dependency, a regulatory change, a corrected rule. It has to be explicit, because it can change what a pending approval, proposal or state value means.

A migration policy should say which source and target versions qualify; which paused states can move; how state, IDs and schemas transform; which dependencies stay historical; whether old policy decisions remain binding or become evidence only; which approvals survive and which need renewed review; how timers, events and uncertain actions are reconciled; and what the fallback is. "Resume on latest" skips every one of these questions. It isn't a migration policy. It's an admission that the version never meant anything.

Rollback doesn't rewrite history

Rollback republishes an earlier version for new work. It doesn't change which version past runs used. Their records keep pointing at what actually governed them.

Rollback and replay also depend on retention. You can't reconstruct or resume an older version if its prompt, policy bundle, schema, mapping, model deployment or sub-workflow was never archived. Retention and dependency inventory are operational requirements, not just audit tidiness.

Replay works the same way. Rerunning a case against today's models, policies and data doesn't reproduce what happened; it tests a new application against old inputs. A pinned version and a run manifest let you separate inspecting the past, simulating it without side effects, comparing a proposed version against history, and re-executing under current checks. Behavior replay covers those modes. Bit-for-bit reproduction may be impossible when a hosted model or external source can't be recreated. Say so plainly. Knowing exactly what ran still has value.

Common anti-patterns

Ten rules for versioning AI workflows

1. Define the application version as the workflow plus every dependency that shapes its behavior.
2. Inventory contracts, mappings, policies, prompts, models, context rules, features, tools, sub-workflows, review screens and environment rules.
3. Give each dependency one binding mode: immutable, pinned, governed selection, recorded, or rechecked.
4. Allow "latest" only when the selection rule and the actual result are both governed and recorded.
5. Write a run manifest of what each case actually used.
6. Keep historical evidence separate from current permission.
7. Bind every approval to the exact proposal, evidence and version reviewed.
8. Keep running cases on their version; migrate only deliberately and with evidence.
9. Retain what rollback and replay need.
10. Version the change process too: migration, rollback, deprecation and resume rules.

The result: fixed meaning in a changing world

Versioning an AI workflow isn't about making the enterprise static. Data changes, policies evolve, people lose authority, models improve and systems retire. Long-running cases have to work in that world.

The job is to make change visible. Freeze what the application means, pin or govern what can alter that meaning, record what each run actually used, and recheck what depends on the present. The workflow version tells you which diagram was published. The application version tells you what was approved. The run manifest tells you what actually ran. The resume check tells you whether it may still act now.