Integrations

Governed Incident Response with Perplexity and PagerDuty

Introduction

Perplexity Sonar can research and propose answers. PagerDuty can alert and escalate. Neither product, by itself, produces a compliance-grade record of what the AI did, what sources it used, and who approved the next action. Loop Engine closes that gap: you model the flow as explicit states and transitions, attach evidence at each step, and only then hand off to PagerDuty when policy allows.

The architecture is linear: Perplexity Sonar supplies grounded text and citations; Loop Engine runs a finite-state loop (for example a governed-incident-response definition) with guards and human gates; PagerDuty receives Events API v2 triggers when the loop reaches an alerting state. The audit trail is written from the loop side — one entry per material step, with hashes and references you can tie back to incidents.

Architecture

1                    ┌── audit trail (tamper-evident entries per step)
2                    │
3Perplexity Sonar ──►│  Loop Engine — governed-incident-response FSM
4                    │
5                    └──► PagerDuty (Events API v2 — trigger / dedupe / custom_details)

The governed-incident-response loop

The catalog id gov.governed-incident-response (version 0.1.0) uses the following state set and transitions. Your runtime should register the definition and drive transitions through the same actor boundaries.

States

1[
2  "idle",
3  "researching",
4  "classifying",
5  "auto_approving",
6  "human_review",
7  "escalating",
8  "alerting",
9  "complete",
10  "rejected",
11  "blocked",
12  "failed"
13]

Key states (annotated)

| State | Role | | --- | --- | | researching | Sonar call with domain filter and citation requirement (unless you pre-seed citations and skip research). | | classifying | Derive risk tier from Sonar output — typically LOW, HIGH, or BLOCKED. | | human_review | Configurable gate; timeout paths can escalate through PagerDuty or move to escalating. | | blocked | No PagerDuty alert; the audit trail records the block decision and rationale. | | alerting | Build an Events API payload (see below) including audit_ref in custom_details. |

Full transition graph:

1{
2  "transitions": [
3    { "from": "idle", "to": "researching", "actor": "automation" },
4    { "from": "researching", "to": "classifying", "actor": "automation" },
5    { "from": "researching", "to": "failed", "actor": "automation" },
6    { "from": "classifying", "to": "auto_approving", "actor": "automation" },
7    { "from": "classifying", "to": "human_review", "actor": "automation" },
8    { "from": "classifying", "to": "blocked", "actor": "human" },
9    { "from": "auto_approving", "to": "alerting", "actor": "automation" },
10    { "from": "human_review", "to": "alerting", "actor": "human" },
11    { "from": "human_review", "to": "rejected", "actor": "human" },
12    { "from": "human_review", "to": "escalating", "actor": "automation" },
13    { "from": "escalating", "to": "human_review", "actor": "automation" },
14    { "from": "escalating", "to": "failed", "actor": "automation" },
15    { "from": "alerting", "to": "complete", "actor": "automation" },
16    { "from": "alerting", "to": "failed", "actor": "automation" }
17  ]
18}