§ Platform / Workspaces
Governance that actually binds.
A Workspace governs a team's work: membership and roles from owner to viewer, policies the interface cannot override, and audit-grade logs of who did what, when. Everything is enforced at the server and in the database — never in the client, where a rule would be only a suggestion. Governing is the Workspace's one job; four sibling concepts carry the others.
One job per concept, kept distinct
| Concept | Axis | What it is |
|---|---|---|
| Pack | ships | A signed, versioned bundle carrying everything it depends on — the thing that gets shipped. |
| Listing | sells | A commerce record pricing one released version; the work itself knows nothing about being sold. |
| Workspace | governs | A team's roles, enforceable policy, and audit scope. |
| Repository | curates | A named, version-pinned shelf of anything you want to hand over as a set. |
| Pool | computes | A cohort of devices running one Job together, under an explicit trust regime. |
One axis each, by design: a Workspace never ships, a Pack never sells, a Pool never governs.
The moment work is shared, five ways to group it appear — and each answers exactly one question. A Pack ships, a Listing sells on the marketplace, a Workspace governs, a Repository curates, and a Pool computes. They are deliberately not interchangeable: none is a mode of another, and none ever does two jobs. When you know which question you are asking — ship, sell, govern, curate, or compute — you know which one you need.
The Repository deserves the sentence it usually loses: a named, version-pinned collection of anything — workflows, models, datasets, blocks — shared as one shelf. Pinned versions keep the shelf stable, so what a colleague opens is exactly what you curated. It carries no roles and no policies; a Repository curates, a Workspace governs. Your own shelves live on your home surface, and the guide walks through both.
Who may do what, exactly
| Role | Scope | What it adds |
|---|---|---|
| owner | the workspace itself | Full control — lifecycle, policy, membership, and every role below. |
| admin | membership, roles & policy | Adds members, sets roles and policies, queries and exports the audit log. |
| editor | the work itself | Creates, edits, and runs what the workspace shares. |
| viewer | read-only access | Sees shared work and its history; changes nothing. |
Membership and role changes are server-enforced and written to the audit log — like every other change on the platform.
Membership is the boundary. Four roles, strictly ordered — owner, admin, editor, viewer — each adding capability over the one below, and the server holds the line: adding a member, changing a role, or setting a policy is an ordinary action on the same API every client uses, checked at the server and written to the audit log. A role is an access decision, never a badge the interface draws.
The same grammar reaches individuals. Sharing one document with one colleague is a Grant — one edge per recipient, carrying its own role, expiry, and revocation — so “shared with me” is a question you ask, not a pile of copies you accumulate. Workspace roles and per-document Grants compose cleanly; neither pretends to be the other.
An enforcement boundary, not a toggle
A workspace policy can require signed content only, forbid network access outright, demand deterministic runs, or keep immutable logs with full audit trails. A policy set here is enforced, not suggested: the interface cannot override it, and neither can the Copilot, because every caller passes the same server-checked surface. It deliberately sits above personal consent — an effect you may allow working alone, a team policy can refuse for everyone.
The audit trail is something you can query, not merely something that is kept: admins ask who did what, when — as data, in the Studio or exported for the record — so accountability is itself reachable, not buried in a log file. Regulated work gets a boundary it can show an auditor, in a form an auditor can actually read.
Who can find it — and who you hand it to
Every piece of work carries a visibility — private, workspace, or public — and it moves in one direction: opening up is a deliberate step, taking it back is a distinct, audited act, and nothing leaves private without a license attached. Visibility answers who may *find* a thing. It deliberately cannot express “share this with exactly one colleague” — one setting cannot hold a list of people.
That job belongs to sharing: Grants for named people, invitations that become a Grant when accepted, and links in two honest kinds. A snapshot link freezes a committed version — unchangeable, no login needed, reproducible from the URL alone. A session link opens the living draft for real-time co-editing. And a regulated document can forbid links entirely, admitting named people only.
Three decisions never collapse into one toggle: visibility decides who finds it, a co-editing role decides who changes it, and lending a device decides who contributes compute. Joining a document to edit it is not lending your GPU — the platform keeps the three visibly separate, so you always know which one you are making.
Separation lives in the database
Isolation between teams is not an application-layer promise. Row-level security policies in the database decide who sees what, underneath every API call and every client — and those policies are generated from one source, covering visibility, workspace membership, Grants, and link-based access in a single sweep. A sharing rule exists exactly once, and the database enforces all of it.
The consequences are concrete. A bug in an interface component cannot widen access, because the database itself refuses. A revoked or expired Grant stops admitting rows at the storage layer — not in a client check that might be skipped. This is one layer of a deeper stack — sign-in, isolation, sandboxing, integrity, accountability — laid out on security and in the guide.
A team license is data, not a bolt-on
What a person may fetch — which plan they hold, which paid content they may install — is one model across the platform, and what holds a plan may be a person or a workspace. A workspace-held license is seat-pooled: members inherit it while they are members, resolved at sign-in through the same membership lookup that governs everything else. Team, course, and campus licensing are therefore data on an edge that already exists — and the same model expresses a team-held license for marketplace content as naturally as a plan.
Seats are metered like every quota: the server refuses overage loudly, with a clear upgrade path — never silently. And beneath all of it: computation is never tier-gated. A workspace license buys hosted services — storage, sharing scale, collaboration capacity — and nothing else.