Stage Transitions

Every use case follows a structured, linear path through your organization's governance framework. Each stage has a gate that must be satisfied before the use case can advance -- through completed work, human approval, or both.

Governance administrators configure the framework and approval pools once at the org level. Use case submitters and reviewers then interact with the resulting workflow as the use case progresses.

Stage overview

The following stages are the default provided by Airia. A use case moves through them in order:

Stage	What happens here
Register	The use case is created to define intended use and associated agents. Initial risks assessed for review.
Triage	Exploratory assessments available to provide additional context for risks, excluding the asset, which is not yet connected.
Build & Connect	Builder constructs the associated asset and connects it to the use case, enabling asset-aware assessment.
Assess	A second assessment pass runs automatically against the connected asset, using the same assessment stage as pass 1.
Mitigate	Treatment plan chosen for each risk related to the use case. Mitigated risks suggest and track completion of associated controls.
Approval	Configured approvers review the full record and vote to advance or block the use case.
Monitor	Live signals — usage patterns, guardrail effectiveness, and drift — are watched against triggers set during assessment.

At each stage boundary there is a gate — a checkpoint that must be satisfied before the use case advances. Gates are where approvals happen.

Triage and Build & Connect are conditional, not universal — they only fire when no asset is provided at Register. If the use case is registered with an asset already attached, both stages are skipped and the use case proceeds straight to Assess.

Moving Forward

A use case progresses by satisfying the gate at each stage boundary. Gates track two things: completed items required for the stage (such as filled assessment sections or resolved mitigation tasks) and any human approval required to advance. Once all conditions are met, the gate clears and the use case moves to the next stage.

Stages that require human oversight will present one of two approval modes:

Generic approvals

A gate configured for generic approval presents a Promote to [next stage] button visible to any governance user. No specific approver is designated — any authorized user can advance the use case. This is appropriate for transitions where a formal sign-off is not needed.

Explicit approvals

A gate requiring explicit approval routes the use case to the users declared in your organization's Default Approvers configuration. Each approver must record a decision, and the gate resolves according to the configured approval logic (see Approval Logic below) before the use case can advance.

Force override

An authorized user (typically a Security Admin) can bypass a gate that is pending — skipping the gate's explicit requirements and advancing the use case immediately. A reason is required when overriding.

Force override is not available on every stage. The Register and Approve stages cannot be bypassed; the review work they represent must be completed normally.

Overriding Mitigate also accepts every untreated risk on the use case, attributed to the person who overrode it with their stated reason. See Risk Tolerance.

Bypassed gates are recorded in the use case history with the overriding user and their stated reason. Overrides are visible to all reviewers and admins.

Moving Backward

Regress

A use case can be regressed — moved back to a previous stage — by clicking a completed stage in the workflow timeline. Regression resets that stage's gate so the work can be redone.

Common reasons to regress:

New information surfaced during a later stage that requires re-assessment
An approver requests changes that affect an earlier stage's outputs

The Register stage cannot be regressed to. Once a use case moves past Registration, the intake record is fixed. Any corrections to the use case details are made on the Assess stage.

Regression requires a reason, which is logged in the use case history alongside the actor and timestamp.

When a use case with a sealed Nutrition Label is regressed to a stage before Mitigate, a new version is created and the sealed label and Receipt stay on the previous version. A use case in Monitor can also return to an earlier stage on its own when something it depends on changes. See Use Case Versions.

Approval Logic

When a gate requires explicit approval, the framework defines how individual approver votes are combined to determine the gate outcome. There are three modes:

Mode	Gate advances when…
Any	At least one approver records an Approved decision
All	Every approver in the pool records an Approved decision
Majority	More than half of the approver pool records an Approved decision

An approver can record one of two decisions:

Approved — counts toward the logic threshold
Rejected — counts toward the rejection threshold for the same logic

The gate resolves as Rejected when the rejections reach the threshold for the configured mode, and approvals are checked first:

Mode	Gate resolves as Rejected when…
Any	At least one approver rejects and no approver has approved
All	Any approver rejects
Majority	More than half of the approver pool rejects

What a rejection does

A gate that resolves as Rejected can never be satisfied by further votes. What happens next depends on the workflow:

Default governance workflow. The Approve stage completes with a Rejected outcome and the use case is routed to Quarantine, a parked stage with no gate where it rests. It leaves the active flow and does not reach Monitor.
A workflow with no rejected path. The stage stays at its gate, awaiting a decision. Use a force override, with a documented reason, to move it.

A rejection does not cut a new version or move a use case back to an earlier stage.

Example: "All" logic with three approvers

An Approval gate is configured with All logic. The org default approver pool contains three users: Ana, Ben, and Clara.

Approver	Decision	Gate state
Ana	Approved	Waiting (2 remaining)
Ben	Approved	Waiting (1 remaining)
Clara	Approved	Gate resolves → use case advances

If Clara records Rejected instead, the gate resolves as Rejected. Ben and Ana's approvals do not override it, and in the default workflow the use case is routed to Quarantine.

Example: "Any" logic with three approvers

The same gate is reconfigured with Any logic.

Approver	Decision	Gate state
Ana	Approved	Gate resolves immediately → use case advances

Ben and Clara are no longer required to vote, and a later rejection does not change the outcome. If Ana had recorded Rejected first, with no approval yet, the gate would resolve as Rejected.

Approval logic mode and approver pool membership are set at the organization level. If you need to adjust these for your organization, see Approvers.

Stage TransitionsEnterprise