Use Case VersionsEnterprise
When a live use case gets a new version, what happens to it, and how to read its version history.
A use case that is live in Monitor has been approved against a specific posture: the assets it governs, the assessment template it was assessed with, your organization's risk tolerance, and the governance frameworks that apply. When one of those changes in a way that matters, the approval no longer describes what is actually running. Airia then cuts a new version of the use case and sends it back through the lifecycle, and keeps the previous version as a permanent record.
The short answer
A use case gets a new version when it is live in Monitor and something it depends on changes substantively. It then returns to Assess (or to Mitigate, when the change is to your organization's risk tolerance).
Editing the use case itself, such as its name, description, owner, or any field you fill in, never creates a new version. Edits update the current version in place.
A new version is cut only when all three of these are true:
- Something outside the use case changed: an AI asset it governs, an assessment template, your organization's risk tolerance, or a governance framework.
- The change was substantive, not cosmetic. Renaming an agent is cosmetic. Swapping its model is not.
- The use case is live in Monitor, meaning it has been approved and holds a Receipt.
A use case can also get a new version when an administrator moves it back to a stage before Mitigate after its Nutrition Label has been sealed.
Your organization can turn automatic version cutting off. See Use Case Versioning.
What the stage of a use case decides
| Where the use case is | What a substantive change does |
|---|---|
| Monitor (live) | New version, and back to Assess. A risk-tolerance change is the exception: it creates a new version only when an automatically accepted risk is now outside the new tolerance, and sends the use case back to Mitigate instead. |
| Register through Approve | No new version. Asset and framework changes keep the risk analysis up to date in place. An assessment-template change is only recorded. A risk-tolerance change refreshes automatic acceptances, and may send a use case at Approve back to Mitigate. |
| Quarantine, Archive | Nothing. The change is recorded and the use case is left alone. |
What can change underneath a use case
AI assets
An agent, pipeline, prompt, application, or discovered external asset assigned to the use case.
- Counts: a different model, changed tools or MCP servers, new knowledge or data sources, edited prompts or code, changed guardrails, instructions, autonomy level, authentication, reachability, or endpoints, and deletion.
- Does not count: renaming the asset. Rename is the only cosmetic change. A field that is not recognized is treated as substantive, so an unknown change is never assumed to be safe.
Assessment templates
Someone published a new version of a template the use case was assessed with.
- Counts: any change to the questions themselves, but only for a use case that is live in Monitor.
- Does not count: republishing with the questions unchanged, such as a retitle.
At every other stage a template change is recorded and nothing else happens. The new questions apply the next time the use case is assessed with that template.
Risk tolerance
An administrator changed the risk-tolerance posture or a per-domain override. Risk tolerance decides which risks are accepted automatically: a risk whose inherent level is within the tolerance for its domain is accepted without anyone signing it off. A tolerance change therefore acts on those automatic acceptances.
- Tightened: an automatic acceptance the new tolerance no longer covers is removed. The risk returns to Pending review, or goes straight to Mitigate if its mitigations already bring it within tolerance, and has to be treated again.
- Loosened: risks newly within tolerance are accepted automatically. Nothing is removed and no use case is sent back.
Acceptances that a person made, or has since edited, are never touched by a tolerance change.
| Where the use case is | What a tolerance change does |
|---|---|
| Monitor, with an automatically accepted risk now outside tolerance | New version, and back to Mitigate. The Nutrition Label is kept as it is. |
| Monitor, with every automatic acceptance still within tolerance | Nothing. Recorded only. This is always the case for a loosening. |
| Mitigate or Approve, with an automatically accepted risk now outside tolerance | Back to Mitigate in the same version. |
| Mitigate or Approve, otherwise | Automatic acceptances refreshed in place. No stage move. |
| Triage through Assess | Automatic acceptances refreshed in place. No stage move. |
| Register, Quarantine, Archive | Nothing. Recorded only. |
Governance frameworks
| What happened | Result |
|---|---|
| Your organization enabled a framework that applies to the use case | Counts. The use case has never been evaluated against its requirements. |
| Airia updated a framework's content | Counts, if the update changed something that affects assessment. |
| Your organization disabled a framework | Does not count. Scope only narrows. |
For the exact verdict on each asset field, see Is an asset change material?.
What you will see when it happens
- A new version appears in the use case's version history and becomes the current version.
- The previous version keeps its sealed Nutrition Label and Receipt as its permanent record.
- The use case returns to Assess, or to Mitigate after a risk-tolerance change.
- Stages above that point reset, and approvals already given are no longer counted. They stay in the history for audit, but the use case has to earn them again against the new content.
- After a return to Assess, the Nutrition Label is regenerated as the use case moves forward, so what it discloses matches what it now does. After a return to Mitigate the analysis has not changed, so the sealed label is kept.
- After a risk-tolerance change, risks whose automatic acceptance no longer holds show as Pending review in the risk registry.
- The new version moves through the lifecycle like any other use case and can reach Monitor again.
Invalidated approvals are intended behavior. A sign-off is a statement about specific content. Once that content changes, the sign-off no longer describes what exists.
Viewing versions
On the Use Cases board, each version appears as its own card with a version badge, such as v2 · Current for the version being worked on. Open a use case and use its Version history panel to see every version, its status (published or archived), when it was created, and who cut it. If you do not have permission to see a use case's history, the panel says so instead of listing versions.
If a use case moved and you do not know why, check the newest version in the version history first. The change is also recorded in the use case's history.
What does not create a version
| Action | Why not |
|---|---|
| Editing the use case, such as its name, description, owner, or any field | Edits update the current version in place. |
| Moving forward through stages and getting approvals | Only moving backward past Mitigate matters. |
| Sealing a Nutrition Label or generating a Receipt | The evidence attaches to the version you are on. |
| Any change on a use case that is not yet live | It is kept up to date in place, or for an assessment template only recorded. |
| A risk-tolerance change that leaves every automatic acceptance in place, including every loosening | Nothing the approval rested on has moved. |
| Renaming an AI asset, or republishing a template with the same questions | Cosmetic. |
| Disabling a governance framework | Scope narrows. |
| Any change on a Quarantined or Archived use case | Parked use cases are left alone. |
| Any change while automatic version cutting is off | Recorded only. |
| Creating or importing a use case | That starts version 1. |
What to do about it
- Warn owners before changing a live asset. If you publish a change to an agent that live use cases govern, their owners will see those use cases return to Assess.
- Expect it after tightening risk tolerance. Use cases whose automatically accepted risks fall outside the new tolerance go back to Mitigate, and those risks need treating again.
- Do not re-approve blindly. Re-read the regenerated Nutrition Label, or the risks back in Pending review, before signing off again.
- Nothing is lost. The earlier approval, its Nutrition Label, and its Receipt are preserved on the earlier version.