Improve One Number Step by Step, Keeping Only Changes That Measurably Help

## Set One Numeric Goal and Decide What May Be Changed State one outcome as a numeric metric with a direction, unit, and target. Define the exact assets, records, configurations, or process steps that may change, and list everything outside that boundary as read-only. - Express the goal as “move metric M from baseline B toward target T,” not as “make it better.” - Name the population, time window, environment, and measurement method so repeated results are comparable. - Set a change budget: maximum iterations, elapsed time, cost, and acceptable risk. - Identify dependencies that may distort the metric and hold them constant when possible. - If the metric, scope, authority, or rollback path is missing, pause and obtain clarification before changing state. Treat the objective and boundary as the experiment contract. Do not broaden scope merely because a nearby improvement looks useful. ## Measure the Starting Point and Set Numbers That Must Not Get Worse Measure the unchanged system before the first experiment. Run the verification at least three times when noise is plausible, then record the median, range, sample size, and relevant conditions. If repeated measurements are infeasible, state why and use the strongest reproducible baseline available. Define the decision rule before making changes: - Primary metric: the number to optimize and whether higher or lower is better. - Minimum meaningful gain: the smallest delta that counts as improvement rather than noise. - Guard metrics: numbers that must not cross safety, quality, reliability, latency, cost, or error thresholds. - Acceptance rule: keep only a change that beats the baseline by the required delta while every guard passes. - Invalid-run rule: discard results affected by missing data, changed inputs, verifier errors, or incomparable conditions. Never reinterpret thresholds after seeing a result. A noisy or unverifiable result is not a win. ## Try One Change at a Time and Measure It the Same Way Within the approved boundary, execute the loop autonomously: inspect the current best state, form one testable hypothesis, make one atomic change, run the fixed verifier, and compare the result with the current best. Change only one independent factor unless the factors cannot function separately and that dependency is documented. For every iteration: 1. Predict the metric direction and name the mechanism expected to cause it. 2. Apply the smallest change that can test the hypothesis. 3. Run the same primary and guard measurements used for the baseline. 4. Repeat measurements when the observed delta is close to the noise range. 5. Classify the outcome as keep, discard, invalid, or blocked. Do not stack an unverified change on top of another. The next iteration must always start from the best verified state. ## Keep Changes That Clearly Help and Undo the Rest Keep a change only when it satisfies the predeclared acceptance rule. Record the exact delta, guard results, and explanation, then make that verified state the new baseline. Equal results favor the simpler, cheaper, or more reversible option. Discard and roll back immediately when the primary metric fails to improve enough, any guard fails, verification is invalid, or the change creates an unexplained side effect. Restore the last verified checkpoint and rerun the verifier to confirm that rollback succeeded before continuing. Never place a new experiment on a failed or uncertain state. Maintain a compact experiment ledger with iteration number, hypothesis, change summary, measurements, delta, decision, and rollback status. Evidence determines the decision; confidence, effort spent, and attractive explanations do not override the numbers. ## Stop at a Preset Condition and Report the Best Measured Result Continue the loop without seeking routine approval until the first predeclared stop condition occurs. Stop when the target is reached, the iteration/time/cost budget is exhausted, a required guard repeatedly fails, rollback cannot be confirmed, the verifier becomes unreliable, authority is insufficient, or no meaningful improvement appears across the configured consecutive attempts. At completion, leave the system at the best verified state and provide a concise report containing: - the objective, scope, baseline, best metric, absolute and relative delta, and guard status; - the accepted changes and the evidence supporting each one; - discarded or invalid experiments and their rollback confirmation; - the exact stop condition, remaining uncertainty, and any follow-up that requires new authority. Do not call the work successful merely because the loop ended. Success means the measured target or acceptance threshold was met with all guards intact; otherwise report the best verified result and the reason for stopping.