Goal
A Radical Pipelines review phase should not approve an artifact whose correctness depends on a risk that is merely hedged ("likely neutralized", "probably fine", "should be safe") and left unverified. Before approval, such a risk must be resolved one of three ways: verified and closed, sent back to the writer to close, or explicitly recorded as an accepted residual with a stated justification for why it is acceptable. The aim is to catch load-bearing gaps at review time instead of letting them surface in a later phase and force a costly fork/backtrack.
Context
Observed during a design-doc review (BILLOW-69, the WooCommerce pipeline). The design doc flagged a correctness-relevant risk — a spurious cart "quantity changed" notice from the optimistic-update path — as "a known risk the implementation must test… likely neutralized for the main consumers." The design-doc-reviewer approved the doc with that hedge intact. The hedge was demonstrably false: the notice did reach two consumers (saved-for-later and wishlist), which do not suppress it. The gap only surfaced in the code phase, when a regression test proved the notice fired — forcing a fork to a new pipeline version (v5) to revise the already-approved design and re-run the plan and code phases. A review that pushed on the word "likely" — requiring the claim to be verified, or the risk to be explicitly accepted with justification — would have caught it at the design stage and avoided the backtrack.
The reviewer agents already review adversarially and catch many real issues (in the same pipeline, the design review correctly caught an internal contradiction and a wrong file path). This is about closing one specific, recurring failure mode: approving around an unverified hedge on a load-bearing claim instead of forcing it to resolution.
Assumptions / directions to explore
- Likely a change to the reviewer agents' instructions — the design-doc-reviewer at minimum, and plausibly the spec/plan/code/doc reviewers, since the discipline is general: treat an unverified hedge on a correctness-relevant claim as a rejection trigger unless it is recharacterized as an explicitly accepted residual with justification.
- Could be expressed as a concrete review checklist item — e.g. "scan for 'likely / should / probably / assume' attached to any claim the artifact's correctness depends on; each must be verified, sent back to close, or justified-and-accepted."
- A risk genuinely deferred to a later phase should name what will verify it there and why deferral is safe, so a deferred risk is a deliberate, justified decision rather than a hedge that slipped through.
Goal
A Radical Pipelines review phase should not approve an artifact whose correctness depends on a risk that is merely hedged ("likely neutralized", "probably fine", "should be safe") and left unverified. Before approval, such a risk must be resolved one of three ways: verified and closed, sent back to the writer to close, or explicitly recorded as an accepted residual with a stated justification for why it is acceptable. The aim is to catch load-bearing gaps at review time instead of letting them surface in a later phase and force a costly fork/backtrack.
Context
Observed during a design-doc review (BILLOW-69, the WooCommerce pipeline). The design doc flagged a correctness-relevant risk — a spurious cart "quantity changed" notice from the optimistic-update path — as "a known risk the implementation must test… likely neutralized for the main consumers." The design-doc-reviewer approved the doc with that hedge intact. The hedge was demonstrably false: the notice did reach two consumers (saved-for-later and wishlist), which do not suppress it. The gap only surfaced in the code phase, when a regression test proved the notice fired — forcing a fork to a new pipeline version (v5) to revise the already-approved design and re-run the plan and code phases. A review that pushed on the word "likely" — requiring the claim to be verified, or the risk to be explicitly accepted with justification — would have caught it at the design stage and avoided the backtrack.
The reviewer agents already review adversarially and catch many real issues (in the same pipeline, the design review correctly caught an internal contradiction and a wrong file path). This is about closing one specific, recurring failure mode: approving around an unverified hedge on a load-bearing claim instead of forcing it to resolution.
Assumptions / directions to explore