← Back to Patent Claims
Patent Claim 054 All Patents →

Earned-Autonomy Graduation for Machine Self-Remediation

Per-Pairing, Bayesian-Confidence-Gated, Revocable Autonomous-Execution Authority for Infrastructure Self-Healing

Patent Claim JIL Sovereign July 2026 Claim 54 of 157

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.

Core Innovation: Autonomous-execution authority is a statistically-earned, continuously-revocable property of each individual fault-remedy pairing - not a static, human-assigned toggle on the automation system as a whole.

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.

70%
of outages Uptime Institute's annual survey attributes at least partly to human error or process failure
$9,000
widely-cited (Ponemon Institute) estimate of average cost per minute of unplanned downtime
5
confirmed successful outcomes required before AEGIS will graduate any fault-remedy pairing to autonomous execution

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

StateBehaviorTransition InTransition Out
ShadowFault diagnosed, fix drafted and logged, execution withheldDefault state for every new pairingConfidence threshold crossed with minimum confirmed-success count met
AutonomousFix executes without human approvalGraduation from shadowConfirmed failure drops posterior confidence below threshold
Restricted / ProbationaryExecution withheld pending renewed confidenceDemotion from autonomousRe-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.

Confidence model
Beta-posterior over confirmed outcomes
Graduation gate
Threshold AND minimum confirmed-success count
Revocability
Continuous, automatic on confirmed failure
Scope of trust
Per fault-signature / remediation pairing

Prior Art Differentiation

SystemTrust UnitStatistically Earned?Auto-Revocable?
AWS Systems Manager AutomationRunbook (global)NoNo
Kubernetes operators / controllersResource type (global)NoNo
PagerDuty / BigPanda / MoogsoftAlert rule / integration hookNoNo
ServiceNow ITOM auto-remediationWorkflow (global)NoManual only
JIL Sovereign AEGISFault-remedy pairingYes, Bayesian posteriorYes, automatic

Patent Claim

Independent Claim 54: A computer-implemented method for governing autonomous execution authority in a machine self-remediation system, comprising: maintaining, for each pairing of a diagnosed fault signature and a candidate remediation action, a shadow execution state in which the remediation is proposed and logged but withheld from autonomous execution; recording confirmed success or failure outcomes of the remediation across successive occurrences of the fault signature; computing a Bayesian posterior confidence score from the accumulated confirmed outcomes; and transitioning the pairing from the shadow execution state to an autonomous execution state only upon the posterior confidence score exceeding a defined threshold and a minimum count of confirmed successful outcomes having been recorded, wherein the transitioned state remains revocable and is automatically returned to a restricted state upon subsequent confirmed failure.