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.

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.

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 — the use case may advance (counts toward the logic threshold)
Rejected — the use case is blocked; the gate stays open

A single Rejected decision blocks advancement regardless of the approval logic mode. The gate only resolves once all rejections are withdrawn or the gate is force-overridden.

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 stays open. Ben and Ana's approvals do not override the rejection. A Governance Admin would need to either address Clara's concern (she can change her decision) or use a force override with a documented reason.

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. If Ana had recorded Rejected instead, the gate would remain open until a different approver in the pool approves, or a force override is applied.

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