Suggestion Inbox
The Suggestion Inbox is the decision surface for Governance Autopilot. It is the only place where an AI-drafted policy change can become a live rule. Every Suggestion - whether produced by the nightly discovery agent, drafted in the Policy Studio Designer, or generated by a future producer - flows through the same Inbox and follows the same review process.
When you apply a Suggestion, it creates a policy rule the same way the manual rule editor does. There is no difference at evaluation time between a rule applied via the Inbox and one authored by hand.
Where Suggestions come from
| Source | How it's created |
|---|---|
| Policy Studio Designer | Admin clicks "Commit to Inbox" after reviewing a candidate in the Designer |
| Governance Insights | Discovery agent produces a Suggestion directly for high-confidence patterns |
| Manual escalation | Any admin can submit a rule candidate via the management API |
The source is recorded on each Suggestion and shown in the Inbox, but it does not change the review or apply flow.
Suggestion lifecycle
Proposed ──▶ Reviewed ──┬──▶ Applied
│ │ │
│ │ ├──▶ Rejected
│ │ │
│ │ └──▶ Superseded
│ │
└────────────┴── Expired (14 days from Proposed, no decision made)
Proposed - The Suggestion is visible in the Inbox and available for review.
Reviewed - An admin has opened and reviewed the Suggestion. For HIGH and CRITICAL severity Suggestions, the first admin's approval is recorded here and a second approval is required before the Apply button activates.
Applied - A policy rule was created. The Suggestion is permanently linked to the resulting rule version.
Rejected - An admin rejected the Suggestion with a required reason. The reason is recorded and used to reduce the likelihood of similar suggestions being proposed for the same domain going forward.
Superseded - A newer Suggestion replaces this one (typically when a Suggestion is refined in the Designer and re-committed).
Expired - No decision was made within 14 days of the Proposed state. The Suggestion is automatically closed.
Severity levels
Each Suggestion is classified by severity at creation time, based on the counterfactual simulation:
| Severity | Trigger | Approval required |
|---|---|---|
| LOW | Would have affected 0 IECs in the simulation window | Single admin |
| MEDIUM | Would have affected 1–10 IECs, or capability risk score ≥ 0.5 | Single admin |
| HIGH | Would have affected 11+ IECs, or capability risk score ≥ 0.8, or irreversibility ≥ 0.8 | Two admins |
| CRITICAL | Would have affected 50+ IECs, or rule targets identity or finance HITL defaults, or removes existing HITL | Two admins + audit webhook on apply |
Severity is calculated automatically at creation time and cannot be changed.
Two-person approval for HIGH and CRITICAL
Suggestions classified HIGH or CRITICAL require approval from two different ADMIN or OWNER accounts before they can be applied:
- The first admin clicks Approve. The Suggestion moves to Reviewed status, recording the first approver.
- The Apply button remains disabled until a second, different admin clicks Approve & Apply.
- Both approver identities are recorded in the audit log.
This requirement is enforced on the server - it cannot be bypassed from the UI.
Apply flow
When an admin clicks Apply:
- The Suggestion payload is validated against the policy rule schema.
- A new policy rule version is created - the same path as the manual rule editor.
- The rule takes effect on the next IEC evaluation.
- The Suggestion is marked Applied, linking it permanently to the new rule version.
- An audit log entry is created, permanently linking the Suggestion, the inference that produced it, and the new rule version.
The resulting rule is indistinguishable from a manually authored rule at evaluation time. The only difference is the provenance trail in the audit log.
Reject flow
Clicking Reject opens a required reason field (25–500 characters). The reason is:
- Permanently recorded on the Suggestion
- Written to the audit log
- Used to reduce the likelihood of similar suggestions being proposed for the same domain going forward
Rejection reasons are private to the organization and are never shared with other tenants.
Counterfactual report
Every Suggestion in the Inbox includes the same Counterfactual Lens report visible in the Policy Studio Designer. The report is cached - re-opening a Suggestion within 24 hours does not re-run the simulation.
Expanding the Suggestion card shows the full counterfactual breakdown: verdict deltas per affected IEC, false-positive estimate, HITL load change, cost delta, risk-reduction score, and the top 5 most-affected agents.
Provenance panel
Each Suggestion exposes a provenance panel that shows:
- The producer (Designer session, discovery agent run, or manual)
- The model, prompt version, token count, and cost of the inference that produced it
- A link to the inference replay tool (re-runs the prompt against the current model for comparison)
- All typed citations: specific IEC records, rule references, baseline values
For applied Suggestions, the panel extends to show the resulting policy rule and the audit log entry that links them.
Refine in Designer
Any Suggestion - including one produced by the discovery agent - can be reopened in the Policy Studio Designer via the "Refine in Designer" button. The Designer loads with the Suggestion's context and evidence pre-populated, allowing iterative refinement before re-committing to the Inbox as a new Suggestion. The original Suggestion is marked as superseded when the refined version is committed.
Related
- Governance Autopilot - overview of the full advisory loop
- Policy Studio Designer - draft candidates before they reach the Inbox
- Policy & Governance - the rule language and evaluation model
- Observability & Audit - the audit trail