Policy Change Audit: The Workflow Definition Needs Its Own Versions and Its Own Log

The encoded workflow closes the gap between policy and execution: the definition is the change-management policy in executable form, and a skipped gate is a failed task (reproducibility, the sixth of the seven properties). The execution log proves every task passed through the gates that existed when it ran. It cannot prove which gates existed, or who changed the set. Those are facts about the definition, and "drift is structurally impossible" holds only once the definition has its own version history and its own change log.

The failure is quiet by construction. Remove the required-approval step from a mutable workflow config and every task from that moment on shows a clean run: 100% of tasks passed every gate, because the approval gate is no longer among them. No control was bypassed; the control was removed, and removal leaves no trace in a log that only records executions.

A mutable definition reproduces drift one layer up

Reproducibility replaces "policy is a document, execution is human habit" with "policy is the workflow definition, execution is the workflow running." A team that stores the definition as one config row an admin edits in place has rebuilt the original drift problem in a new location: the policy can silently diverge from what anyone believes it to be.

This is also the layer an insider reaches for first. Tampering with the execution log after the fact is hard when the log is external and append-only. Editing the rules before acting is easier, and it launders the act: everything downstream is legitimately approved under the loosened rules.

Publish immutable versions and pin one to every task

Two mechanisms close the gap.

Immutable versions. A workflow definition is never edited in place. An edit produces a draft; publishing the draft creates a new immutable version and activates it. Old versions are never rewritten or deleted, and disabling or archiving a workflow is an explicit recorded transition rather than a row deletion, so "this policy stopped existing on March 3" is itself a fact on file.

Task-level pinning. Every task records the definition version in force when it was created and stays bound to it, even if the definition changes mid-run. The task record then answers the audit question exactly: not "here is our current workflow" but "here is the version this change ran under, as published on this date by this person." This is the same move versioned images make for the environment. A-LIGN's retrieval bar, demonstrating "what it was capable of at any point in the past six months" (A-LIGN), applies to the rules the agent ran under as much as the runtime it ran in.

Policy changes get their own stream, separate from execution and access

Versioning preserves the states; a change log preserves the transitions. Keep three streams:

• Execution. What tasks did: the session and event log, the high-volume stream the audit trail property governs.
• Policy changes. Who published, disabled, archived, or re-enabled which workflow version, and when. Low volume, high stakes.
• Access. Who was granted or used what. Routine and noisy.

The separation is what makes the policy stream answerable. Folded into the execution stream, a dozen publish events a quarter drown under millions of task events, and the four-axis audit query has no axis for "changes to the rules." As its own stream, the auditor's "who authorized this gate to become skippable" resolves to one row.

Record actors as they were at the moment of the act. Membership churns: the person who published version 4 may have left, changed name, or changed role by audit time. Snapshot the actor identity into the event instead of joining to a live user table at read time.

The change process applies to the change process

The SOC 2 CC8.1 row cites the encoded workflow definition as an evidence artifact (SOC 2 mapping), and an artifact offered as evidence has to be governed like one. The auditor corpus already asks the recursive version: Kognitos's SOX list includes "How is the AI's decision logic version-controlled?" and who can modify the agent, with that access reviewed (Kognitos); it appears as question 12 in the auditor question bank. Vanta's distilled standard, "evidence, not policies" (Vanta), cuts here too: "workflow edits require approval" is a policy sentence, while a policy stream showing every publish with its actor is the evidence, produced as a byproduct of publishing being the only way a definition changes.

The strongest form routes a definition change through a gated workflow itself: the publish is a task, review is a gate, and the policy stream records the approval. Whether you go that far or hold publishes behind role-scoped permissions plus the change log, the bar matches the one the workflow imposes on code: no unrecorded transition. And the trigger block is part of the definition. Loosening a trigger filter or a dedupe rule changes when and how often the policy fires (event routing and dedupe), so it gets the same versioned, logged treatment as removing a step.

What the stream does not cover

Two fences. First, the policy stream records changes made through the system's own write path. A database administrator with direct write access to the definitions table bypasses it, so the table needs the protections the execution log already gets: restricted writes and tamper-evident storage. Second, the stream governs the workflow definition, one of three things that determine agent behavior. The model version and the prompt content drift on their own schedules, and the reproducibility page's fences cover why those are recorded per task rather than pinned.