Exactly one improvement per execution cycle — not zero, not three — so you can attribute changes to effects

Why This Is a Rule

The scientific method's most basic principle — change one variable at a time — applies directly to workflow improvement. If you change three things between executions and the workflow improves, you don't know which change helped. If it degrades, you don't know which change hurt. Multiple simultaneous changes destroy your ability to learn from the experiment.

The "exactly one" constraint serves three purposes. First, attribution: with a single change, any effect (positive or negative) is clearly attributable. You changed the template format and error rate dropped — that's a signal. You changed the template, the order of steps, and the review process, and error rate dropped — that's noise. Second, reversion: if the single change makes things worse, you revert one thing. If three changes make things worse, you don't know which to revert. Third, momentum: "identify one improvement" is achievable after every execution. "Identify three improvements" is ambitious enough to become procrastination fuel. One improvement compounds over 50 executions into a dramatically better workflow.

The constraint also prevents zero improvements — the stagnation failure mode where each execution reveals problems but nothing changes because "I'll fix it later." Mandating exactly one improvement per cycle forces continuous evolution rather than accumulated technical debt in your personal processes.

When This Fires

• After completing any workflow execution, during the reflection/debrief moment
• When tempted to overhaul multiple aspects of a workflow simultaneously
• When a workflow has been static for many executions despite known problems
• Complements Give each workflow change 3-5 executions before deciding to keep, modify, or revert — distinguish signal from noise and prevent oscillation (3-5 execution stability test) with the single-change discipline

Common Failure Mode

Batch improvements: "I'll save up all the improvements and do a big overhaul." This feels efficient but produces unattributable results and increases the risk of cascading failures. The big overhaul changes everything, something breaks, and you can't tell what caused it. One improvement per cycle is slower but produces reliable, learnable evolution.

The Protocol

(1) After each workflow execution, ask: "What is the single most impactful improvement I could make before next execution?" (2) Choose the one with the highest expected impact — don't default to the easiest. (3) Implement the change before the next execution. Not after three executions, not "when I have time." Before the next one. (4) On the next execution, observe: did the change help, hurt, or show no effect? (5) Based on the observation: keep the change if it helped, revert if it hurt, give it 2 more executions if unclear (Give each workflow change 3-5 executions before deciding to keep, modify, or revert — distinguish signal from noise and prevent oscillation). Then identify the next single improvement.