Blast-Radius-Scoped Fail-Closed Autonomy Constitution

Executive Summary

Earning statistical confidence, as described in Claim 54, answers "has this fix worked before." It does not answer "how much damage could this fix do if it is wrong this time." AEGIS answers that second question with a separate, constitutional layer: every candidate remediation is classified ex ante into a blast-radius tier before it is ever eligible to graduate to autonomous execution, and the classification - not the confidence score - sets the ceiling on what the system is structurally permitted to do without a human.

The constitution is fail-closed by design: any action whose blast radius cannot be affirmatively determined is denied autonomous execution outright, never defaulted to allow. On top of the tiered model sits one absolute rule with no statistical exception: any action determined to affect blockchain consensus state is categorically excluded from autonomous execution, independent of how many times it has succeeded before.

Problem Statement

Confidence-based automation gates answer "is this fix statistically reliable," which is necessary but not sufficient. A fix can be reliable in 999 out of 1,000 cases and still be catastrophic in the thousandth, particularly for actions with a wide potential blast radius. Most automation frameworks conflate "how often does this work" with "how much should we let this touch," collapsing both into a single approval decision.

Why Existing Solutions Are Insufficient

• RBAC / IAM policy engines: Permission is granted by role or resource type, not by the consequence class of the specific action being taken - a role with "restart service" permission has that permission for every service, regardless of blast radius.
• Kubernetes admission controllers: Enforce binary allow/deny per resource kind or namespace; there is no graduated three-tier impact taxonomy, and no structural carve-out specific to consensus-critical state.
• Generic circuit-breaker / kill-switch patterns: Stop cascading failure after it starts, but do not classify a candidate action's blast radius before it is ever attempted.
• Single-tier auto/manual runbook gates: Treat "automate this" as one decision with one ceiling, rather than layering a statistical confidence gate underneath a separate, harder constitutional ceiling.

Technical Architecture

Blast-Radius Tiers

Fail-Closed Classification

Classification happens before authorization is even consulted. If the classifier cannot map a candidate action to a known blast-radius tier - because it targets an unfamiliar resource type, or its downstream effects are not modeled - the constitution denies autonomous execution by default. There is no "unclassified, therefore permitted" path anywhere in the authorization flow.

Consensus-Safety Carve-Out

Actions that touch blockchain consensus state are identified independently of the general blast-radius classifier and hard-excluded from autonomous execution as a constitutional rule, not a confidence threshold. This carve-out cannot be satisfied by any amount of accumulated confirmed-success history under Claim 54, and complements the live quorum-safety gate described in Claim 66, which additionally constrains fleet-tier actions that are authorized but could still endanger validator quorum.

Static Baseline vs. Dynamic Reclassification

The blast-radius tier described here is assigned per action type as a static baseline. Claim 60 extends this constitution with a dynamic reclassification rule: when the same fault signature is observed matching across a large share of the fleet simultaneously, actions that would individually classify as contained or node-or-cell are reclassified upward into a fleet-scoped response in real time, suppressing what would otherwise be many independently-authorized autonomous actions.

Prior Art Differentiation

Patent Claim