Before changing the system, complete these two sentences:
“If we change [specific behavior], [measured outcome] should improve under [defined workload], because [mechanism].”
“We will reconsider that explanation if [disconfirming observation].”
Those sentences give the change a purpose and the test a decision to support. They also expose the missing facts. If the outcome, workload, or mechanism is still vague, that is useful information before anyone starts interpreting a result.
Name the mechanism
“This should make it faster” leaves too much open.
Describe the behavior you expect to change. A proposed change might remove repeated work, reduce waiting, or alter how a workflow uses a constrained resource. Each explanation points toward different observations.
Ask what should move if the explanation is right. Then ask what should remain unchanged. If the expected signal never appears, a faster headline number alone does not establish the mechanism you predicted.
When the constraint is unclear, start with the Teardown Stack: define the path and collect evidence about where time goes. A prediction should grow from that investigation.
Define where the prediction applies
Name the workflow, its start and end events, and the population being observed. Decide how failed or incomplete attempts will be represented. An improvement among completed requests may leave an important part of the experience unexplained.
Describe the workload and the conditions around it. Request mix, data shape, cache state, and environment belong beside the result. Record differences that could change its interpretation.
The load-testing guide examines test design. This record adds the expectation and the decision criteria you will bring to the comparison.
Copy this decision record
This is a proposed blank tool. Fill it with evidence from your system. Leave unknowns visible rather than assigning them convenient values.
- Hypothesis: Which behavior will change, and why should that affect the outcome?
- Boundary: Which workflow and population are included? Where does observation start and stop? How are failed or incomplete attempts counted?
- Workload: Which operations, request mix, offered load, and observation window will be used?
- Data: What size, shape, distribution, and configuration matter? What will stay consistent between comparisons?
- Cache state: What state is intended at the start, and how will it be established and recorded?
- Environment: Which version, resources, dependencies, and settings apply? Which differences remain unresolved?
- Expected effect: What should improve, and what change would be useful? Use a direction or range when the evidence does not justify a precise estimate.
- Countermetric: What might get worse? Choose a relevant companion measure, such as errors, resource use, or useful work completed.
- Disproof: What observation would contradict the explanation? What would leave the comparison inconclusive?
- Observations: What actually happened, including variation, exceptions, and differences from the planned conditions?
- Decision: What action does the evidence support? Who owns it, and what question remains?
Write the expectation before examining the comparison. Preserve it when recording the observations, so the result can be judged against the original question.
Read the result as a decision
Improved: The intended outcome changes in a useful way under the stated conditions, and the companion measures stay within their agreed limits. Explain which part of the prediction the evidence supports and where that conclusion applies.
Worse: The target outcome deteriorates, or a companion measure crosses its acceptable limit. Record the tradeoff even if another number improves. Decide whether to revise the change, investigate further, or stop.
Inconclusive: Variation, changed conditions, missing observations, or an effect too small to interpret prevent a defensible decision. Name the unresolved issue and the next observation needed. A result that cannot distinguish the explanations should remain inconclusive.
Leave room for investigation
Exploratory profiling can come first. You may need several observations before a useful prediction exists. Record that uncertainty and revise the hypothesis as the evidence develops.
Once you have a candidate change, make its expectation reviewable. The next step should follow from what was observed: proceed within the tested scope, revise the explanation, or gather the missing evidence.
The record earns its place when it makes that next action clear.
Source posts: Prediction · Disproof · Measurement · Signals to decisions.