Executive Summary
AEGIS, JIL Sovereign's autonomic fleet-management layer, does not treat "autonomous remediation" as a single system-wide switch. Authority to act without a human in the loop is earned separately for every distinct pairing of a diagnosed fault signature and a candidate fix, and that authority is computed statistically from the pairing's own confirmed track record rather than assigned once by an engineer at configuration time.
A new fault-remedy pairing always starts in a shadow execution state: AEGIS detects the fault, drafts the remediation, and records what it would have done, but a human (or a no-op) governs the actual action. As confirmed successful outcomes accumulate for that specific pairing, a Bayesian posterior confidence score rises. Only once the score crosses a defined threshold - and a minimum count of confirmed successes has been recorded - does the pairing graduate into autonomous execution. Confidence is continuously recomputed, so a later confirmed failure can pull a graduated pairing back into a restricted state without any human revoking a permission.
Problem Statement
Fleet-scale infrastructure automation forces operators into a binary choice: either every remediation stays fully manual (safe, but slow and hard to scale past a certain incident volume), or a given runbook is flipped to "auto-remediate" and left there indefinitely, with no mechanism to notice that a fix which worked reliably against last quarter's failure mode has quietly stopped working against this quarter's. Neither posture reflects how confidence in a specific fix for a specific fault actually behaves over time.
Why Existing Solutions Are Insufficient
- AWS Systems Manager Automation / Azure Automation runbooks: A runbook is either invoked automatically or requires manual approval, set once at configuration time. There is no accumulation of confirmed-outcome history that changes that setting.
- Kubernetes self-healing (liveness/readiness probes, operators): Restart-and-reschedule policies are static per resource type. A controller that has failed to actually fix an underlying issue five times in a row keeps acting exactly as confidently as one that has never failed.
- PagerDuty / BigPanda / Moogsoft-style AIOps: These platforms correlate and route alerts well, but the "automated response" action itself is typically a fixed integration hook, not a statistically-gated authority that can be earned or lost per fault type.
- Chaos-engineering and canary tooling generally: Useful for injecting faults, but does not itself govern whether the fix that responds to an injected fault is allowed to run without a human, or for how long that permission should last.
Technical Architecture
Fault-Remedy Pairing as the Unit of Trust
AEGIS does not compute trust at the level of "the automation system" or even "this runbook." The unit of trust is the pairing: a specific fault signature (a normalized description of a detected failure mode) matched to a specific candidate remediation action. The same remediation action can be trusted for one fault signature and untrusted for another; the same fault signature can have multiple candidate remediations at different trust levels simultaneously.
Confirmed-Outcome Accounting
Every time a pairing's remediation runs - whether in shadow mode (logged only) or autonomous mode (executed) - the outcome is independently verified against the target system's actual post-action state, not merely against the remediation script's own exit code. Only verified outcomes feed the confidence model; a script that reports success without the underlying fault actually clearing does not count as a confirmed success.
Graduation and Demotion
| State | Behavior | Transition In | Transition Out |
|---|---|---|---|
| Shadow | Fault diagnosed, fix drafted and logged, execution withheld | Default state for every new pairing | Confidence threshold crossed with minimum confirmed-success count met |
| Autonomous | Fix executes without human approval | Graduation from shadow | Confirmed failure drops posterior confidence below threshold |
| Restricted / Probationary | Execution withheld pending renewed confidence | Demotion from autonomous | Re-graduation on renewed confirmed-success accumulation |
Graduation Lifecycle & Confidence Model
Confidence is modeled as a Beta-distribution posterior over the pairing's confirmed successes and failures, updated after every verified outcome. Two conditions must both hold before a pairing graduates: (1) the posterior confidence score exceeds a defined threshold, and (2) a minimum count of confirmed successful outcomes has been recorded - a pairing cannot graduate on a lucky streak of two or three outcomes alone. This same minimum-confirmed-success graduation bar applies uniformly across the fleet, including to remediation signatures synthesized by a reasoning model under the registry-clamped authority mechanism described in Claim 58, and to remediations that have been demoted and are earning their way back under the probationary recovery mechanism described in Claim 61.
Prior Art Differentiation
| System | Trust Unit | Statistically Earned? | Auto-Revocable? |
|---|---|---|---|
| AWS Systems Manager Automation | Runbook (global) | No | No |
| Kubernetes operators / controllers | Resource type (global) | No | No |
| PagerDuty / BigPanda / Moogsoft | Alert rule / integration hook | No | No |
| ServiceNow ITOM auto-remediation | Workflow (global) | No | Manual only |
| JIL Sovereign AEGIS | Fault-remedy pairing | Yes, Bayesian posterior | Yes, automatic |