These are the questions I ask of any claim that an AI system is safe enough to use where a mistake could cause physical harm. None of them is new. Safety engineers asked versions of all five long before machine learning. AI makes each one harder to answer. They come from the research for *[Safe Enough](/safe-enough)*, and every case in the book is tested against them. [Download the field card (PDF)](/assets/five-questions-card.pdf) ## 1. What would change your mind? Ask what evidence would lead the people responsible to restrict or withdraw the system. If nothing would, the claim of safety is a belief rather than a finding. A useful answer names a measure, a threshold, and who is watching it. ## 2. Who checks the machine after it changes? The system that was evaluated is not automatically the system in service. Models are retrained, recalibrated, reconfigured, and updated, and the data they see drifts. Ask what triggers a fresh assessment, and who decides that a change is small enough not to need one. ## 3. What happens when they all fail at once? Safety engineering has long worried about common-mode failure: a single fault that defeats several safeguards together. A fleet that shares one model, one data feed, or one cloud service can turn a single error into many simultaneous ones. Ask what is shared, and what happens when it goes. ## 4. Who answers when it goes wrong? Follow the chain of accountability from the developer to the operator, the regulator, and the person on shift. Ask who can stop the system, who must report an incident, and who carries the consequences. A gap in that chain is a hazard in its own right. ## 5. Who is your strongest opponent? Every serious safety claim has informed critics. Ask who they are, what their best argument is, and whether it has been answered or avoided. If nobody can name a credible opponent, the case has probably not been tested. ## How to use them Use the questions before agreeing that a system is ready, when reviewing a supplier's claims, and whenever a deployment changes. They work best as openers for a conversation with the people who hold the evidence. For each question, record whether the answer is evidence, silence, or uncertainty. All three are informative. ## What they are not The Five Questions are a decision lens. They are not a certification scheme, an audit, legal advice, or a safety guarantee, and using them does not make a system compliant with any standard. They do not replace the standards that apply in each domain, such as DO-178C, ISO 26262, IEC 62304, or EN 50128. This is personal research, separate from my work at QA-Systems. I do not certify systems through this framework, a talk, or a workshop. ## Version **Version 1.0** — 22 October 2026. First public version. You are welcome to share the questions and the field card, with attribution. For use in teaching or inside an organisation, or to suggest an improvement, please [get in touch](/contact).