Operator Stack
Workflow Jun 10, 2026 published

AI Automation Change Log Template

A practical change log template for AI automations so prompt, source, script, and review-rule updates stay traceable after launch.

Small AI automations rarely fail because one dramatic change was made. They usually drift because prompts, scripts, source rules, and review notes are edited quickly over several weeks.

A change log keeps those edits visible. It tells the next operator what changed, why it changed, which evidence supported the change, and what needs to be retested before the workflow runs unattended again.

What Belongs In The Change Log

Log any change that affects output quality, source evidence, access, or delivery.

Common entries include:

  • Prompt edits.
  • Source URL additions or removals.
  • Spreadsheet column or formula changes.
  • New stop conditions.
  • New acceptance criteria.
  • Script updates.
  • Manual fallback changes.
  • Disclosure or compliance notes.
  • Review cadence changes.

Do not use the change log for every typo fix. Use it for changes that could affect whether the automation is safe, accurate, or repeatable.

Copy This Change Log

Place this template beside the workflow SOP:

Workflow:
Change date:
Changed by:
Change type:
Previous version:
New version:
Reason for change:
Evidence or exception that triggered the change:
Files, prompts, sources, or rules changed:
Expected impact:
Risk if wrong:
Retest required:
Retest result:
Rollback target:
Approved to resume:
Resume date:

The important fields are reason for change, risk if wrong, and retest result. Without those fields, the log becomes a list of edits instead of an operating control.

Use Simple Change Types

Use a short fixed list so entries stay scannable.

Change typeUse when
PromptInstructions, examples, or formatting rules changed.
SourceEvidence URLs, source freshness rules, or citation requirements changed.
InputRequired fields, file shape, form questions, or spreadsheet columns changed.
ScriptCode, formulas, automation steps, or file paths changed.
ReviewAcceptance criteria, stop conditions, or handoff checks changed.
AccessPermissions, credential handling, or private-data boundaries changed.
FallbackManual delivery or rollback steps changed.

This keeps the log useful even when several parts of the workflow change on the same day.

Every meaningful change should point to a reason.

Good reasons:

  • A repeated exception appeared in the exception log.
  • A source page moved or became unreliable.
  • A reviewer found an unsupported claim.
  • A client changed the required output format.
  • A workflow asked for data it should not access.
  • A rollback showed the manual fallback was incomplete.

Weak reasons:

  • The prompt felt stale.
  • The output looked better in one test.
  • The operator wanted to try a new model.
  • The change seemed harmless.

The goal is not to block improvement. The goal is to prevent unexplained edits from becoming hidden risk.

Retest Before Resuming

After a change, run the smallest test that proves the workflow is still safe.

Use this retest checklist:

  • The workflow runs on a known input.
  • The output still meets the acceptance criteria.
  • Factual claims trace back to source evidence.
  • Any public, client-facing, or buying-related recommendation has review notes.
  • Private data is not sent to an unsafe destination.
  • The rollback target is still available.
  • The handoff notes describe the change.

If the change affects source evidence, public claims, client reports, private data, or money-related decisions, do not resume unattended operation until the retest is recorded.

Keep The Latest Version Easy To Find

Use a simple folder pattern:

workflow-name/
  current/
    prompt.md
    source-log.md
    acceptance-criteria.md
    change-log.md
  archive/
    2026-06-10-change-note.md

The operator should not need to search chat history to know which prompt or rule is current. The current version should be visible in the workflow folder.

Turn Repeated Changes Into Product Decisions

The change log also helps with monetization.

If a workflow needs the same kind of change every week, it may not be ready to become a product. If the change log stabilizes after a few accepted runs, the workflow may be ready to package as a checklist, template, service SOP, or small paid workflow.

This is useful evidence. Stable workflows can become assets. Unstable workflows should stay as reviewed services until the repeated judgment is understood.