The Evidence-Preserving
Experiment.

Premise

When a small system behaves strangely, the first job is not to explain it but to preserve what was actually observed. Reproduce the failure, record the exact state and conditions, change one variable, and observe again.

A useful report keeps observation separate from diagnosis:

“The first load remained at CONNECTING at 11:49 UTC; refresh reached the backlog” is evidence. “The websocket handshake is broken” is a hypothesis. The first can be handed off; the second must earn its place.

Practical exercise

Choose a small intermittent behavior in a tool, page, or script. Do not provoke failures that could harm people or data.

1. Run it once without changing anything. Record the UTC time, route or command, visible state, inputs, and result.
2. Repeat under the same conditions if possible.
3. Then change exactly one variable per comparison—refresh, reconnect, input, browser, or environment—and run it again. “One variable” applies to each comparison, not necessarily to the entire investigation: a sequence of controlled tests may change one variable at a time.

Produce a four-part handoff:

1. original observation,
2. controlled change,
3. new observation,
4. the smallest diagnosis the evidence supports.

Mark every unknown explicitly; do not fill gaps with mechanism-shaped fiction.

Second half: the healthy retest

Before writing the conclusion, repeat the original attempt once more under unchanged conditions. If the failure does not reproduce—the page loads, the connection completes—that is not a contradiction to explain away and not an embarrassment; it is a second result.

Intermittence is itself a finding, and it shrinks the claim:

“Stuck at CONNECTING at 11:49 UTC; connected normally at 13:19 UTC” establishes variability inside a window—not a broken transport layer.

A failed reproduction is still a result, and the conclusion stays proportional to the evidence: name the window, the conditions, and what the two observations together do not establish.

Evidence checklist

• Exact UTC timestamp for each attempt.
• Route, command, version, or other unambiguous target.
• Initial conditions and relevant inputs.
• Exact visible state, error text, or output—not a paraphrase when the original is available.
• Whether the behavior reproduced.
• One changed variable, named plainly.
• Result after the change.
• Console, network, or log evidence when available, with secrets removed.
• Separate labels for observed, changed, inferred, and unknown.
• Scope limits: what was not tested and what the report does not establish.

Review rubric

Score each category 0–2 (10 points total).

Scoring bands: 8–10 ready for operational handoff · 5–7 useful but needs clarification or a tighter experiment · 0–4 a narrative of impressions; repeat the test before drawing conclusions.