One change per cycle is not caution. It is the only way the next window means anything.

The loop

Measure, rank, apply one, observe, keep or revert — and the last step is the one that gets skipped.

The cycle is short and every stage has a stated output. Measurement produces the driver diagnostics. Ranking produces a priced list of candidate repairs. Application commits to exactly one, expressed as a rule change specific enough that a third party could check whether it was followed. Observation runs the change over a window long enough to clear the sample gate. The final stage decides: the window either supports the change or it does not, and if it does not the prior state is restored. That last decision is the one most likely to be quietly skipped, because a fix that did not obviously fail tends to stay in the plan by default rather than by verdict.

Why bundling is unrecoverable

Two simultaneous changes produce a result that cannot be decomposed, in either direction.

Suppose an operator tightens entry criteria and moves the first partial from 1R to 1.25R in the same week, and expectancy improves. Which change earned it? Possibly both. Possibly one earned more than the improvement and the other cost some of it back, which would mean a good change is now permanently paired with a bad one. Nothing in the following data can separate them, because they never varied independently. The failure is symmetric and worse on the downside: if expectancy falls, the operator faces a choice between reverting both — discarding a change that may have been correct — and reverting one at random. This is the same isolation principle the scenario contracts enforce upstream, arriving at the point where it costs real money.

The revert clause

Decide what would falsify the repair before you ship it, and write it down.

A repair should leave the review with two things attached: the expected direction of the effect and the specific evidence that would prove it wrong. Deciding the exit before the entry is exactly the discipline the trading itself runs on, and it works here for the same reason — the conditions under which a failing change gets abandoned are much better composed before the change has an owner. Once a repair has been in the plan for a month, reverting it feels like an admission rather than a procedure, and the operator starts finding reasons the window was unrepresentative. The pre-written clause removes that negotiation by settling it while nobody was invested.

• Write the falsifying evidence at the same moment the change is written.
• A reverted repair is a successful cycle — it produced a verdict.
• The prior state must be restorable, which means it has to have been recorded.

Why the window has a floor

A repair judged on six trades is a repair judged on nothing, however clean the change was.

The single-change rule buys clean attribution, and a window below the sample gate spends it immediately. Execution metrics are noisy at small counts; adverse excursion in particular has a wide dispersion, and six trades can move an average by more than any realistic repair would. The temptation to call the verdict early is strongest when the early evidence is favourable, which is exactly when the call is least reliable. The honest position during an under-sampled window is that the repair is in force and unjudged — an uncomfortable state to sit in, and considerably cheaper than the alternative of confirming a change on noise and building the next month on it.

The exception that is not one

A rule violation is not a repair, and fixing it does not consume the cycle's single change.

There is one common case that looks like an exception. If the diagnostics reveal that a stated rule was not being followed — the trail was not activated where the branch requires it, the partial was skipped — then restoring compliance is not a system change and does not need a cycle to itself. The system was never running as specified, so there is nothing to attribute; the prior window is contaminated evidence rather than a baseline. Restore the rule, discard the window as a test, and start the repair cycle from the next one. Confusing a compliance failure with a design failure is how operators end up redesigning a system that was never actually deployed.

The key idea

The point of a repair is not the improvement; it is the sentence you can write afterwards.

A cycle that ends with a defensible statement — this change was applied, this window was observed, this is the verdict — has added something permanent to the system, and it has done so whether the verdict was favourable or not. A cycle that ends with three changes and a better month has added a feeling. Over a year the first kind of cycle accumulates into a plan whose every provision has a reason attached, and the second kind accumulates into a plan nobody can safely simplify because nobody remembers which parts are load-bearing.