← all hypothesesPostmortem Action-Item Pre-Send Gate for Incident Leads
ranked [TRIANGULATED] filter 8.0/15 spread ±1.0 signals: 2 independent
What is this?
Incident leads at 50-300 engineer SaaS companies run postmortems where the team commits to action items meant to prevent recurrence. Lived reality: most action items are symptom-treating ('add more logging'), under-specified ('improve runbook'), or correct-in-spirit but lacking falsifiers. 60-90 days later, similar incidents recur and the lead has no signal on which classes of action items actually held. The product is a pre-commit gate: before each action item is locked into the postmortem doc, the lead pastes it in and the gate runs an adversarial interrogation — what would falsify 'this prevents recurrence', what independent signal proves root cause vs. symptom, what is the 30/60/90-day check, what specific incident class would refute it. Manual entry per item; no doc scraping. The lead's chosen resolution events are then tracked against incident-tracker ground truth. AE's adversarial multi-model debate runs the interrogation; the ten-module behavioral contracts shape each round; PagerDuty/Incident.io/Jira hold the truth.
Why did we consider it?
Every postmortem tool tracks action items after they're written; AE gates them before commit, turning unfalsifiable promises into graded resolution events using machinery incumbents can't replicate.
What breaks?
- Misdiagnosed root cause: Industry data shows action items fail due to lack of ownership and prioritization, not lack of epistemological rigor.
- Fatal workflow friction: Engineers will reject a manual copy-paste interrogation gate that prolongs already exhausting postmortem meetings.
- Infosec/Integration blocker: Tracking ground truth requires deep Jira/PagerDuty integrations, triggering enterprise security reviews a part-time solo founder cannot easily pass.
What did we learn?
Still in evaluation (phase: ranked). No verdict yet.
Filter scores
Five axes, each scored 0-3. Three independent runs by different model perspectives. Median shown.
| Axis | What it measures |
|---|
| data moat | Does this product accumulate proprietary data that compounds? |
| 10x model test | Does a better model make this more valuable, or redundant? |
| fast feedback loops | Can outputs be graded against reality in <30 days? |
| solo founder feasible | Can a solo operator build and run this without a team? |
| AI providers cant eat it | Do hyperscalers have structural reasons NOT to build this? |
Composite median: 8.0 / 15. Graduation threshold: 9.0. IQR across runs: 1.0.
Evidence
Signal B — Competitor with documented gap
incident.io helps teams 'track action items to prevent recurrence' — it addresses action-item completion tracking but has no pre-commit quality gate that adversarially interrogates whether each item addresses root cause vs. symptom, includes falsifiers, or specifies 30/60/90-day verification criteria before the item is locked in.
Signal D — Demand proxy
{"found":true,"summary":"A Reddit r/devops thread directly asks 'What actually happens to postmortem action items after...' — indicating practitioners actively questioning whether action items deliver on their promise. Google's SRE Workbook documents that 'action items from postmortems are often forgotten, resulting in outages,' confirming the systemic failure mode the hypothesis targets. A Hacker News discussion on the Cloudflare outage postmortem shows ongoing community scrutiny of postmortem quality and follow-through.","sources":["https://www.reddit.com/r/devops/comments/1q30bt7/what_actua…
Evaluation history
| When | Stage | Phase |
|---|
| 2026-05-09 07:12 | filter_score | scored |
| 2026-05-09 07:06 | filter_score | scored |
| 2026-05-09 07:00 | filter_score | scored |
| 2026-05-09 06:55 | evidence_search | argument |
| 2026-05-09 06:48 | audience_simulation | argument |
| 2026-05-09 06:42 | red_team_kill | argument |
| 2026-05-09 06:38 | steelman | argument |
| 2026-05-08 20:53 | genesis | argument |