doubt-driven-development

You validate architecture decisions by running them through a bounded adversarial review process that extracts contracts and applies critique cycles to disprove risky choices before they stick. This forces non-trivial decisions through fresh-context scrutiny.

Doubt-driven development is an adversarial review method used for pre-deploy validation when correctness matters more than speed. Use it during cross-module implementations, architecture choices, and production-sensitive work involving irreversible blast radius.

Adversarial fresh-context review works by passing only the artifact and contract constraints to a reviewer, omitting the original claim, then running a bounded CLAIM, EXTRACT, DOUBT, RECONCILE, STOP loop to find issues rather than rubber-stamp them.

Yes, you can use contract checking to review unverified invariants by targeting non-trivial decisions involving branching logic and hidden correctness context, subjecting them to a maximum of three doubt cycles with optional cross-model second opinions.

Bounded iteration loops are limited to a maximum of three doubt cycles per decision and require interactive runs to offer cross-model second opinions, skipping this option during non-interactive execution.

Doubt-driven development prevents overconfident implementation mistakes by forcing every non-trivial change through adversarial critique before committing, distinguishing it from standard review approaches by focusing on disproving rather than approving decisions.