Lifecycle

Every organisation, group, and workspace carries a lifecycle state. The state decides whether the resource accepts changes, whether it can hold anything new, and whether it can be deleted.

stateDiagram-v2
  classDef primary fill:#e8e8ff,stroke:#1100ff,stroke-width:2px,color:#0e0d1a
  classDef danger fill:#ffe3e8,stroke:#ff002f,stroke-width:2px,color:#0e0d1a

  [*] --> Active: create
  Active --> Suspended: suspend
  Suspended --> Active: resume
  Active --> Archived: archive
  Archived --> Active: restore
  Archived --> Deleted: delete
  Deleted --> [*]

  class Active,Suspended,Archived primary
  class Deleted danger

Lifecycle states

A resource reports its current state at any moment. Resting states are stable: the resource stays there until somebody asks for a change. Terminal means there is no way back.

The impact column is the one to read first. It says what the state does to your data, which is the difference that matters.

State	Kind	Impact	What it means
Active	Resting	None	Normal operation. Everything is created active.
Suspended	Resting	Non-destructive	A safety lock. Changes are refused, so nothing new can be created while the problem is dealt with. Every byte of data is kept.
Archived	Resting	Non-destructive	Put away because it is no longer in active use. Changes are refused, and what is inside is preserved in case it is needed again.
Deleted	Terminal	Destructive	The resource and its data are gone for good. Only the history remains.

Non-destructive means the state stops the resource being used without touching what is in it. Disks, buckets, objects, secret material, and images are all kept, and you can still list and inspect a suspended or archived resource, so you can see your data and understand why you are blocked.

Destructive applies to deletion alone. It genuinely removes the resource and the data it holds, and there is no way to undo it.

Suspended and archived do the same thing to your data, which is nothing. What separates them is the reason the resource was put in that state.

Suspending is a safety net. It locks a resource down when something has gone wrong, such as an attack in progress or a billing problem, and the point of the lock is to stop the situation from getting worse while it is investigated. Nothing new can be created, so an attacker cannot keep spinning up resources and the bill cannot keep growing.

Archiving is about relevance. The resource is no longer a hot one, so it is moved out of the way of everyday use instead of cluttering it. What is inside is shut down but preserved, so it can come back if it turns out to be needed later. Archiving is also the middle step before deletion, and the only route to it.

Because the reasons differ, the two states are reached and left by their own actions: suspend and resume for the safety lock, archive and restore for putting something away. There is no single action that returns any resource to active, and that is deliberate. Undoing an archive and lifting a safety lock are different decisions, made for different reasons, so they stay separate.

A suspended resource cannot be archived directly. The lock has to be lifted first, so archiving is never a way around it.

State inherits down the tree

A change on a parent can reach everything nested inside it, so the tree never ends up in a mixed state where an active resource sits inside one that is not.

Suspending and resuming always reach the contents. The safety lock would be worthless otherwise: locking a group has to lock everything it holds, or the problem simply continues one level down. A workspace inside a suspended group is itself suspended.

Archiving and restoring reach the contents only when you opt in. By default each acts on the resource you named and nothing else, and archiving a parent that still holds anything active is refused rather than cascading. Setting force on the request is what extends it to the whole subtree, in either direction. See Archiving below.

flowchart TD
  classDef primary fill:#e8e8ff,stroke:#1100ff,stroke-width:2px,color:#0e0d1a
  classDef warn fill:#fff4e0,stroke:#ff8a00,stroke-width:2px,color:#0e0d1a

  ORG["organisation acme<br/>Active"]
  ENG["group engineering<br/>Suspended (direct)"]
  BE["group backend<br/>Suspended (inherited)"]
  WS["workspace api<br/>Suspended (inherited)"]

  ORG --> ENG --> BE --> WS

  class ORG primary
  class ENG,BE,WS warn

Every resource also reports why it is in its state:

Direct: an administrator acted on this resource itself.
Indirect: the change came from an ancestor.

You can filter a listing on both, so you can ask for everything that is suspended, or only for what is suspended because a parent is. The second question is the useful one: it tells you what would go back to normal if the ancestor were resumed.

An indirect change also records which request caused it, so “why is this archived?” has an answer months later. Nothing changes silently.

Reversing on the ancestor reverses the same subtree, and that includes a state a descendant was given on its own. If a workspace was suspended by itself last week, resuming the group above it returns that workspace to active too. An organisation is the root of the tree, so it has nothing to inherit from: its state is always direct.

Archiving

Archiving is indefinite. There is no retention clock, no scheduled purge, and no background job that eventually removes an archived resource. It stays archived until somebody decides otherwise.

An organisation or group can be archived once nothing inside it is still in use. Something already put away is no reason to keep its parent in use, so a parent whose contents are all archived can be archived as it is.

A parent that still holds anything active is refused. Archiving never reaches the contents by accident. You have two ways forward: archive the contents first, from the inside out, or repeat the request with force.

Archiving with the contents

force is the opt-in that says “also act on what is inside”. It is a flag on the archive request, and setting it is you accepting that resources you did not name will be archived too. With it, one request puts the whole subtree away, at any depth, instead of one request per resource in strict innermost-first order. Without it, nothing below the named resource is touched, and a parent holding anything active is refused.

The same flag exists on restore and means the same thing there, so what you put away in one act comes back in one act. It is offered on groups and organisations only. A workspace is always a leaf, so the flag could never change the outcome.

A few rules make it safe to use:

Anything already archived is left exactly as it is. No change is recorded against a resource that did not change.
A suspended resource anywhere inside refuses the whole request, force or not. A safety lock is not something you can archive your way around, and it has to stay liftable by whoever placed it. Only that administrator can clear the block.
Nothing is applied in halves. If any part of the request is refused, no part of it takes effect and you never see a half-archived subtree.
Every resource changed as a consequence records that it was indirect, and which request caused it.

Restoring with force brings back everything inside, including a workspace that somebody archived separately long before the parent was. Setting the flag is the statement that you want the contents back, and each of those changes is recorded as indirect so the reversal is attributable. Without it, restoring returns only the resource you named and leaves everything inside it archived. A resource can only return to active where its parent is already active, so restore from the outside in.

Deletion process

Deleting is refused unless the resource is already archived, so destroying something always takes two deliberate acts: archive it, then delete it. You choose how much time passes between them. There is no timer and nothing deletes itself.

This is a safety feature. Archiving is fully reversible, so the first act is cheap to undo, and it stops the resource from being used in the meantime. Anything you archived by mistake shows up as an outage long before the second act, which is the irreversible one.

sequenceDiagram
  autonumber
  participant Admin as Organisation administrator
  participant Taxonomy as taxonomy
  participant Audit as Audit history

  Admin->>Taxonomy: Archive the resource
  Taxonomy-->>Admin: Archived, changes refused, data kept
  Note over Admin,Taxonomy: Reversible. Restore at any time, with no deadline.
  Admin->>Taxonomy: Delete the resource
  Taxonomy->>Taxonomy: Check it is archived and empty
  Taxonomy-->>Admin: Deleted
  Taxonomy->>Audit: Keep the full history

A parent must also be empty to be deleted. Unlike archiving, an archived child still blocks deletion, because it is still a resource that belongs to the parent, and there is no way to ask for the contents to be deleted along with it. Deletion is always one resource at a time, on purpose.

Deleting an organisation is therefore: archive and delete each workspace, archive and delete each group, then archive and delete the organisation.

The audit history outlives the resource. Records of what happened are never removed along with the resource they describe, so after a deletion you can still see who created, suspended, archived, restored, and deleted it. That is what makes an irreversible deletion acceptable.