negative-results-ledger
Dead ends are expensive knowledge — burying them buys the same failure twice. The contract:
every abandoned approach leaves at least one line — what was tried, why it died, where
the evidence is — in a place the next person (or the same person, six months later) will
actually search. And a rigorous negative result is promoted, not just logged: infeasibility
with evidence can be a primary finding.
When to use
- An approach is being abandoned — algorithmic idea, modeling variant, tooling attempt,
data source that didn't pan out.
- A run produced a negative/null/infeasible outcome and someone is tempted to "just not
mention it".
- Before starting something that feels familiar: check the ledger first.
- Pre-paper sweep: which dead ends belong in the text (limitations, "we also tried")?
When NOT to use
- Bugs — a broken implementation is fixed or filed, not memorialized as a negative result.
Only record it here if the approach itself was abandoned because of what the bug
revealed.
- Deferred-not-dead ideas — those are
decision-log entries with status deferred.
- Every failed exploratory cell in a notebook — the ledger records abandoned directions,
not every red cell on the way.
The ledger
A single tracked file (recommended: docs/negative_results.md), newest first, one line per
entry — with a link when evidence exists:
- YYYY-MM-DD — **<what was tried>**: <why it died — one clause>. Evidence: <link or "none, reasoning only">. See D<NN> if a decision was involved.
The bar for an entry is deliberately low (one line, ≤30 seconds); the bar for skipping one
is high — "too minor to record" is how the same dead end gets re-explored quarterly.
Escalation ladder (one line is the floor, not the ceiling)
- One-liner (default) — the ledger line above.
- Rejected decision — the dead end settled a real design question →
decision-log
entry with status rejected; the ledger line points to it.
- Build-log entry — the failure came from a real campaign with numbers → the evidence
and its interpretation get a
build-log entry (write-once, citable), and the ledger line
points to it.
- Primary finding — the negative result answers the research question (an
infeasibility that proves a constraint is binding, a null that kills a hypothesized
effect). Treat it as a first-class result: full evidence chain, statistical treatment,
pre-registered branch honored (
evidence-convention), and a place in the paper.
Rules
- Never soften, never bury. Recording a negative result verbatim is a norm the
phase-gate enforces (a rigorous negative is a valid closure artifact); deleting a
failed branch without a ledger line is the violation.
- "Didn't work" needs one clause of why. "Too slow at realistic sizes", "assumption
X false in our data", "upstream data unusable" — the why is what prevents the re-attempt,
and it distinguishes abandoned from abandoned prematurely.
- Date everything. A dead end from an old code era may deserve a revisit; the date is
what makes that judgment possible.
- Check before you start. The ledger is read at idea-triage time
(the idea lifecycle: probe → adopt → retire) — a hit does not forbid retrying, it demands
engaging with why it died last time.
- Negative results are publishable material. The limitations section, the "approaches
we ruled out" paragraph, and sometimes the headline finding come straight from this
ledger — keep entries paper-quality honest.
Configuration
{{decision_log}}, {{build_log_dir}}, {{evidence_dir}} — escalation targets.
Provenance & maintenance
Authored from the research-hygiene canon (file-drawer effect countermeasures, tried-and-
failed registries), grounded in working practice: a decision log with an explicit rejected
status kept in place rather than deleted, infeasible cells recorded verbatim as data, and a
pre-registered infeasibility branch that fired and was promoted to the project's primary
finding rather than smoothed away. See the pack's examples/ directory for the worked
exemplar mapping.
Re-verify in your project:
test -f docs/negative_results.md && head -5 docs/negative_results.md — the ledger
exists and is current (adapt the path).grep -c "rejected" {{decision_log}} — rejected decisions are recorded, not deleted.- Ask "what did we abandon this quarter?" — if the answer is from memory rather than the
ledger, the discipline has lapsed.
1---2name: negative-results-ledger3description: Use when an idea, approach, or experiment fails, dead-ends, or gets abandoned — recording it in one line so it is never re-attempted from scratch and never silently buried. Also use when a negative or infeasibility result might itself be a finding, and when auditing a project for unrecorded dead ends. Trigger phrases: "that didn't work", "abandon this approach", "record the dead end", "why didn't we try X" , "we tried that before", "the result was negative".4---56# negative-results-ledger78Dead ends are expensive knowledge — burying them buys the same failure twice. The contract:9**every abandoned approach leaves at least one line** — what was tried, why it died, where10the evidence is — in a place the next person (or the same person, six months later) will11actually search. And a *rigorous* negative result is promoted, not just logged: infeasibility12with evidence can be a primary finding.1314## When to use1516- An approach is being abandoned — algorithmic idea, modeling variant, tooling attempt,17 data source that didn't pan out.18- A run produced a negative/null/infeasible outcome and someone is tempted to "just not19 mention it".20- Before starting something that feels familiar: check the ledger first.21- Pre-paper sweep: which dead ends belong in the text (limitations, "we also tried")?2223## When NOT to use2425- Bugs — a broken implementation is fixed or filed, not memorialized as a negative result.26 Only record it here if the *approach itself* was abandoned because of what the bug27 revealed.28- Deferred-not-dead ideas — those are `decision-log` entries with status `deferred`.29- Every failed exploratory cell in a notebook — the ledger records abandoned *directions*,30 not every red cell on the way.3132## The ledger3334A single tracked file (recommended: `docs/negative_results.md`), newest first, one line per35entry — with a link when evidence exists:3637```markdown38- YYYY-MM-DD — **<what was tried>**: <why it died — one clause>. Evidence: <link or "none, reasoning only">. See D<NN> if a decision was involved.39```4041The bar for an entry is deliberately low (one line, ≤30 seconds); the bar for *skipping* one42is high — "too minor to record" is how the same dead end gets re-explored quarterly.4344## Escalation ladder (one line is the floor, not the ceiling)45461. **One-liner** (default) — the ledger line above.472. **Rejected decision** — the dead end settled a real design question → `decision-log`48 entry with status `rejected`; the ledger line points to it.493. **Build-log entry** — the failure came from a real campaign with numbers → the evidence50 and its interpretation get a `build-log` entry (write-once, citable), and the ledger line51 points to it.524. **Primary finding** — the negative result *answers the research question* (an53 infeasibility that proves a constraint is binding, a null that kills a hypothesized54 effect). Treat it as a first-class result: full evidence chain, statistical treatment,55 pre-registered branch honored (`evidence-convention`), and a place in the paper.5657## Rules58591. **Never soften, never bury.** Recording a negative result verbatim is a norm the60 `phase-gate` enforces (a rigorous negative is a valid closure artifact); deleting a61 failed branch without a ledger line is the violation.622. **"Didn't work" needs one clause of *why*.** "Too slow at realistic sizes", "assumption63 X false in our data", "upstream data unusable" — the why is what prevents the re-attempt,64 and it distinguishes *abandoned* from *abandoned prematurely*.653. **Date everything.** A dead end from an old code era may deserve a revisit; the date is66 what makes that judgment possible.674. **Check before you start.** The ledger is read at idea-triage time68 (the idea lifecycle: probe → adopt → retire) — a hit does not forbid retrying, it demands69 engaging with why it died last time.705. **Negative results are publishable material.** The limitations section, the "approaches71 we ruled out" paragraph, and sometimes the headline finding come straight from this72 ledger — keep entries paper-quality honest.7374## Configuration7576- `{{decision_log}}`, `{{build_log_dir}}`, `{{evidence_dir}}` — escalation targets.7778## Provenance & maintenance7980Authored from the research-hygiene canon (file-drawer effect countermeasures, tried-and-81failed registries), grounded in working practice: a decision log with an explicit `rejected`82status kept in place rather than deleted, infeasible cells recorded verbatim as data, and a83pre-registered infeasibility branch that fired and was promoted to the project's primary84finding rather than smoothed away. See the pack's `examples/` directory for the worked85exemplar mapping.8687Re-verify in your project:8889- `test -f docs/negative_results.md && head -5 docs/negative_results.md` — the ledger90 exists and is current (adapt the path).91- `grep -c "rejected" {{decision_log}}` — rejected decisions are recorded, not deleted.92- Ask "what did we abandon this quarter?" — if the answer is from memory rather than the93 ledger, the discipline has lapsed.
huguryildiz