Spaces

A space divides an organization's work and decides who can reach it. Models live in spaces, and a space is where access is granted — not on each model one by one.

That is the point of them. Granting someone access to a space gives them everything in it, now and in future, instead of a share for every model you create.

The three kinds

Every space is one of three kinds, and the kind decides where it can sit.

Restricted is the ordinary top-level space. It is not advertised to the organization — its name reaches people through a link you send them, or through a grant.

Sealed is a Restricted space with a wall around it. See sealed spaces below.

Open spaces nest. An Open space inherits everything from the space above it: who can reach it, at what level, and whether it sits inside a wall. It cannot exist at the top level, because an Open space with no parent has nothing to inherit — which is simply a Restricted space.

The rule in one line: Open nests, Restricted and Sealed are roots. Sealing a space detaches it from its parent, because a wall cannot inherit access from outside itself.

Creating one

Any member of an organization can create a top-level space, and whoever creates it becomes its first manager.

A manager can then create Open spaces inside it, and can grant that right to other people or to a team.

Roles in a space

Roles inherit down into Open sub-spaces. A collaborator on a parent is a collaborator on everything Open beneath it.

Two things about managers are worth knowing:

Managers are named individuals, never a team. The managers of a space are the owners of every model in it, and team membership is edited elsewhere by someone who cannot see what it would confer. If teams could be managers, adding someone to a team would silently make them an owner of models they have never seen. Collaborator and viewer can be granted to a team.

A viewer is implied. Anyone who is a collaborator or manager can also view, so you never grant both.

You can grant access to people outside the organization. They appear as Guest in the access list.

Organization owners and admins

An organization's owners and admins govern every space — they can manage access, delete a space, and appoint a manager to one that has lost its own.

What they do not get is standing read access. Governing a space does not let you read what is in it. To look inside, an admin has to grant themselves access, which is visible in the access list and recorded in the governance log.

That is deliberate: it makes reading someone's space an audited act rather than a silent privilege.

A space with no manager

If the last manager leaves or is removed, the space is left with nobody who can grant access to it, and the settings page says so: "This space has no manager".

An organization owner or admin fixes it with Assign manager. This is the reason the Spaces section stays visible even in a personal organization — it is the one place a stranded space can be given a manager again.

When removing the last manager, the app warns first: "Nobody owns the models inside it — until an org owner or admin appoints a manager."

Sealed spaces

Sealing puts a wall around a space. The confirmation states exactly what changes:

Nothing will inherit in. The space becomes invisible to non-members and its data cannot leave: no exports, no copies, no outbound imports, no per-model sharing. Access is granted on the space itself.

So inside a sealed space:

• Nothing inherits in. Access must be granted on the space itself.
• Nothing leaves. No exports, no copies, no importing its tables elsewhere, no sharing an individual model out of it.
• It is invisible to anyone without a grant.

Every Open space nested inside a sealed one sits inside the same wall. A space is inside at most one wall — walls do not nest, because a sealed space has no parent.

Unsealing

Unsealing is declassification, and it is not the manager's to do. Only an organization owner or admin can unseal a space.

The reason is that a manager operates inside the wall and can appoint more managers, so a manager-held unseal would be self-administered — the wall would only hold until someone inside decided otherwise.

What unsealing does:

Exports, copies and sharing are re-enabled. Sub-spaces that only inherited the wall are unsealed; sub-spaces sealed in their own right are unaffected. Inherited access is not restored and existing grants are unchanged.

Note the two things it does not undo: access that was lost when the space was sealed does not come back, and a sub-space that was sealed in its own right stays sealed. Unsealing is recorded in the governance log.

Deleting a space

Deleting a space takes everything under it — every nested space, and every model in any of them.

1. Open space settings and choose Delete space.
2. Read the analysis, which lists what will go, including the people whose only access is through this space.
3. Type the space name to confirm.
4. Confirm.

Then:

• The space and every live space beneath it enter a 30-day window.
• Every model under it goes to the Trash on the same clock.
• Models outside the space that imported from it lose their source.

Nothing is spliced out or re-homed. A space that is already in its own deletion window joins the act, and its clock restarts with the rest.

During the window the whole subtree can be brought back, models included. Cancel from the organization's Spaces section, where doomed spaces carry a badge and a Cancel action. Cancellation is done on the root of the deletion — cancelling a nested space alone is refused, and the message names the root to use instead.

Doomed spaces are hidden from ordinary working surfaces during the window, so nobody builds on something that is about to disappear.