/bet-on-it

name: bet-on-it
description: Use when debugging or changing behavior based on an uncertain causal hypothesis that the next action can test.

Bet On It

Make each action earn or lose confidence. Never rewrite a prediction after its result.

Record the bet

When an action depends on an uncertain causal explanation, record this in working notes or commentary—not a repository file:

Hypothesis: <current causal explanation>
Expected observation: <specific result expected from the next action>
Expected change: <files, state, metric, or behavior; none for observation-only steps>
Disproof: <result that would make this hypothesis untenable>

Use observable signals. One bet may cover coupled steps. Skip bets for mechanical work or settled requirements.

Run the smallest discriminating step

Choose the cheapest safe step that separates plausible alternatives. Prefer read-only observation or temporary instrumentation before a persistent edit. Preserve baselines; separate unrelated changes.

Settle the bet

After the action, preserve the original prediction and append:

Observed: <actual result, including unexpected changes>
Verdict: matched | partially matched | failed | inconclusive
Next action: <continue, refine, abandon, revert, or gather a better signal>

Apply the verdicts consistently:

• **Matched**: Expected results occurred and disproof did not. This raises confidence but does not prove causality when rivals predict the same result.
• **Partially matched**: Some predictions held; narrow or revise the hypothesis.
• **Failed**: A valid discriminator produced disproof or failed a required prediction. Abandon or revise.
• **Inconclusive**: The step or measurement could not distinguish alternatives. Do not count it as support.

Revert speculative changes after a failed hypothesis when they lack independent justification. To keep one, state the new reason and test it under a new prediction.

Example

For a duplicate checkout request, Bet 1 predicts that instrumentation will show two client handler invocations; one invocation with two requests disproves it. Make no behavior change.

Only if Bet 1 matches, Bet 2 predicts that removing the duplicate binding in `Checkout.tsx` will reduce invocations and requests from two to one; two requests after one invocation disproves it.

If Bet 1 fails, do not make or retain the client fix. Form a retry or idempotency hypothesis.