This entry is unlike the others: it never ran. A proposal I made and rather liked was overturned from three separate angles before anything was built, and archived. Cost: $0. What is recorded here is not a strategy — it is a process.
| Unrecorded | Recorded |
|---|---|
| the same idea resurfaces in three months | look it up, see why it was rejected |
| "I think we decided against it, cannot remember why" | three reasons in writing |
| the review process's contribution is invisible | you can see what it stopped |
The third row matters most. Successful risk control is invisible — its output is a loss that did not happen, and things that did not happen do not appear on a ledger. Without deliberately recording them, the process starts to look like overhead.
The point of adversarial review is not "find someone to look at it" but attacking from different angles separately, because different angles see different kinds of fault and passing one implies nothing about the others:
| Angle | Asks |
|---|---|
| Correctness | does the reasoning hold? is the denominator right? is that causal link in the source or did you join it? |
| Cost | after fees, spread and slippage, what is left? |
| Executability | is there size? can the data be obtained? can the tooling perform the action? |
This proposal failed all three. Three independent negatives leaves no room for "let me adjust it and try again".
When you propose something you assume it is right and go looking for support — and support will always be found with enough data. So "I found supporting evidence" carries no information: it is equally true of sound and unsound proposals.
Adversarial review inverts the default: assume it does not hold unless it survives an attack. The reviewer's task is not "evaluate this proposal" but "find why it does not work".
With one accompanying rule: "cannot be shown" counts as overturned. The burden sits with the proposer — because where money is concerned, an unproven proposal and a wrong one have identical consequences.
To be explicit: the content of the proposal is not published.
Not because it is valuable — it was overturned from three angles. Because a kill is not a declassification: the signal reasoning, selection logic and data usage it involved are shared with lines still under test.
The rule on this site: a kill unlocks the money, the discipline, the engineering and the bases — it does not unlock the ideas. Fortunately nothing this entry has to say needs a single detail of that proposal.
Working alone and unable to genuinely split roles, these approximate most of the effect:
| Approach | Why it works |
|---|---|
| Sleep on it | time partially simulates "a different person" |
| Force three written objections | failing to reach three means you have not seriously considered being wrong |
| Cost first, upside last | a great many proposals die at the cost calculation |
| Check executability early | is there size? can the tooling do this action? |
| Write "how it will die" first | if you can list five ways, reconsider starting |
The order of rows three and four is deliberate: compute cost and executability first, and look at upside last. Reversed, you get attracted by the upside and then unconsciously go easy on the cost estimate.
This entry cost $0 and its output is a road not taken. Successful risk control is invisible, so it needs a headstone of its own — otherwise you will eventually decide the process is overhead and remove it.