Plans Governance
How intent plans move through pending, held, approved, and terminal states, and how human delegation approvals fit into that lifecycle.
Every intent plan ArmorIQ intercepts is a row in a governance ledger, not just a point-in-time decision. This page covers the lifecycle a plan moves through and how human approval fits into it. For the list and detail views themselves, see Plans List and Plan Detail; for tab-by-tab detail and the tamper-evident audit chain, see Plan Detail Tabs.
Open Plans in the dashboard to see the ledger filtered by:
| Filter | Shows |
|---|---|
| Needs you | Plans held on a delegation waiting for your approval |
| Active | Plans currently in progress |
| Resolved | Plans in a terminal state - completed, approved, blocked, failed, rejected, expired, or killed |
| All | Every plan, unfiltered |
Status lifecycle
A plan's status is computed from several signals rather than a single stored field - see Status Types for the full table. In short: an agent kill always wins and marks the plan killed; a pending delegation holds the plan at held until it's approved or rejected; an unresolved plan past its expiry becomes expired (a background job periodically sweeps stale active plans into this state); and otherwise the plan is active until it completes, fails, or is blocked by policy.
Delegation and approval
When a tool call exceeds what an agent's policy allows on its own - typically a monetary or authority limit - ArmorIQ raises a delegation request instead of failing the call outright. This is a human-in-the-loop escalation, separate from IAP's own agent-to-agent trust chain (see trust deltas):
- The agent's tool call carries requester context - email, role, and any amount involved.
- If the request exceeds the requester's role limit, a delegation request is created and the plan is held.
- A human with a higher-ranked role than the requester can approve or reject the request. A requester can never approve their own request.
- Approving or rejecting the delegation updates the plan's status accordingly -
approvedorrejected- and, on approval, records aDelegatetrust delta.
There are two independent paths that can approve or reject a plan: the SDK-facing delegation API, and the dashboard's admin status-update action. Both apply the same self-approval guard, but only the dashboard path currently respects the ALLOW_SELF_APPROVAL environment variable - treat that variable as dashboard-only until both paths are unified.
PAP pre-flight
Before a plan is finalized, the SDK can call a separate refinement step ("PAP") that returns a decision of accepted, rejected, or escalated along with any policy predicates that failed. ArmorIQ persists these refinement decisions and exposes them read-only through /pap/decisions and related stats endpoints for dashboard review.
The PAP acronym is not expanded anywhere in the codebase or its docs. Treat "PAP" as the name of this pre-flight refinement step rather than a confirmed expansion.