Workspaces and clean rooms
Two boundaries carry ownership and collaboration across the whole platform. A workspace is the universal ownership boundary; a clean room is a mutual-distrust governance overlay laid on top of one. Both are whole, portable environments (not folders, not filters) and a clean room is a structural partition, not a view over a shared table.
Workspace: the universal ownership boundary
Every entity, a user, an agent, a node, a service account, the organization itself, is auto-provisioned exactly one workspace at creation. Provisioning is not a copy of a template a customer wires up later; it mints the whole environment in one step:
A workspace belongs to a node, the identity a group of cells shares, and runs across that node's cells. It is not a property of any single cell, which is why a cell can be added, replaced or rebuilt underneath it without the workspace moving or being rebuilt with it.
- a dedicated storage namespace (isolation is structural, not a prefix convention),
- a messaging inbox,
- a feed,
- default streams, and
- an owner membership row.
Access is by membership role (owner, editor, contributor, viewer) or group grant, enforced at the gateway, and an access profile (open, restricted, sensitive, regulated) classifies the data the workspace holds. Every asset, table, message, model, and job belongs to a workspace, and a read is evaluated in the context of the workspace it runs in.
Clean room: a governance overlay on a workspace
A clean room lets competitors or coalition partners compute jointly without trusting each other with raw inputs. It is not a separate, reduced surface: it is the workspace console, scoped to the room, with the collaboration governance layered on as the "clean" part. Everything you can do in a workspace, you can do in a clean room, with the collaboration guarantees built in.
*Figure: the two boundaries. The single-border box is a workspace, the universal ownership boundary auto-provisioned for every entity with its storage namespace, inbox, feed, streams, and owner membership. The double-border box is a clean room, a mutual-distrust governance overlay laid on a host workspace, adding parties, a differential-privacy budget, an egress/DLP gate, and cross-party graph gluing, the amber controls are all deny-by-default, and a new room is deny-all until grants are made.
Table equivalent
| Boundary | Glyph | What it is | What it carries |
|---|---|---|---|
| Workspace | single border | Universal ownership boundary, one auto-provisioned per entity | Storage namespace, inbox, feed, default streams, owner membership; role- or group-based access; an access-profile classification |
| Clean room | double border + party divider | Mutual-distrust governance overlay on a host workspace | Parties with per-room roles, a differential-privacy budget, an egress/DLP gate, cross-party graph gluing: a structural partition, deny-all by default |
The egress gate: an ordered, fail-first cascade
The defining clean-room guardrail is the egress gate: every output passes through an ordered cascade, and the first failure terminates the run. No output leaves except through it.
| Order | Check | Effect on failure |
|---|---|---|
| 1 | k-anonymity | Terminate |
| 2 | Max-output-rows cap | Terminate |
| 3 | Per-collaborator differential-privacy budget | Terminate |
| 4 | Per-run epsilon ceiling | Terminate |
| 5 | Destination allow / deny (default deny) | Terminate |
| 6 | DLP inspection | Terminate |
Alongside it: asset aliasing (a collaborator only ever sees a per-room alias, and notebook bodies are alias-rewritten before compute so the kernel never sees a source table name), approval-gated, signed notebooks (M-of-N review; an edit resets approval), output watermarking and hashing, a per-room key with rotation, and a signed, hash-chained run audit. Any agent, function, or pipeline bound into a room has its authority intersected most-restrictive-wins with room policy at execution.
Clean rooms are policy-based isolation with a signed run chain, not a hardware trusted execution environment, the signed, tamper-evident run audit is the documented compensation for not having an enclave. The approval, signing, aliasing, and egress machinery is real and describable; the compute path behind it is complete. A workspace is fully mobile across cells (clone, migrate, snapshot, archive, and failover) but a clean room is single-cell for cross-cell recovery today: the room-clone primitives and the fail-closed cutover admission gate are real, while carrying a room's differential-privacy budget and output-review posture across cells for an in-flight run is in progress. The wedge is where the room runs: on-prem, air-gap-capable, sovereign.
Promoting a clean-room result
A joint result computed under mutual distrust can be promoted into a governed data product, which is the commercially interesting end of a clean-room engagement: the output becomes a first-class, owned, contract-bearing asset rather than a one-off export.
Across the deployment matrix
- Single-cell, a workspace or clean room is a local boundary the engine enforces on every read; a clean room runs on one cell.
- Multi-cell, a workspace boundary spans cells, keeping its scope as assets replicate, and the whole environment is mobile across cells, clone, migrate, snapshot, archive, and failover; clean-room cross-cell in-flight recovery is in progress.
- Sovereign / air-gapped and cloud-enabled: boundary enforcement is a property of the local engine, so it holds identically with or without connectivity, and a clean room needs no vendor's cloud to run.
Related
- Logical databases, the domain partitioning these ownership scopes sit inside.
- Governed reads, the row filters and masks a workspace read carries.
- The virtual graph, cross-party graph gluing inside a clean room.
- The entity & identity model, the entities that each get a workspace.
- Workspace mobility, how a workspace is cloned, migrated, reshaped, and retired across cells.