Remediation & Human-in-the-Loop

Why PulseServe proposes fixes but never executes them without a human confirming.

PulseServe's automation runs as a four-phase pipeline — correlation, triage, root cause analysis, then remediation — and each phase commits its own result as it completes, so a reviewer sees findings land in real time instead of waiting for the whole pipeline to finish.

The Remediation Agent takes the incident, the RCA output, and similar past resolutions, and proposes an ordered list of steps. Each step comes with a rationale, an estimated blast radius, whether it is rollback-safe, and whether it requires a formal change ticket. Execution configs can target shell, Ansible, or Terraform — but PulseServe never runs any of them on its own. An operator confirms every step before it executes.

How the gates are enforced

That "confirm before execute" behavior is enforced by configurable HITL gates, not just convention: RCA will not run until enrichment confidence clears a minimum threshold; remediation will not be proposed unless RCA confidence clears a higher one; and any incident whose blast radius exceeds a configured number of CIs, or whose RCA confidence falls below a configured floor, is routed to a human review queue regardless of how automated the rest of the pipeline was.

Executing a step that needs a change ticket, or that carries high blast radius, additionally requires an approved (or CAB-approved) linked Change record when running in live mode. Every executed step supports rollback and cancel.

Cascade auto-escalation

If two or more incidents are firing from the same blast-radius group, PulseServe auto-escalates the group to critical; at three or more, it is treated as a major incident. That escalation changes urgency, not authority — remediation still waits for a person.

Approving, rejecting, or refining a plan

When HITL rules trigger, an incident enters an awaiting-review state and the review controls appear inside its AI Analytics tab, alongside the RCA and remediation plan you're reviewing. From there, decide:

  • Approve — moves the incident to completed. The approved RCA is stored so future analyses learn from it.
  • Reject — enter a detailed reason and pick a feedback signal (e.g. wrong cause, wrong steps). The incident moves to failed and the rejection is stored as a negative training signal, not just discarded.
  • Refine — describe what the AI got wrong or what context it was missing. The pipeline re-runs with your feedback injected into the RCA prompt, and a new result appears for you to review again.

Example

RCA on an "authentication service returning 500 errors" incident comes back with "load balancer misconfiguration" at 58% confidence (amber) — but the analyst's own logs point to an expired certificate instead. Clicking Refine with "the certificate for the auth service expired two hours ago — refocus on the certificate chain" triggers a re-run, and the new RCA correctly identifies the expired certificate. The analyst reviews the corrected plan and approves it.