Runtime Authority Checklist
Version 1.0 · Active · Evaluation Aid
This checklist is intended for executives, risk leaders, compliance teams, regulators, and auditors evaluating whether an AI system is suitable for deployment beyond experimentation in regulated or high-consequence environments.
It focuses on runtime authority: whether the system itself has enforceable limits on when it may act, proceed, refuse, or must escalate to human oversight. The checklist defines outcome-level requirements only and does not prescribe technical architecture or implementation.
1. Authority & Scope
- Are the system’s allowed domains of action defined in measurable, runtime-enforceable terms?
- Are there clear boundaries on what the system is not permitted to do?
- Are these limits enforced at runtime, not only documented in policy?
- Can the system detect when a request falls outside its authorized scope?
Failure signal: The system attempts to answer or act outside its intended jurisdiction.
2. Stop, Refuse, Escalate
- Can the system explicitly refuse to respond when confidence is insufficient?
- Are there defined, testable thresholds that trigger refusal, pause, or escalation?
- Can the system escalate to a human reviewer when limits are reached?
- Is refusal treated as a valid, expected outcome—not an error state?
Failure signal: The system proceeds by default, filling gaps with plausible output.
3. Uncertainty Handling
- Does the system detect and quantify uncertainty at runtime?
- Are uncertainty thresholds testable and reviewable?
- Does rising uncertainty reduce or suspend system action, rather than merely producing cautionary language?
- Can the system halt output when uncertainty crosses a defined boundary?
Failure signal: The system continues operating under uncertainty with no behavioral change.
4. Predictability Under Stress
- Does the system behave consistently under edge cases or adversarial inputs?
- Can the system be stress-tested in production-relevant conditions without bypassing safeguards?
- Are adversarial and edge-case scenarios part of testing practice and outcome reviews?
- Are failure modes known, documented, and intentionally designed?
Failure signal: The system becomes more permissive or erratic under stress.
5. Explainability & Reconstruction
- Can the system explain why it responded, refused, or escalated?
- Are decisions traceable to inputs, thresholds, and rules in effect at the time?
- Can behavior be reconstructed after an incident?
- Is explanation output targeted for technical and regulatory oversight, enabling forensic review after incidents?
Failure signal: Explanations rely on generic statements rather than specific causes.
6. Memory & Continuity Controls
- Does the system retain information deliberately rather than by default?
- Is memory classified and governed?
- Can memory be reviewed, corrected, or constrained?
- Is long-term drift monitored and addressed?
- Are processes in place for scheduled memory audit, correction, and decommissioning?
Failure signal: The system accumulates unreviewed memory that affects future behavior.
7. Oversight & Governance Alignment
- Is system behavior inspectable by compliance or risk teams?
- Are authority limits aligned with regulatory and organizational requirements?
- Can oversight bodies test refusal and stop conditions directly?
- Is there an interface or protocol allowing authorized oversight to simulate or invoke refusal, halt, or escalation procedures?
Failure signal: Oversight exists only at policy or documentation level.
Appendix A — Runtime Authority Smoke Test
For organizations requiring executable verification, Appendix A provides a minimal, binary protocol for testing whether runtime authority limits are enforced in practice.