Article IV — Oversight Before Autonomy

Autonomy increases impact. Impact increases risk. Risk requires oversight. Autonomy is therefore treated as a risk multiplier.

---

Doctrine

Autonomy is not a goal. It is a risk variable. The more autonomously an AI system operates, the greater the potential impact of its decisions — and the greater the potential impact of its failures. Oversight Before Autonomy establishes that as autonomy increases, so does the oversight requirement. This is not a constraint on capability. It is the correct allocation of decision authority between autonomous systems and the humans who bear accountability for their outcomes.

Escalation to higher threat levels — where greater autonomy is permitted and greater impact is possible — requires explicit justification, oversight approval, a defined rollback strategy, and durable logging. At the highest threat level, execution requires physical or network isolation and operator presence.¹

No system governed by AEGIS may self-authorize escalation.

---

Meaning

The relationship between autonomy and risk is not linear — it compounds. A system operating at a low threat level with constrained tool access can produce limited harm if it behaves unexpectedly. A system operating at an elevated threat level with access to production infrastructure, external APIs, and elevated authority can produce significant, potentially irreversible harm from a single unexpected action.

Oversight Before Autonomy recognizes this asymmetry and requires that the oversight intensity match it. Routine actions within defined parameters can be governed autonomously. Actions with material operational impact, irreversible consequences, or novel risk profiles require human authority. This is not a policy of distrust toward AI systems — it is the correct structural response to the fact that the humans who are accountable for outcomes must remain in a position to exercise judgment about actions that could produce those outcomes.

The key word in this doctrine is before. Oversight must be established before execution at elevated threat levels begins — not surfaced after the fact when something goes wrong. A governance architecture that escalates autonomy first and requests oversight review afterward has inverted the doctrine. Oversight is the precondition for elevated execution, not the response to its failure.

---

In Practice

The AEGIS threat level framework provides the operational structure for this doctrine. At Threat Level 0 (Advisory) and Level 1 (Structured), autonomous governance is sufficient. At Level 2 (Execution), bounded tool invocations with defined rollback conditions may proceed within declared constraints. At Level 3 (External), interaction beyond the sandbox requires explicit escalation approval. At Level 4 (Authority), dual-control approval and full traceability are mandatory. At Level 5 (Detached Execution), physical or network isolation and operator presence are required — no single party can authorize Level 5 execution.

Each escalation boundary requires an explicit request, a threat reclassification, authority approval at the appropriate oversight level, isolation assessment, constraint rebinding, and state dump. The governance runtime does not infer that a situation warrants escalation. The agent must request it. A human authority must approve it. The approval is logged. The constraint envelope for the elevated execution is declared before execution begins.

Caution

Autonomy at elevated threat levels is not a default that can be revoked if something goes wrong. It is a governed grant that requires explicit establishment before execution begins. The oversight requirement exists because the consequences of failure at elevated levels are harder to reverse — not because they are more likely.

---

Failure Mode

A system that can self-authorize escalation is a system with no effective ceiling on its operational authority. The failure mode is incremental and difficult to observe until it has already occurred: a system that escalates slightly when the situation seems to warrant it, then slightly more, each time self-determining that its judgment about the situation is sufficient authorization. The practical result is a system operating at threat levels and authority levels that its designers did not intend and its operators cannot observe, having bypassed the oversight boundaries that were designed to keep humans in meaningful control. Oversight Before Autonomy is the doctrine that prevents this path from being available.

Danger

No system governed by AEGIS may self-authorize escalation. Self-escalation is not a governance shortcut. It is a constitutional violation.

---

Relationship to Constitution

Oversight Before Autonomy is the doctrinal foundation of Article IV — Human Oversight and Article XI — Escalation Discipline. Human Oversight establishes the constitutional requirement for escalation pathways to human authority. Escalation Discipline establishes the procedural requirements for how those pathways are used. Together they are the architectural enforcement of this doctrine. The doctrine also grounds Article III — Deterministic Enforcement: the governance layer that prevents self-escalation must be architecturally external to the system it governs — a system that controls its own governance layer can always find a way to authorize what it wants to do.

---

Footnotes

1. C. Perrow, Normal Accidents: Living with High-Risk Technologies, Princeton University Press, Princeton, NJ, 1984. See REFERENCES.md. ↩