02901dfec7
ADRs: - Update 0008-honor, 0009-courage, 0013-overflow, 0015-plausibility - Add 0017-hosted-coding-assistant-architecture RFCs: - 0032: per-repo AWS profile configuration (draft) - 0033: round-scoped dialogue files (impl + plan) - 0034: comprehensive config architecture (accepted) - 0036: expert output discipline (impl) - 0037: single source protocol authority (draft) - 0038: SDLC workflow discipline (draft) - 0039: ADR architecture greenfield clarifications (impl) - 0040: divorce financial analysis (draft) - 0042: alignment dialogue defensive publication (draft) Spikes: - Read tool token limit on assembled dialogues - RFC ID collision root cause - Expert agent output too long - Judge writes expert outputs - Blue MCP server on superviber infrastructure - Playwright MCP multiple window isolation Dialogues: 16 alignment dialogue records Code: - blue-core: forge module enhancements - blue-mcp: env handlers and server updates - alignment-expert agent improvements - alignment-play skill refinements - install.sh script Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
50 lines
1.7 KiB
Markdown
50 lines
1.7 KiB
Markdown
# ADR 0015: Plausibility
|
||
|
||
| | |
|
||
|---|---|
|
||
| **Status** | Accepted |
|
||
| **Date** | 2026-01-25 |
|
||
|
||
---
|
||
|
||
## Context
|
||
|
||
Most engineering decisions are made in fear of the implausible. We add error handling for errors that won't happen. We build abstractions for flexibility we'll never need. We guard against threats that don't exist.
|
||
|
||
## Decision
|
||
|
||
**Act on the plausible. Ignore the implausible.**
|
||
|
||
1. **Probability matters.** A 0.001% risk does not deserve the same treatment as a 10% risk.
|
||
|
||
2. **Rare failures are acceptable.** A system that fails once per million operations is not broken.
|
||
|
||
3. **Don't guard against fantasy.** If you can't articulate a realistic scenario, remove the guard.
|
||
|
||
4. **Recover over prevent.** For implausible failures, recovery is cheaper than prevention.
|
||
|
||
5. **Trust reasonable assumptions.** "What if the user passes negative infinity?" is not serious if the user is you.
|
||
|
||
## Consequences
|
||
|
||
- Less defensive code
|
||
- Simpler error handling
|
||
- Faster development
|
||
- Occasional rare failures that we fix when they occur
|
||
|
||
## The Calculation
|
||
|
||
```
|
||
Expected Cost = P(failure) × Cost(failure) + P(success) × Cost(prevention)
|
||
```
|
||
|
||
If `P(failure)` is near zero, almost any `Cost(failure)` is acceptable. We waste more engineering time preventing implausible failures than we would spend recovering from them.
|
||
|
||
### When Prevention Cost Approaches Zero
|
||
|
||
If Claude implements, `Cost(prevention)` for code changes approaches zero. The plausibility calculus inverts:
|
||
|
||
- **Previously**: "This edge case is too expensive to handle."
|
||
- **Now**: "This edge case takes Claude 30 seconds. Handle it."
|
||
|
||
But `Cost(judgment)` remains high. The new bottleneck is deciding *whether* to handle the edge case, not *affording* to handle it. See RFC 0039.
|