Define the reported execution before testing
Synthetic report: build v4 exports rows A and B with filter F, but B is missing. Reproduction trial D-61 uses v4, the same synthetic rows and F; it reproduces the omission. D-62 uses no filter and passes, testing a different condition. No live customer data is needed. This fixture treats reproduction as evidence of behaviour under the stated input, not proof of the underlying cause.
| Trial | Baseline | Observed output | Conclusion |
|---|---|---|---|
| D-61 | v4 / A,B / F | A only | Reported omission reproduced |
| D-62 | v4 / A,B / no filter | A,B | Different condition passes |
| D-63 | Version not recorded | A,B | Insufficient baseline comparison |
Compare like-for-like observations
- Capture reported baseline
- Prepare synthetic equivalent input
- Run the specified action
- Record observed output and limits
If the original condition is unknown, label the test exploratory rather than claiming successful reproduction.
Does D-62 prove the customer’s filtered export was healthy?
Show the worked answer
No. D-62 omits F. D-61 matches the reported condition and reproduces the failure; neither test alone establishes its cause.
When version, input or action differs, record the difference before interpreting a pass. Keep exploratory findings separate from a matched reproduction.