> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mnemom.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Governance Signals

> Operator-actionable observations from Mnemom's platform detectors — fleet drift, value fault lines, coherence drops, behavior drift. Surfaced to operators (UI, webhook, REST). The platform never injects governance signals into an agent's prompt.

**Governance signals** are operator-actionable observations produced by Mnemom platform detectors. They surface fleet-shaped concerns — coherence drift across a team, value fault lines between agents, fleet topology changes, per-agent behavior drift — that an *operator* (CISO, org admin, team admin, on-call SRE) needs to see and act on.

They are deliberately distinct from the agent-facing advisories the gateway carries forward into an agent's next turn (the `pending_advisories` surface — see the [wire format](/specifications/pending-advisories-schema)). The architectural commitment is:

> **Operator observations never reach an agent's prompt; agent advisories never reach the operator alert rail.**

If an agent is told "Recalibrate fleet alignment before the next response," it has no team-management authority, no acknowledgment surface, and no remediation it can perform from inside its own LLM call. The signal is real and important — but the recipient is wrong. Governance signals fix that mis-layering by routing fleet-shaped observations exclusively to operator surfaces.

## What gets surfaced

| Source | Detector | What it catches | Acts at |
| - | - | - | - |
| `sideband.drift` | Per-agent drift | An agent's behavior diverging from declared alignment | Per agent |
| `sideband.coherence` | Team coherence | Pairwise governance scores below threshold; conflict edges; outlier agents | Per team |
| `sideband.fault_line` | Value fault lines | A value dimension splits the team into agents-declaring vs agents-missing vs agents-conflicting | Per team |
| `sideband.fleet` | Fleet topology | Cluster partitions, weak-pair score floors, fleet outliers | Per team |

Future `protection.*` and `posture.*` sources will land additively.

## Surfaces, not injections

A governance signal lives in **three operator surfaces** simultaneously:

1. **Web UI** at `mnemom.ai/dashboard/teams/{teamId}/governance` (and per-agent at `mnemom.ai/dashboard/agents/{uuid}/governance`). Filterable list, severity badges, ack/resolve/dismiss workflow.
2. **Notification destinations**: `governance.signal.fired`, `governance.signal.acknowledged`, `governance.signal.resolved`, `governance.signal.dismissed`, `governance.escalation.triggered`. A generic `webhook` destination delivers an HMAC-SHA256 signed POST (`X-Mnemom-Signature: sha256=<hex>` over the raw JSON body, plus `X-Mnemom-Event` and `X-Mnemom-Delivery-Id` headers). This is a purpose-built delivery path for governance destinations, configured per-org and separate from the general-purpose org webhook subscriptions described in the [webhook contract](/concepts/webhook-contract) — do not assume the same signature scheme or retry schedule applies.
3. **REST API**: `GET /v1/orgs/:org/governance/signals`, `GET /v1/teams/:team/governance/signals`, `GET /v1/agents/:agent/governance/signals`, plus state-transition endpoints. See [Governance Signals Schema](/specifications/governance-signals-schema).

The platform **never** injects governance signals into an agent's LLM request — there is no exception, no per-agent fast-path, no platform-supplied composer pattern. Applications that want fleet context inside an agent's prompt derive it from application-internal data and render it application-side; the platform offers no surface for that.

## Operator workflow

A signal moves through this lifecycle:

```
   open → acknowledged → resolved
       ↘                ↗
        dismissed
       ↘
        expired (TTL)
```

* **`open`** — fresh detection. Notification rail (Slack, email, PagerDuty, generic webhook) routes per your [escalation rules](/guides/operating-governance-signals#escalation-rules).
* **`acknowledged`** — an org admin / org owner / team admin has confirmed receipt. Captures `acknowledged_actor_role` per the audit-actor model.
* **`resolved`** — closed with a `resolution_status` (`action_taken` / `wont_fix` / `duplicate` / `false_positive` / `self_resolved`) and optional `action_taken` note.
* **`dismissed`** — operator marked as not actionable (noise, redundant).
* **`expired`** — TTL elapsed without operator action; configurable per posture, default 30 days.

The schema's partial unique index on `(scope, scope_id, source, pattern_type) WHERE status='open'` makes detection idempotent: repeated cron emissions of the same condition refresh the open row in place rather than stacking. This is the architectural fix to the symptom that triggered this work — an agent receiving the same `cluster_partition` paragraph 2× per turn for weeks.

## Notification destinations

Each org configures destinations independently:

* **`webhook`** — generic HMAC-signed POST to a URL of your choice (see the signature format above).
* **`slack`** — incoming-webhook POST with [Block Kit](https://api.slack.com/block-kit) payload. Severity-color border, action button to "Acknowledge in dashboard."
* **`email`** — HTML + plaintext email.
* **`pagerduty`** — Events API v2 with stable `dedup_key` so coalesced detections don't duplicate incidents.

`webhook` and `slack` destination URLs must be `https://` and must resolve to public addresses. A URL that carries credentials, uses a single-label, `localhost` or internal hostname, or points at a loopback, private or link-local address is rejected when you save the destination, and every delivery re-checks the address, following redirects only to URLs that pass the same checks. A blocked delivery or test reports one generic failure rather than the underlying network error.

A destination's `filter` narrows what it receives (sources, severities, scopes, pattern\_types). [Escalation rules](/guides/operating-governance-signals#escalation-rules) bind a predicate to a list of destination IDs and support rate-based gating (`threshold_count` + `window_minutes`) for "fire only if N matching signals occurred in M minutes."

Test a destination from the CLI:

```bash theme={null}
mnemom governance destinations test <destination_id> --org <org_id>
```

This sends a synthetic signal through the channel only (bypasses rules) and records `last_tested_at` / `last_test_status` on the destination.

## Surface-separation guarantee

The surface-separation invariant — governance signals never reach an agent's prompt — is continuously asserted in CI:

1. End-to-end fixtures that provoke each `governance_signals` source and assert the agent's prompt is byte-clean.
2. Telemetry that production gateway requests over a 30-day rolling window write zero `pending_advisories` rows whose `source LIKE 'sideband.%'`.

## Related

* [Sideband detection](/concepts/sideband-detection) — the detector layer (unchanged; only the delivery surface moved).
* [Governance Signals Schema](/specifications/governance-signals-schema) — table layout, RPCs, RLS.
* [Operating governance signals](/guides/operating-governance-signals) — operator runbook for ack/resolve/dismiss + destinations + rules.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.