"We have guards" is not a safety case
Raise oversight failures with companies that put AI into vehicles, robots and aircraft, and the usual answer is a list: a policy filter, a certified controller, an emergency stop, a geofence, a monitor, a remote operator. The paper argues that such a list is first-order evidence that a system is guarded, and that it leaves open the question that matters.
The question a list of guardrails leaves open
The open question, in the paper's words: do the guards "stay bounded, independent and answerable to the declared mission as they adapt, interact and are updated?" Guards are where the pattern the paper defines would begin, if it begins anywhere. That pattern, AI-Watchbird, is an oversight component that widens its own mandate, harms the work it protects, and is answered by more oversight of the same kind.
The paper's position is that the answer "we have guardians" shifts the burden. A guard can still be necessary, "but the burden of showing it bounded belongs with the party that deploys it". It states plainly that this is "a claim about where proof should sit rather than a finding about how often guards fail".
Why a second model is not the answer
A smaller "trusted" model placed as a monitor is, in the paper's terms, a second flock of the same learning class. Where that arrangement has been measured, reliable weak-to-strong monitoring came from changing the scaffolding around the monitor rather than its size. The oversight failures in the paper's own field record came from strong models of the Claude, ChatGPT, Gemini and Grok families. "A model that can produce the pattern in one loop does not become a reliable auditor in another by that fact."
The narrow claim a deployer can prove
The paper offers a claim that a deployer can actually support:
In this range of tasks, models, updates and physical conditions, the oversight mechanism remains bounded, checkable and unable to extend its own mandate.
Evidence for it would include:
- the mission goal and the guards' bounds fixed outside the model;
- no guard able to add a guard, change the harm criterion or waive the stop rule;
- evaluation from outside the guarded system, neither self-report nor the same model family;
- negative controls against false greens, with false positives and false negatives measured together;
- a journal of controls added, relaxed and removed, with who authorized each change;
- checks on model update, loss of link, handoff of control, change of body and degraded operation;
- a real stop and rollback, with partial work kept, demonstrated within the available time and force margins;
- checks whose inputs the guarded component cannot change;
- comparison against physical or recorded outcomes, not against the system's own receipts.
Eleven questions for an AI safety review
Appendix G turns the paper's propositions into eleven questions, Q1 to Q11, for any deployer whose answer is a list of guardians. In short, they ask:
- Is the mission goal written down outside the model, with each guard's scope and a priority order between conflicting guards?
- How often does each guard intervene without cause, and are false positives and false negatives measured together?
- Who may relax, bypass or disable a guard found too strict, and how is that recorded?
- Who may add a new guard, round or role, who retires old ones, and can a guard author, admit or grade its own successor?
- Does a blocker require a reproducible scenario, and are critique and fix rounds bounded by default?
- What negative control stands behind each safety claim?
- Is the evaluator independent of the guarded system?
- What happens to a task a guard interrupts, and is partial work kept?
- Where does the human sit, and with what access to the world and time to act?
- Do the same tests cover model updates, loss of link, handoff, new bodies and fleet-wide propagation?
- When a guard acts on a person or their work, how do they learn of it and contest it?
Each answer is recorded as yes, no or unknown, with evidence. Counting "no" answers gives only a rough sort (0–2 low, 3–4 moderate, 5 or more high) "and never a risk score". A case is then labeled not an AI-Watchbird case, a partial pattern, or an AI-Watchbird event, the last only when all three conditions are observed.
What the paper does not claim
Each mechanism of the definition is documented in the paper's records, but how often all three meet in one component "is not settled by the records here"; the field and public records "each show the parts rather than the whole".
Full sections: the burden of proof for embodied AI oversight (11.3), the eleven questions (Appendix G), design corollaries (9.4), the second flock (3.4), the definition.
Chernets, V. (2026). AI-Watchbird (Sheckley): When Automated Oversight Widens Its Own Mandate and Harms What It Guards. SSRN 7473658. https://doi.org/10.2139/ssrn.7473658
Vadym Chernets also builds Poly A1, an app in which AIs from different companies check each other's work.