Key takeaways
- A living SOP changes through controlled proposals, not silent edits. Every proposal needs a trigger, owner, evidence, affected clauses and affected workflow nodes.
- Pin each run to one approved SOP and workflow version. Mid-run changes create evidence nobody can later reconstruct.
- Treat corrections, repeated exceptions and system changes as review signals, not automatic permission to rewrite the process.
- Roll out a new version to test cases first, preserve the previous version for rollback and close the change only after real runs meet acceptance criteria.
Treat operating evidence as a signal, not an automatic edit
A colleague corrects a category twice. A form gains a required field. One exception queue starts receiving half the volume. Each fact deserves review, but none proves what the new rule should be. Silent self-editing would turn observed behaviour into policy without an owner.
ISO 9001 connects maintained documented information with evaluation and improvement. The word maintained matters. A living SOP is current because changes pass through control, not because anyone can rewrite it quickly.
| Signal | Evidence to attach | First question |
|---|---|---|
| Repeated operator correction | Before value, proposed value, reason and frequency | Is this a stable rule or expert judgment? |
| System or field change | Release note, schema diff and failed test | Which clauses and nodes depend on it? |
| Exception spike | Baseline, current rate and case sample | Did the process change or did input quality fall? |
| Policy decision | Approved source, owner and effective date | Must in-flight work follow old or new policy? |
| Near miss | Timeline, affected control and safe outcome | Should execution pause before analysis ends? |
Run every material change through seven states
- 01ObservedTriggerRecord the signal without changing the procedure. Link it to affected runs and preserve raw evidence.
- 02TriagedHuman approvalThe process owner labels it as training, input quality, runtime defect, procedure ambiguity or policy change.
- 03ProposedHuman approvalWrite a redline against exact SOP clauses plus the matching workflow-node changes, migration rule and rollback condition.
- 04TestedCodeRun ordinary, boundary, exception and historical regression cases. Record results against acceptance criteria.
- 05ApprovedHuman approvalThe authorized owner approves one SOP version and one compatible workflow version as a pair.
- 06ReleasedCodeSend new runs to the version gradually. Pin existing runs unless the approved migration rule says otherwise.
- 07Closed or rolled backHuman approvalCompare live results with the acceptance window. Close with evidence or restore the previous pair and reopen the proposal.
Version the document and workflow as one compatibility pair
Signal: 11 of 40 sample requests used a newly mandatory region field. Proposal: SOP clause 3.2 changes from “validate postal code” to “validate country, region and postal code”; workflow node validate-address@4 adds the field and a missing-region exception.
Pair: SOP 2.4 is compatible with workflow 4.1. Runs already started on SOP 2.3 remain on workflow 4.0. New runs enter a 10-case canary. Two false rejections trigger rollback.
Closure: the owner reviews the ten outcomes, exception count and evidence completeness. The figures are illustrative, not customer or product results.
| Record | Required value |
|---|---|
| Change identity | Proposal ID, owner, opened date and reason |
| Document diff | Old clause, new clause and approved source |
| Runtime diff | Affected nodes, data contracts, permissions and tests |
| Compatibility | Allowed SOP/workflow version pairs |
| Rollout | Population, start time, stop condition and rollback target |
| Decision | Approver, outcome, evidence and effective time |
Use a short path for wording and a full path for behaviour
| Change | Route | Why |
|---|---|---|
| Typo with no change in meaning | Editorial review, same workflow | Execution and operator choice are unchanged |
| Clearer example using the same rule | Owner review plus comprehension check | Training may change even when execution does not |
| Threshold, role or system of record | Full proposal, regression test and approval | Authority or path changes |
| New model judgment | Full path plus evaluation and monitoring plan | Output variance changes |
| Emergency prohibition | Immediate safe stop, then retrospective change record | Containment precedes normal release |
The SOP audit trail supplies the evidence for this loop. Without version-bound run records, repeated exceptions become impressions and regression cases disappear with the operator who found them.
Limitations and when not to use this
- Continuous improvement does not mean continuous deployment. Some procedures need scheduled review windows, independent approval or formal validation.
- A correction log can reflect one operator's preference or a biased sample. Require enough evidence to distinguish drift from noise.
- Emergency changes still need a retrospective record, testing and an owner. Urgency shortens the path to a safe stop; it does not erase accountability.
Sources
- ISO 9001:2015 — Quality management systems — International Organization for Standardization Accessed 31 July 2026
- AI Risk Management Framework Playbook — National Institute of Standards and Technology Accessed 31 July 2026
Design the audit record
Define the version and execution events the change loop must preserve.
Design the audit recordUli Prantz
Builds and operates all-agents
Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.