What the doctrine actually requires
The doctrine establishes one central obligation: authority over consequential decisions may not be delegated to an AI system. Governance must be resolved at the commit boundary — the moment before a consequential decision takes effect — by legitimate human authority under enforceable constraints.
This is not a documentation requirement. It is not satisfied by audit trails, explainability tools, or retrospective reporting. The question the doctrine asks is operational and specific: at the moment this decision took effect, who held authority, and could they have changed the outcome?
The anti-theatre tests — one page
These distinguish governance that can refuse from governance that can only explain. Use them as a pre-deployment gate, an audit lens, and an incident triage checklist.
- 1 Jurisdiction at commitment. Can you produce decision-grade evidence of who owned the "yes" at the moment of commitment, under which mandate version, with what constraints, and at what time?
- 2 Time-indexed mandate validity. Does authority remain valid only while its conditions hold? At execution time, can the system resolve who currently holds the mandate, whether the mandate still exists, and whether the context satisfies its constraints?
- 3 Perimeter closure. Can you show that all consequential execution paths traverse the enforcement plane or a declared exception? Any path that bypasses the boundary makes governance incomplete by definition.
- 4 Fail-closed on ambiguity. When authority, context, or constraints are indeterminate, does the system refuse by default — or escalate? Or can uncertainty execute?
- 5 Override accountability. When refusal or escalation is overridden, is the override attributable and evidenced? If that override is itself reversed, can you prove by whom and under what authority?
- 6 Protected intervention under load. What happens to the person who intervenes on a governance concern? If retaliation, career cost, or informal suppression follows, escalation is theatre and drift becomes the stable equilibrium.
What the doctrine does and does not do
The doctrine should be used as
- A reference point for governance, assurance, and accountability discussions
- A boundary-setting instrument during system design, procurement, or deployment
- A citation baseline in audits, reviews, or disputes concerning delegated authority
- A control against authority laundering, responsibility diffusion, or epistemic overreach
The doctrine should not be used as
- A substitute for legal advice, policy drafting, or regulatory interpretation
- A technical specification or system design guide
- A decision-making proxy or justification mechanism
- A rhetorical or persuasive tool detached from its governance purpose
State Zero: the upstream conditions
State Zero-A and State Zero-B, attributed to Toni Scorsese, Ph.D. (Doctrine attribution register), address the human and institutional conditions that must exist before consequential authority can function.
State Zero-B asks whether the person holding authority can perceive the decision environment clearly. A person who inherits a system already shaped by drift may treat the compromised state as the baseline — and be genuinely unable to recognise deviation as deviation.
State Zero-A asks whether intervention is expected and protected in practice — not merely permitted on paper. Where career risk, reputational penalty, or single-gatekeeper escalation suppresses challenge, the formal authority is ornamental.
Together, these frameworks explain why governance that appears complete on paper can fail at the point of consequence. They are applicable at the procurement, design, and operational stages.
Access the full doctrine
AI Non-Delegation Doctrine v2.0 · Frank C. Schouten · 20 March 2026
Publicly available. No account required. Full normative text.