Remediation under governed authority

ChangeGuard can close the loop on a failure: detect a failing workload, diagnose the root cause, propose a concrete fix, obtain authority for exactly that fix, execute it through a verified Executor under a single-use Permit, verify that it actually worked against fresh evidence, and hand it to a human if it didn’t. Every step is recorded against the change, attributable and visible in the product. It does none of that on its own by default. Every environment starts in Advise: ChangeGuard proposes and waits for a person. Even in Auto it acts only inside an explicit policy, and outside that policy it falls back to Advise. See Advise and Auto.

​

The loop

Three properties of this loop matter more than any individual feature:

1. Nothing executes without a consumed Permit. Judgment proposes; a human or a policy authorizes; the Permit carries that authority to the Executor for one action, once, for minutes. A revoked, expired, replayed or re-proposed change is refused before anything touches the cluster.
2. Every arrow is auditable. Each transition appends an event to an append-only audit trail — the approver or policy version, the Permit, the attempt, the pre-state, the result, the observation.
3. Failure escalates, it never loops. A failed verification or a silent attempt ends with a human in the loop. The system never retries indefinitely, never rolls back a rollback, and never resolves an incident it did not observe recovering.

​

Lifecycle states

Remediations and incidents move through first-class states, so you can filter, alert and reason about them precisely. The product also shows the execution ladder on every record — Permit issued → Execution started → Action applied → Verifying → Verified (or Failed, Rolled back) — and the Permit’s own state: Not issued, Authorized · expires in …, Consumed, Expired, or Revoked · reason.

​

Where to go next