Workflows
Approvals and holds
Inserting a human decision into a run, with timeout behaviour that fails safe.
An approval is a workflow step, not a side channel. The run pauses, the approver sees the specific parameters that will execute, and the decision is recorded against the run.
Where approvals come from
- Declared on an action in the catalogue, so every workflow using it inherits the requirement.
- Declared on a workflow step, for cases specific to that process.
- Derived from policy — an environment, a tenant, a size threshold or a blast radius crossing a limit.
What the approver sees
The resolved asset set, the exact action parameters, the findings gathered so far, who or what triggered the run, and the verification that will be performed afterwards. Approving without that context is how approval becomes a formality.
Timeouts
Every approval declares a timeout and a timeout action. The available timeout actions are abandon the run, escalate to a secondary approver, or continue — and continue is deliberately not the default. An approval that silently proceeds when nobody responds is not a control.
Scope of this documentation