Change my mind

Change My Mind

A conclusion that can't name what would overturn it isn't a conclusion — it's a belief wearing a lab coat. This skill makes every verdict falsifiable and every important document alive: it states, in advance, the specific evidence or event that would flip the call, who or what is authorized to trigger a revision, and when to check even if nothing obvious happened. The discipline is simple and it changes everything — a conclusion is retired not because it aged, but because a named piece of evidence moved.

The core deliverable: for every verdict, its kill conditions

For any load-bearing conclusion, specify the four trigger types below. You don't need all four every time, but you need at least the datapoint and the calendar check — a verdict with neither is not falsifiable.

1. Datapoint trigger (easiest, most common) — a specific measurable result that would flip the verdict. "This reverses if the next official labor dataset fails to replicate the early-career employment effect." Testable, often on a known schedule.
2. Incident trigger (hardest to predict, most important) — a discrete event that forces immediate re-evaluation, not a scheduled one. "Flips to negative if a second, higher-success incident of type X surfaces within 18 months." Don't wait for the calendar; evaluate within a stated window when it fires.
3. Threshold trigger (for capability/scale claims) — a level crossing that upgrades or downgrades the evidence itself. "Converts from expert-consensus to measured-fact if a system is confirmed above threshold T."
4. Calendar checkpoint — a default re-confidence check on a fixed cadence (e.g. no verdict goes untouched more than 12 months without a recalibration), even absent new evidence. Catches slow drift and stale priors.

Some claims are honestly non-falsifiable — say so

A few conclusions can't be falsified by advance evidence — only judged after the fact (e.g. one-shot tail risks with no base rate). Don't fake a trigger for these. Mark them explicitly as non-falsifiable-in-advance, report them as a distribution of judgment rather than a single value, and note that the honest move is to track the reasoning, not to pretend a datapoint will settle it. Naming this is itself a form of intellectual honesty the reader can rely on.

Make the document live: the provenance ledger

For anything meant to guide action over time, don't silently overwrite when the verdict changes. Keep a visible ledger:

• What the verdict was, and what evidence/event changed it, and when.
• Preserve the prior verdict rather than erasing it — how a conclusion's mind changed is itself valuable, and auditable.
• Version the document (major = the framing/method changed; minor = a new section/verdict; patch = an update to an existing verdict from new evidence).

The ledger is what converts a one-time analysis into a standard that earns trust by showing its work over time.

Procedure

1. Restate the verdict/forecast/plan crisply.
2. For each load-bearing conclusion, write its triggers: datapoint (required), calendar (required), plus incident/threshold where they apply.
3. Mark any genuinely non-falsifiable-in-advance claims as such; report them as distributions, not points.
4. List the leading indicators to watch and where they're published/observed — the standing monitoring list.
5. If the artifact will persist, set up the provenance ledger + version scheme.
6. State the review cadence and who/what may trigger an off-cadence revision.

Output template

VERDICT: <the conclusion, crisply>

KILL CONDITIONS:
  Datapoint → flips if: <specific measurable result> (source, cadence)
  Incident  → re-evaluate within <window> if: <discrete event>
  Threshold → upgrades/downgrades if: <level crossing>
  Calendar  → recheck by: <date/cadence> regardless of news

NON-FALSIFIABLE-IN-ADVANCE: <any claims that only resolve post-hoc — report
  as a distribution, not a point>

WATCH LIST: <leading indicators + where to find them>

LEDGER (if living doc):
  vX.Y — <date> — verdict: <…> — changed because: <evidence/event> — prior: <…>
REVIEW CADENCE: <interval> | TRIGGER AUTHORITY: <who/what forces an update>

Example (compressed)

Verdict: "Our product bet assumes agentic coding tools will reliably handle multi-hour tasks by end of next year."

KILL CONDITIONS:
  Datapoint → flips if the standard task-horizon benchmark's doubling trend
    breaks across two consecutive quarterly updates (either a plateau or a
    jump changes the timeline).
  Incident → re-evaluate within 2 weeks if a shipped model is found to have
    silently regressed on long-horizon reliability post-deployment.
  Threshold → upgrades from "assumed" to "confirmed" when an independent eval
    shows >80% reliability at the multi-hour mark (not vendor-reported).
  Calendar → recheck the whole assumption every quarter regardless.

WATCH LIST: the task-horizon benchmark (quarterly), independent eval reports,
  our own internal reliability logs.
REVIEW CADENCE: quarterly | TRIGGER AUTHORITY: eng lead may force an off-cycle
  review if the internal logs diverge from the benchmark.

Now the bet isn't a hope — it's a claim with a tripwire. If the trend breaks, you find out on purpose instead of in a retro.

Gotchas

• A trigger must be observable and specific. "If things change a lot" is not a trigger. "If metric M crosses V by date D" is.
• Don't overwrite history. The prior verdict and the reason it changed are the point — preserve them.
• Required minimum: datapoint + calendar. Anything less isn't falsifiable.
• Pairs with scenario-branch (its branch triggers become your update conditions) and grade-the-evidence (a trigger firing often raises the tier of a claim, e.g. consensus → measured).