Design decision: our generator would rather say TODO than make things up

Thu Aug 27 2026 · engineering · RSS

A postmortem document has unusual failure economics. In code generation, a hallucinated line fails visibly at runtime. In prose, a confidently wrong root cause succeeds rhetorically while being false — it survives review because it sounds complete, then misdirects months of prevention work.

Three honesty rails we refuse to remove

1. Input-boundedness. The system prompt constrains the writer to facts present in input. No inferring impact metrics, no plausible "likely triggered by", no filling durations from priors. Where information is missing the output contains explicit TODO markers addressed to a named role in review — turning unknowns into assigned follow-ups instead of fiction.

2. Hedged causality. Users give best guesses. Those enter verbatim as "working hypothesis," hedged appropriately unless verified. A chain may express uncertainty up its whole length; that's correct behavior for unverified territory and reviewers learn to treat hedge-free text as a red flag.

3. Structural blamelessness. Names become roles at generation time regardless of input phrasing. "Dave deployed Friday" becomes "deploy automation permitted an unsafe window." This is enforced in the document contract, not begged for in instructions — culture doesn't survive politeness requests; it survives format constraints.

The tradeoff we accept

Honesty rails mean more visible TODOs than tools that optimize for confident polish. We think that's correct: the document's job is to generate questions in review, and a page of crisp unknowns beats a page of fluent invention. If you want confident narratives, any general-purpose model will serve them. If you want documents that survive contact with reality, the rails are the product.