Proposals

Nothing changes in your infrastructure without a proposed change first. A proposal is a record: it names the target, the exact operation and parameters, its risk tier, and what it is expected to do. Approving it is a separate, deliberate act.

This page is the workflow as you meet it. For the tier model and policy behind it, see actions & approvals.

Where proposals come from

Three doorways, all reaching the same governed entry point:

AI diagnosis during an incident. ISE investigates, forms a view, and drafts the fix it thinks follows from the evidence.
You, directly. The actions panel on a system detail page lets you pick an operation and fill in its parameters. Or type it in the incident conversation — “propose scaling the deployment” reaches the same place the button does.
A playbook run. Changes inside a published playbook’s envelope are auto-approved with provenance rather than queued.

Whichever door it came through, the tier is resolved by policy, protected targets apply, and separation of duties can never be auto-satisfied.

What a proposal shows

Before you approve anything you can see:

Target system and target — exactly what it will touch.
Operation and its exact parameters — no summarised intent, the real values.
Tier badge — T0 through T3.
Rationale and evidence — why this, with links to what it was based on.
Expected effect and rollback note — what should happen, and what undoing it involves.
Proposer — a person, or the agent run that drafted it, linked so you can read the whole reasoning trace.

Proposals raised by an AI are visibly marked as such, and self-proposed items are blocked from self-approval at the higher tiers.

Approving

Approvals appear in two places, deliberately: on the Approvals queue (everything pending, in one governance view) and inline in the incident timeline, where an awaiting-approval change shows as a notification bubble right where the work is happening. It is the same governance either way — approve or reject from wherever you are reading.

Rejection asks for a comment. That comment is the useful half of the record six months later.

Approvers are approver or admin roles, and at T2/T3 the proposer cannot approve their own change. In a small team, admin self-approval is possible but is distinctly audited so it stands out rather than blending in.

Execution

Once approved, ISE runs the exact approved parameters through the connector. No model is in the loop at this point — approval froze the parameters, and execution applies them deterministically.

Long-running operations are polled to completion. An action reports success when the target system says it finished, not when it accepted the request — so “succeeded” means it actually did.

Failures stop and are recorded with their error, and are never silently retried unless the operation is provably idempotent. Nothing rolls back automatically: undoing a change is itself a new change, proposed and approved on its own terms.

Afterwards

The result posts to the incident timeline, and the whole sequence — proposed, approved by whom, executed, outcome — lands on the audit trail. During an incident, ISE follows an execution with a suggestion of what to check or do next, and if the condition clears the signal recovers and the incident resolves.

Actions & approvals — tiers, policy, protected targets.
Playbooks — when approval is spent once, at publish.
Roles & access — who may propose and who may approve.