> For the complete documentation index, see llms.txt.
Skip to main content

Check out Port for yourself ➜ 

Act on response

A ranked response only matters if running it is safe, scoped, and verifiable. Once a response is chosen, Act runs it inside guardrails, then verifies whether it actually worked.

Port runs workflows and actions inside boundaries the team defined in advance, logs intent and outcome on the incident record, and escalates when verification fails. Every run is recorded in the audit log. The same approval gates apply whether a person triggers the workflow or automation runs it.

The problem: Without structural checks, whether an action may run becomes a judgment call made fresh under pressure.

The solution: A governed action crosses an approval gate that checks policy, blast radius, and rollback availability before it proceeds, then verifies the outcome against what was expected.

What a governed action needs​

A governed action needs a clear definition and an approval gate. Teams add the rest as they move from approved workflows toward autonomous execution.

  • Action definition - inputs, scope, expected outcome, success signals, and a rollback path.
  • Policy enforcement - boundaries the runtime cannot bypass.
  • Scoped identities - issued per action, not standing credentials.
  • Post-action verification - tied to the action definition's success signals: SLOs, health checks, the metric the action was supposed to move.
  • Automatic rollback - triggered when verification fails and reversal is defined.

Approval gate​

When the approval gate evaluates an action, it returns one of three outcomes:

  1. Autonomous - may run without a human in the loop.
  2. Needs approval - waits for human approval before execution.
  3. Blocked - not allowed at the current confidence or impact level.

Automation eligibility sets which action types can reach each outcome. The approval gate re-checks at execution time because incident state may have changed since recommend.

Execution sequence​

For governed actions, the runtime moves through three stages in order: gate, execute, verify.

Governed execution sequence: Gate (re-check), Execute (identity, run action definition), Verify (observe, decide, rollback or escalate)

Gate

  1. Re-check incident context and automation eligibility. The approval gate returns autonomous, needs approval, or blocked for this action given current incident state, not when it was recommended.

Execute

  1. Acquire a scoped identity for this action only when automation runs it.
  2. Execute according to the action definition.

Verify

  1. Observe the signals the action definition said would confirm success.
  2. Decide success or failure against that expectation.
  3. Roll back automatically, or escalate to a human, if it did not work.

Human oversight​

As autonomy handles more of the response, humans regulate authority and risk instead of approving each action. Each active incident runs inside a control loop that tracks how much human involvement that response needs as confidence and results shift.

The control loop moves between three states during the incident:

  1. Autonomous execution - incident confidence stays above threshold, verification signals converge on success, and risk remains within policy. Automation continues without pulling a human in.

  2. Assisted autonomy - confidence drops, options compete, or corrective actions show diminishing returns. A human tightens or redirects constraints while automation keeps running inside the new bounds.

  3. Human-led intervention - verification fails, confidence collapses, or the pattern is unrecognized. Autonomy pauses or scales back, and a human takes the lead from a decision packet the system prepared.

Human oversight control loop: autonomous execution, assisted autonomy, and human-led intervention, separate from the per-action approval gate

Port tracks control loop state on the incident record, assembles decision packets when humans are pulled in, and records agent reasoning and tool calls in AI invocation logs when agents are involved.

The approval gate decides each action; the control loop sets human oversight for the whole response. Transitions are set in policy in advance, not decided under pressure.

When the control loop pulls a human in, they get a decision packet:

  • Current state and confidence trend.
  • What has already been tried, and what happened.
  • Options still on the table, with tradeoffs.
  • The specific question the system cannot resolve on its own.

Each governed action stays attributed to a service owner and runs under a scoped identity. The team encodes responsibility into the system; it does not delegate it.

Next: what the team learns from the outcome feeds back into the system. See Learn from incidents.

Back to the self-healing incidents overview.