LZLZL/Prediction markets/Research method
FREEBUILD IT F · MethodFlagship

Kill rules and
pre-claimed failure modes

2026-08-21 · write down how it will die, before it runs

Most strategies are not killed; they are shelved indefinitely — "leave it, we'll look again later". The difference matters: a kill frees your attention and your capital; a shelving does not. Two tools here: what condition stops it, and writing down how it will die before it starts.

1Why you need an explicit stop

No kill ruleWith one
"a bit longer"condition triggers → stop
losses arrive gradually; no moment ever feels like the momentthe moment was defined in advance
sunk cost accumulates, making it harder to stopthe reason to stop is independent of what you have spent
ends in indefinite shelving, holding capital and attentionends archived, in the kill file

The last row is the point. A kill is an output — it becomes a piece of knowledge ("this road is closed") that can be reused, published, and can save someone else the tuition. Shelving produces nothing; it defers the decision to a future you.

2Three kinds of stop condition

TypeTriggerExample
Capitallosses reach an absolute figurestop ordering when the wallet falls below a floor
Futilitypassing is now mathematically impossibleno remaining sample can turn it around
Criteriathe scheduled read misses a gateany of the four gates failing

The second is the valuable one, because it can fire far in advance and save a lot of both. The arithmetic is simple:

how much must the remaining sample average to pass? if that exceeds the theoretical ceiling for a single observation — stop
LineAt the timeRemaining sample would needVerdict
An≈460, excess −1.8pp, gate +4pp~40 observations at +71pp eachabove the ceiling → stop
Bn=2,468, excess +1.56pp, gate 2.25pp32 at +55pp eachimpossible → read

A harder variant states it as a probability: one line needed 87 of its remaining 93 to turn around, which under randomness has probability 8.25 × 10⁻²⁰. That number is the verdict.

3★ Pre-claimed failure modes

The tool I use most, and it is one sentence: before running, write down how this will look if it is wrong.

WithoutWith
look for an explanation when it breaksclaim one from the list: "this is failure mode two"
an explanation always exists, and always sounds reasonablethe explanations were written first and cannot change
so you can always justify one more tryclaiming one means archiving
⚠ Why post-hoc explanation nearly always succeeds

Because there are too many available: sample too small, unusual conditions, parameters untuned, execution issues, bad luck. Any of them might be true, and you will pick the one that lets you continue.

Pre-claiming inverts it: the list of explanations is sealed before you see the result. Something on the list happens → claim it, archive. Something off the list happens → that is genuine new information and worth studying.

It has a side effect too: writing the list often reveals you do not really believe in the line. If five failure modes come easily, reconsider starting.

4⚠ But a number is not a count

An error of my own, worth publishing. Closing one line, I labelled the verdict "final kill, the sixth in its family". It sounds weighty — as though five prior kills were on record.

Checking later: that phrase appears in exactly one place in the entire archive — a single self-declaration at the end of a preregistration, written seven days before the read. Nowhere is there a list of kills one through five.

There genuinely are more than five documented kills, but that is a list reconstructable afterwards, not a count made at the time — so the verdict is rhetoric, not ledger.

Transferable

When a claim carries a number — "the Nth time" — ask whether that N was counted or simply said.

This applies to reading anyone's results. A numbered claim looks audited, readers treat it as audited, and frequently it is not.

5What a kill should leave behind

RecordWhy
What it was betting onso a similar idea later can be matched against it
Criteria and readingsso a reader can judge whether the kill was sound
Which gate it died atno edge? edge too small? eaten by execution? — three different diagnoses
What it costthat is the price of the knowledge
What the ledger did not recordwrite "not recorded" — do not supply a plausible cause afterwards

The last is a hard rule here. One line received $0 of rebates and the ledger did not record why — so the kill file says "no cause recorded" rather than offering a reasonable-sounding one.

6One line to keep

A strategy without a kill rule does not fail; it gets shelved indefinitely — and shelving produces nothing. Write down how it will die before it runs, claim one from the list when it does, and the claim turns it into knowledge somebody else can use.

EvidenceCheck it yourself

Futility stops Line A: n≈460, excess −1.8pp, gate +4pp → ~40 remaining observations would need +71pp each, above the single-observation ceiling. Line B: n=2,468, +1.56pp against a 2.25pp gate → 32 at +55pp each.
Probability form one line required 87 of a remaining 93; under randomness, 8.25×10⁻²⁰.
"Sixth kill" is a self-declaration the phrase occurs once in the archive, in a preregistration written seven days before the read; no list of kills one to five exists.
Rebates $0 with no cause all three ledger references record the result and not the mechanism, which is why this site writes "no cause recorded".
Checked 2026-08.

NextWhere to go

F · METHOD
Gates and the single read
F · METHOD
Adversarial verification
F · METHOD
Preregistration
E · UP/DOWN
What a complete kill file looks like
This is an educational and research record. It is not investment advice, promises no returns, and offers no personalised trading recommendations. Rules and API behaviour are per the official documentation; this page states when it was checked and both can change without notice. Prediction markets are restricted or unavailable in some jurisdictions — confirm your own before taking part.