Workspace lifecycle operations

Beyond cloning and migrating, a workspace has a set of smaller, everyday mobility operations, handing over custody, renaming, reclassifying, snapshotting, reshaping, isolating, and retiring. Every one is a governed, fail-closed operation recorded on the mobility activity ledger, and every one respects the home invariant: an operation that would leave an entity unaddressable refuses.

The operations at a glance

Figure: the lifecycle operations. Each acts on one workspace and leaves a activity-ledger record. Color marks intent, not severity: green is a recoverable point-in-time capture, cyan reshapes boundaries, amber is incident isolation, and red is retirement, each recoverable in its own way.

Table equivalent

Operation	Changes	Identity/address	Refuses when
Delegate / succeed	Who operates the workspace	Unchanged	Cross-scope custodian; revoke under legal hold
Rename + alias	The name-bound routable address	Id and inbox unchanged	Name collides with a live name
Promote	workspace_type and the routing root	Id unchanged	Would leave the entity with no default
Snapshot / rollback	Captures / restores state	Unchanged	Digest mismatch (rollback)
Merge / split	Which resources belong to which workspace	Split mints new id/address	Collision (merge); merging away a default
Quarantine	Read + delivery access	Unchanged	Release without a lift authorization
Archive / restore	Lifecycle stage; cold placement	Unchanged

Delegate custody and succession

Handing over a workspace does not require the owner to leave. Delegation grants a custodian or successor operational control while the owner stays the owner. Succession then promotes a designated successor to owner when needed, reusing the same owner-transfer machinery rather than a parallel path.

• Only the owner or an admin may delegate; a custodian from a different scope is refused.
• Legal hold wins: a revoke is refused while an active hold stands.
• Exactly one active delegation is enforced at the database.

Use delegation for planned coverage (someone operates a workspace on the owner's behalf) and succession for handover (the successor becomes the owner). Departure offboarding (re-homing and tearing down when someone leaves the organization) is a separate cascade, not this operation.

Rename with a no-loss alias

A rename changes only the name-bound routable address; the workspace keeps its id, its home, and its id-bound inbox, a rename is not a move. It is safe against in-flight resolves because of a strict ordering:

1. Insert an alias old name → workspace id (with a grace-window expiry).
2. Then update the name.
3. Record the rename on the activity ledger.

The old name therefore never resolves to nothing. A live name always beats an alias, so if someone later claims a freed name, the new claimant wins and the stale alias yields. A collision with an existing live name is refused.

Promote a default workspace to a regular one

Every entity is auto-provisioned a default workspace that keeps it addressable. Promotion reclassifies such a workspace to a regular type and atomically rebinds the routing root, it demotes the target and promotes a designated replacement default under a write lock, so the exactly-one-default invariant is never briefly violated.

You must name the replacement default

Promoting an entity's sole default refuses unless you designate a new_default_workspace_id to take over addressability, a new default is never minted implicitly. A cross-subject replacement is refused. This is the home invariant protecting the entity from being left unreachable.

Snapshot and roll back

A snapshot captures the workspace's resource-graph state, canonicalizes it, and content-addresses it (a hash seal) into the snapshot store. Identical content under the same label reuses the row (idempotent).

A rollback is verify-before-apply and deny-closed: the snapshot must exist, and its recomputed digest must equal the stored seal, both checked before any state is applied, and the apply is all-or-nothing (no partial restore) and idempotent, so a retried rollback converges rather than corrupting. Snapshot/rollback is distinct from an archive (cold retention) and from a DR backup (a replica copy).

Merge and split

Both reshape which resources belong to which workspace, built over the same resource-graph enumeration and repoint machinery as a clone, no parallel mover.

• Merge repoints every resource from the merged-away workspace onto the survivor under a conflict policy, the default is refuse on any key present in both (never a silent winner); an explicit keep-survivor policy drops the duplicate. The merged-away name is aliased to the survivor for a grace window, then that workspace is retired. Fail-closed post-conditions assert an exact union. Merging away a default is refused.
• Split partitions a workspace by a predicate, mints a new identity, address, and default/home for the moved set and repoints it, while the original keeps its inbox. A second default for the same entity is refused by the database.

Quarantine for incident response

Quarantine is forensic isolation, not a write freeze. While a quarantine hold is active, the workspace's reads and inbox/feed delivery are fenced deny-closed, and the hold carries a chain-of-custody record (who, why, incident reference, attestation). It can optionally re-point the home to an isolation sink. Release requires an explicit, non-empty lift authorization, a deny-closed re-attestation, so a quarantine cannot be lifted by accident.

Quarantine vs write-freeze

These are different controls. Quarantine fences reads and routing for incident response. A write-freeze is the archive-only control that blocks writes but not reads or routing. It is what gives an in-place archive its teeth, not an incident tool. Do not conflate them.

Archive and restore

Archive retires a workspace to cold storage in one of two ways, and restore brings it back:

• In-place archive sets the lifecycle stage to archived with no data movement; the write-freeze then makes it read-only.
• Tiered archive deep-clones the workspace to a cold service group, seals the copy as immutable retention, soft-deletes the hot resources, and leaves the source row as a tombstone pointer to the sealed archive. The seal happens before the hot copy is dropped, so the archive is durable before the original is removed.
• Restore returns the workspace to active (unfreezing writes) and, for a tiered archive, rematerializes it by cloning the sealed copy back.

A later retention sweep purges sealed archives past their window. Full teardown (soft-delete versus a hard purge with cryptographic erasure) is a separate, depth-aware operation.

Across the deployment matrix

Corner	How these operations behave
Single-cell	Rename, promote, snapshot/rollback, quarantine, and in-place archive run locally; a tiered archive needs a cold target
Multi-cell	Merge/split and tiered archive repoint across cells; residency and protection bound where copies land
Cross-organization	Custody, rename, and promote are in-org; moving a workspace to another org is a cross-org migrate
Sovereign / air-gapped	All operations are cell-local and need no vendor cloud; sealed archives and snapshots verify locally

Related topics

• Workspace mobility, the umbrella model and the home invariant.
• Migrating a workspace, the identity-preserving move.
• Cloning: the copy-on-write engine merge, split, and archive reuse.
• Disaster recovery, failover, distinct from snapshot and archive.
• The two work boundaries, what a workspace and a clean room are.