prove-it

Prove It

You proposed the idea; from here on, stop defending it. Switch roles from advocate to experimenter: design an experiment that could kill the idea, run it honestly, and report whichever verdict the evidence supports. "Partially viable" and "not viable — it broke here" are successful outputs of this skill. A proof that cannot fail is not a proof.

The audience for every piece of evidence is the user. Narrative is not evidence. Evidence is anything the user can run, read, or measure without trusting you.

The unit of proof is the claim, not the idea. Keep each proof round self-contained in its own directory, docs/proofs/YYYY-MM-DD-<idea>/: the record is that directory's README.md (created from references/proof-record-template.md), and everything the verdicts point to lives in evidence/ beside it. Successive proofs sit side by side instead of interleaving. Work through the phases in order.

1. Extract the Claims

Decompose the idea into explicit claims and classify each:

• capability — X can be built or done at all.
• quality — X is simpler, faster, safer, or cheaper than the current baseline.
• derivative — X stays good as the system grows or changes: maintainable, scalable, extensible. These are claims about a cost curve, not a point.
• generality — X works beyond the demonstrated case: other domains, stacks, teams.

Mark the killer claims: the ones whose falsity kills the idea. They are usually the derivative and integration claims — the ones the design discussion glossed over. Most ideas have one to three; if every claim looks killer, the decomposition is too coarse.

Present the claim list to the user and confirm the killer set before designing anything. The user knows hostilities you do not.

2. Design the Experiment

Choose the apparatus by evidence strength against the killer claims, never by ease of construction:

• Brownfield retrofit — implement the idea inside an existing real project. Prefer this whenever the idea claims to apply to existing systems: reality supplies legacy constraints, dirty data, and integration friction for free.
• Greenfield build — a new minimal-but-sufficient project. Right for paradigm-level ideas with nothing to retrofit into; hostility must then be manufactured deliberately, or the apparatus slides into a toy.
• Reference problem — implement a well-known non-trivial problem in the new approach. Public recognition of the problem's difficulty prevents cherry-picking.
• Targeted spike or benchmark — when one subproblem carries all the risk, attacking it directly beats building everything around it.