Adversarial Audit · Swan Attack

Verification-Guided Falsification for Safe RL via Explainable Abstraction and Risk-Aware Exploration

Source: arXiv:2506.03469 · Tuan Le, Risal Shefin, Debashis Gupta, Thai Le, Sarra Alqahtani · June 2025
Source: abstract verbatim, emergentmind.com/papers/2506.03469
AUDIT METHOD:
Swan Attack V21.0 adversarial audit — Directed to claim analysis & falsification
LLM: Claude Code (claude-sonnet-4-6 1M) on VSCode
Human Supreme Commander and Chief Skeptical: Donato Marco Mangialardo @donatomm
Date: July 1, 2026
Abstract — verbatim

Ensuring the safety of reinforcement learning (RL) policies in high-stakes environments requires not only formal verification but also interpretability and targeted falsification. While model checking provides formal guarantees, its effectiveness is limited by abstraction quality and the completeness of the underlying trajectory dataset. We propose a hybrid framework that integrates (1) explainability, (2) model checking, and (3) risk-guided falsification to achieve both rigor and coverage. Our approach begins by constructing a human-interpretable abstraction of the RL policy using Comprehensible Abstract Policy Summarization (CAPS). This abstract graph, derived from offline trajectories, is both verifier-friendly, semantically meaningful, and can be used as input to Storm probabilistic model checker to verify satisfaction of temporal safety specifications. If the model checker identifies a violation, it will return an interpretable counterexample trace by which the policy fails the safety requirement. However, if no violation is detected, we cannot conclude satisfaction due to potential limitation in the abstraction and coverage of the offline dataset. In such cases, we estimate associated risk during model checking to guide a falsification strategy that prioritizes searching in high-risk states and regions underrepresented in the trajectory dataset. We further provide PAC-style guarantees on the likelihood of uncovering undetected violations. Finally, we incorporate a lightweight safety shield that switches to a fallback policy at runtime when such a risk exceeds a threshold, facilitating failure mitigation without retraining.

cyan underline — claim extracted for audit orange underline — internal contradiction or self-refutation
Claims under audit — derived from abstract
  1. The framework provides formal safety guarantees for RL in high-stakes environments.
  2. PAC-style guarantees cover the likelihood of finding undetected violations.
  3. This is a framework for safe RL (the fallback shield makes the system safe at runtime).
TL;DR

if no violation is detected, we cannot conclude satisfaction is the sharpest find — the authors concede the core limitation of Claim 1 in the same paragraph that makes it.

Claim 1 of 3
“The framework provides formal safety guarantees for RL in high-stakes environments.”
Guarantee covers the abstraction, not the policy

Formal verification of an incomplete model is not formal verification of the system

The authors say outright: “if no violation is detected, we cannot conclude satisfaction due to potential limitation in the abstraction and coverage of the offline dataset.”

The Storm model checker verifies the CAPS abstract graph — a discrete summary built from offline trajectories. Not the continuous RL policy operating in the real environment. A clean result from the model checker means “the abstraction is safe,” which says nothing about real policy behavior in states the trajectories didn’t cover.

All the “formal rigor” language in the framing is downstream of an abstraction the authors themselves admit may be incomplete. The word formal is doing misleading work.

Claim 2 of 3
“PAC-style guarantees cover the likelihood of finding undetected violations.”
Bounds break in their own featured use case

The math holds; the assumptions don’t

PAC guarantees require approximately i.i.d. sampling with known error bounds. The medical domain they feature — insulin dosing, continuous glucose monitoring — is explicitly flagged in the paper as having “delayed safety effects” that make “reliable abstractions” impossible.

You cannot compute meaningful PAC bounds on violation coverage when the feedback signal is delayed and the abstraction is unreliable. The math is internally consistent; it just doesn’t apply to the problem the paper positions as its primary motivation.

Claim 3 of 3
“This is a framework for safe RL.”
Violation detector with an unverified backup plan

The fallback policy is never itself verified

The runtime shield “switches to a fallback policy when risk exceeds a threshold.” Two problems:

  1. The fallback policy is not verified by this framework. Its safety is assumed, not shown.
  2. The underlying policy is never fixed — only bypassed at runtime.

The framework finds some violations and hands off to an unverified fallback. That is a failure detector with an ejector seat, not a safety guarantor. The title says “safe RL.” What it delivers is “RL with a trip wire.”

Structural problem

The falsification loop is circular

The risk-guided falsification strategy “prioritizes searching in high-risk states and regions underrepresented in the trajectory dataset.” But risk estimates are derived from the same incomplete offline dataset that caused the coverage gap in the first place.

The search finds gaps the risk model already suspected. It cannot find the gaps the risk model didn’t know to look for — which is precisely the class of dangerous failures that matter most in high-stakes RL.

Naming problem

“Verification-guided” is doing a different job than the name implies

“Verification-Guided Falsification” implies the two operations work in tandem. In practice: verification runs first, produces risk estimates when no violations are found, and those estimates guide heuristic search. Verification is functioning as a coverage analyzer, not a verifier. The title names one operation; the method does something adjacent to it.

Summary

The formal guarantee covers an abstraction the authors admit is incomplete. The PAC bounds depend on distributional assumptions that break in the paper’s featured use case. The fallback policy that “ensures safety” is never itself verified. The system doesn’t make an unsafe policy safe — it detects some of its failures, then delegates to something else.