Capacity and placement
A workspace is a governance boundary, but work has to run somewhere. This page is how a workspace is bound to real compute: which cells serve it, how much of them it is entitled to, and what the platform refuses when the arithmetic stops adding up.
Service groups are the acquisition unit
A service group is a set of cells grouped for a purpose, and it is also the unit a capacity decision is expressed in. A capacity contract sizes and owns a service group: a department buys N cells, and that quantity drives the group's physical ceiling, so the reconciler and the quota gate honor it rather than treating it as advice.
Because cells, nodes and service groups are free and unlimited as infrastructure, the contract is about entitlement and accounting, not a charge for the shape of the deployment. You are not billed for splitting into more groups.
Binding a workspace to capacity
A workspace is bound to a contract's service group, and the binding carries two things: a share mode and a share percentage.
| Share mode | Meaning |
|---|---|
| Reservation | The workspace holds a guaranteed slice of the group. Reservations are additive and are capped |
| Other modes | A workspace can be bound without reserving a guaranteed slice, drawing on the group's shared headroom instead |
The reservation cap is the rule worth knowing: reservation shares across a service group cannot exceed 100%. A bind that would push the sum past the ceiling is refused, naming the group, the existing sum and the requested share, and telling you to reduce a peer share first. The platform does not accept an overcommitment and discover it later under load.
Dedicating cells to one workspace
The useful consequence of that arithmetic: bind a single workspace at a 100% reservation share and the whole service group is dedicated to it. Its cells serve that workspace and nothing else competes for a guaranteed slice of them, because no peer reservation can be added without exceeding the ceiling.
That is the mechanism behind a dedicated deployment:
- A workspace whose workload must not share cells with anything else.
- A clean room that has to run on cells no other party's work touches.
- A classification or residency boundary that is easier to argue when it is physical as well as logical.
- A noisy or bursty workload isolated so it cannot crowd out its neighbours.
Figure: a capacity contract sizes a service group. A group can carry several workspaces whose reservations sum to at most 100%, or one workspace at a full 100% reservation, which dedicates the group's cells to it. A bind that would push the sum over the ceiling is refused (amber) rather than accepted and discovered under load.
Table equivalent
| Shape | Reservations | Result |
|---|---|---|
| Shared group | Several workspaces, summing to 100% or less | Each holds its guaranteed slice |
| Dedicated group | One workspace at 100% | The group's cells serve that workspace alone |
| Over-committed | A bind that would push the sum past 100% | Refused, naming the group and the existing sum |
What else is refused
Capacity is one of the places the platform is most willing to say no, because the alternative is an estate that has promised more than it has.
- Shrinking a contract below its deployed cells is refused. You cannot size away capacity that is already carrying work.
- Growth past the licensed cell cap is scored net-negative at the decision gate, so it does not pass on an operator's say-so alone.
- A large growth step is flagged for splitting into smaller steps. This one is a warning rather than a block, and the call stays with the owner.
Capacity you can see
A workspace's capacity is a surface, not a mystery. Capacity gauges show a workspace's share of its group, its banked headroom, its burst standing, and any compensation actions in flight.
That last one is the platform's posture in miniature. Sustained over-use is answered with rebalance and compensation before refusal, and a transient spike is not treated as damage at all. Only a sustained breach is, and it is reported as debt owed compensation rather than as an alarm to acknowledge.
Placement and residency
Capacity says how much. Two other constraints say where.
Residency is pinned on the workspace or clean room itself as a cell selector, and it is re-resolved against live fabric membership on every placement and egress decision, so failover never crosses the pinned boundary. It can be pinned at any level of the physical hierarchy, region, zone or rack, plus the orthogonal cloud-provider dimension. A required residency constraint that no live cell can satisfy refuses rather than quietly degrading to the wrong jurisdiction.
Clearance is a hard placement constraint. A workflow cannot execute on a cell below the required clearance, and that is scored before any of the soft criteria like GPU availability, model availability, data locality or cost.
Related
- Workspaces and clean rooms, the boundary being placed.
- Data residency, pinning in full.
- Deployment topology, the region, zone, rack and cell hierarchy.
- The cell model, what a cell is.
- Metering, FinOps & tokenomics, what is actually charged.