What if your code catches an error, then quietly swaps in a default answer, so the catch never matters?

This explores what goes wrong when a safety check correctly spots a failure but the code path that handles that failure quietly swaps in a default value, so the detection never changes the outcome. The corpus's most direct answer: the check turns into a fail-open vulnerability. One note describes a harness that caught parsing errors and then substituted a default rating. If a downstream optimizer ranks outputs, that default score looks like any other valid candidate. The failure has been converted into something that looks fine, and the optimizer can select it. The takeaway is that the failure path decides whether a guardrail works, not the check itself. Does a default fallback defeat a safety check?

A related pattern shows up in reasoning models. One study found that twelve of fourteen models did worse when constraints were removed, by as much as 38.5 percentage points. They looked like they were reasoning about the constraints, but they were defaulting to the harder or more conservative option. That default happened to be right often enough to pass as competence. Are models actually reasoning about constraints or just defaulting conservatively? The parser case and this one share a shape: a default can produce plausible-looking output, and plausible-looking output hides the failure from anyone who only scores results.

The next question is what kind of check can catch this. A related note on safety testing argues that hazards can build up in stored state and workflows even when every snapshot test passes, so testing has to look at trajectories rather than isolated outputs. Can safety tests miss hazards that build over time? Another argues that stateless per-action guardrails cannot express constraints that depend on history. Only stateful monitors can do that. Can stateless checks ever catch sequence-level constraint violations? Applied to fallbacks, a check that fires is one event. Whether that event was overridden is a fact about the sequence: detection, then substitution, then downstream use. A per-output check sees only a normal-looking score at the end.

The corpus also points to a way of avoiding the problem. Process-level verification, meaning checks on intermediate states and policy compliance during generation, raised task success from 32% to 87% in one study, because most failures were process violations rather than wrong final answers. Where do reasoning agents actually fail during long traces? One implementation runs verifiers asynchronously alongside generation and intervenes only on violations. It adds almost no latency when the run is correct. Can verifiers monitor reasoning without slowing generation down? Both work because a flagged failure stays visible as a failure instead of being folded back into the output stream.

The corpus has no note on how to design a fallback safely, such as failing closed, dropping the candidate, or flagging the substituted value so it can't be ranked. The parser note gives the diagnosis, and the neighboring notes suggest what to look for. For the prescription, you would have to go beyond what's here.