One directory for people, machines and AI
Six crypto-bearing principals share one foundation, one authorization path and one cryptographic identity: organization, user, node, device, agent and service account , each holding an entity id in the directory and its own certificate policy. The governance concepts that are not principals (group, role, policy and domain) live in their own tables and are never keyed as entities, and there is no organizational-unit entity: “organizational unit” exists only as an X.509 subject field on an issued certificate, not as an identity in the directory. There is no separate machine-identity bolt-on, no separate agent registry and no separate device directory.
An AI agent is looked up, granted, audited and billed by the same machinery as a person, which is the reason every other claim on this site is possible.
| Level | What it is |
|---|---|
| Organization | The top boundary. Mints nodes, owns users, agents and policy, holds a certificate authority. An organization can be moved under another, transferring ownership with recorded consent. |
| Node | A cryptographic identity over a set of cells that may span clouds and regions. It survives cell replacement, so a cell can die without the estate losing an identity, a history or a peer relationship. |
| Service group | Cells grouped for a purpose, an erasure set, a replication group, a workload boundary. |
| Cell | The unit of deployment: a complete instance of the platform with its own databases, object store and service processes. Not a worker node. |
| Air-gapped cell | Modelled as an absent edge rather than a failed peer to retry, every rival treats a partition as an error condition. |
| Edge Agent | A signed binary on a field device, holding a delegated identity from a parent entity. |
Configuration is derived from intent, and every cell attests what it applied
Materialising correct configuration per cell, for a thousand cells, by hand, is not a strategy. So an operator declares a capability at a high semantic level and the worker set derives from it through a dependency graph. Turn off a data capability and the worker that services it derives off. Nobody toggled a worker.
It is one plane, not two. The same signed engine governs configuration itself, every cell setting resolves as base defaults overlaid by signed policy matched to the cell's place in the topology, narrowest scope winning. Configuration is a property of the cell and where it sits, organization, node, service group, zone, rack, cell profile, or a single cell, so it stays correct as the fleet grows and shrinks, with no separate settings store to drift out of step.
Signed policy over replication, not file push
A policy is authored through a control-plane API, signed by the issuing entity, written to a directory-replicated table and propagated by the existing replication scopes. A cell verifies before applying, rejects an unsigned or badly-signed policy, and holds last-known-good. Versions are monotonic, so a replayed policy cannot roll a cell backwards.
Targeting by selector, never by cell list
Disable a capability across a region with one signed edit rather than a thousand. A newly joined cell inherits its effective configuration during join, before it serves traffic, so a cell is never live but ungoverned.
Local edits are reconciled away
Cell configuration is read-mostly with provenance. A local change is an audited, reason-prompted, time-boxed break-glass pin that the reconciler reverts unless explicitly held.
And every cell attests back
On each reconcile tick a cell emits a signed effective-configuration attestation (what it applied, its capability state, its worker set, any drift, any active pins) hash-chained into the audit. Distribution alone would be write-only.
One plane for every setting, delegable by section
The same signed engine governs configuration, not just worker enablement: the nine administrative areas (identity, security, catalog, data, AI, workspaces, node, fleet, organization) and services such as Arrow Flight SQL, all authored the same way. Authorization is tiered and deny-by-default: a full cell operator, or a delegated administrator holding only one area's permission, so a security lead owns security configuration without the keys to the rest.
Every change is a signed audit row
Authoring writes a tamper-evident config-change record for each key changed, which setting, at which topology scope, from what value to what, by whom. Who changed which setting, where, is always answerable.
A disconnected cell stays governed: it enforces last-known-good signed policy and keeps reconciling locally, accepts new policy by signed offline bundle verified on import, and flushes queued attestations on reconnect so the fleet view back-fills its observed history.
The deciding question is never how sensitive the data is
It is how many trust domains are in the room. One → a workspace, where members trust each other and isolation is between workspaces. Two or more that must collaborate without trusting each other → a clean room, which layers a mutual-distrust enforcement model on a host workspace.
| Mechanism | What it does |
|---|---|
| Asset aliasing | The only name another collaborator ever sees is a per-room alias. Code is alias-rewritten before compute, so the kernel never sees source table names, and a result un-aliases only the recipient's own names. |
| Approval-gated, signed code | Reviewed and cryptographically signed by several reviewers before it can run. An edit resets approval. |
| The egress gate | Every output passes, in order: anonymity threshold, output-row cap, per-collaborator privacy budget, per-run ceiling, destination allow-or-deny defaulting to deny, and content inspection. First failure terminates the run. |
| Per-room keys | Crypto isolation per room, minted at creation and re-sealed on any move. |
| Signed, hash-chained run audit | Every run signed, every output hashed and watermarked, and the room's activity ledger tamper-evident. |
| Governed bindings | Agents, functions and pipelines bound into a room have their authority intersected most-restrictive-wins with room policy at execution. |
| Cross-organization transfer | Default-prohibited without recorded consent from every collaborator organization, one party cannot unilaterally export another party's data and consent context. |
A new room is created deny-all by default. Clean rooms are policy-based isolation with a signed run chain, not a hardware enclave, the wedge is where the room runs: on your premises, air-gap-capable, sovereign, multi-cell.
Privacy budget
6 of 10 releases
A run that would exceed the budget is terminated on its first failing check.
Signature chain
- code signed · reviewer A
- code signed · reviewer B
- aliased, kernel never sees source names
- egress gate armed
Isn’t a platform this broad overwhelming?
It would be, shown all at once. A workspace console carries 56 capabilities, projected through one of 6 experiences, data engineering, data analyst, data science, software engineering, consulting, security, with eight cross-cutting tabs always on in every one, so governance and identity never disappear because someone switched persona.
The invariant that makes this safe is gate, don’t omit: the union of every experience’s tabs plus the always-on set equals the full set, so organising the console can never make a capability unreachable. That property is enforced by a test, not by convention.
The nearest rival concept is a platform split into named experiences you switch between, but those are separate products sharing a bill, each with its own surface. Here an experience is a view over one governed workspace: the same data, the same policy, the same audit chain, the same identity. Switching persona changes what you see, never what governs you.
A workspace is a portable unit
Not a folder that happens to have data in it. 8 planes move together, storage, data and messaging through per-service coordinators; directory, catalog, system, compute and sessions through a metadata copier, with a freeze during the transition and references repointed so they follow the move. Clone copy-on-write, deep or live-sync; archive and restore; move between organizations under quorum. A full deep clone consults the decision boundary and refuses with a 403, because duplicating all eight planes is a high-consequence act.
6 disaster-recovery operations, per workspace
Policy, readiness assessed on demand, a standby continuously following the primary, scheduled drills (recovery you have practised rather than assumed) and failover and failback in both directions with cell transition, run rehoming and completeness digests.
The record is three questions, not one
Logging asks what the software did. Audit asks what an actor did and whether the record is complete. Lineage asks where data came from. They have different stores, different guarantees, different retention and different readers, and a workspace's own operational logs are a membership right, not a purchasable capability. A customer debugging their own workspace should never hit a licence wall.
| Scope | What it covers |
|---|---|
| intra-node | Within one node's cells. |
| intra-rack | Within a rack. |
| intra-zone | Within an availability zone. |
| cross-rack | Between racks in a zone. |
| cross-zone | Between zones in a region. |
| cross-region | Between regions, the residency boundary most policies care about. |
| cross-node | Between nodes in one organization. |
| nested-organization | Into a subordinate organization. |
| cross-organization | Authenticated with a key derived from the trust edge between the two parties, never the cluster token, which a foreign organization never holds. Both sides must select the same edge to derive the same key, so revoking a partner drops an edge rather than rotating a cluster. |