Workspaces
PJ-ACC-9PJ-ARCH-5PJ-ACC-2WS-KIND-1WS-KIND-3WS-KIND-3WS-KIND-6Derived from the published System Guide. Every row cites the claim groups it renders, and every rule on it is quoted from one of them.
You are in: Workspaces. This assumes only the core model (T1).
P1.1What a workspace isPermalink
WS-WHAT-1A workspace is the container that holds projects — and, through them, tasks — and that people take part in as members.
Gen-5 describes it as the scope in which obligations were incurred: the place where work was assigned, reviewed and approved.
There are two kinds, and they are genuinely different.
Why is this true?
WS-WHAT-1Fulla fact about the sources, not a reader labelExact identity
WS-KIND-1Personal WorkspaceEvery account gets one when it signs up — always, with nothing to qualify for.
It is the baseline container every account starts from, and nothing that governs creating any other workspace can withhold it: not whether the account may create another, not permission for a template, not whether a template is on offer, not any limit. The account owns its Personal Workspace, and that ownership stays bound to the account for as long as the account exists: it cannot be handed to anyone else.
Why is this true?
WS-KIND-1Fulla fact about the sources, not a reader labelExact identity
Runtime evidence is never an authority of its own. An accepted document says the same thing first; the evidence says only that the running system agrees.
WS-KIND-5"Free" is a way of describing the Personal Workspace, not a setting in the system.
ChatWell has no plan, tier, price or subscription behind it. The rule is simply that every account gets one.
Why is this true?
WS-KIND-5Fulla fact about the sources, not a reader labelExact identity
free is positioning only; no plan, price, billing tier, entitlement tier or subscription; §1.1 Provisioning guaranteeWS-KIND-4Other people can be invited into a Personal Workspace.Partly defined
Accepting adds them to the workspace and to no project — the same rule that holds everywhere (P2.2). Its owner has that workspace's main project because the account's own setup gave it to them, not because joining a workspace hands anyone a project. Only the owner can give someone else access to that project. Partly defined.
Why is this true?
WS-KIND-4Partly defineda fact about the sources, not a reader labelExact identity
WS-KIND-2User-created workspaceCreated by a person, who becomes its owner.
Why is this true?
WS-KIND-2Fulla fact about the sources, not a reader labelExact identity
WS-KIND-3Creating any further workspace takes two separate permissions.
During the current beta an account needs both: it must be authorized to create an additional workspace at all, and the particular template it wants to create from must be permitted to it. Neither substitutes for the other — being allowed to create one is not permission for a given template, and permission for a template is not authorization of the account. Where a template sets a limit on how many workspaces it may produce, that limit applies on top of both — being authorized never overrides it.
Why is this true?
WS-KIND-3Fulla fact about the sources, not a reader labelExact identity
Runtime evidence is never an authority of its own. An accepted document says the same thing first; the evidence says only that the running system agrees.
WS-KIND-6Today both permissions are arranged by ChatWell's operators, one account at a time.
There is no screen in the product for asking for them or granting them, and no account gives them to itself. Until an operator acts, an account has its Personal Workspace and cannot create another.
Why is this true?
WS-KIND-6Fulla fact about the sources, not a reader labelExact identity
Runtime evidence is never an authority of its own. An accepted document says the same thing first; the evidence says only that the running system agrees.
WS-KIND-7Workspace templates are not offered to everyone.
Every template in use is permitted account by account: an operator names who may create from it. A template can also be retired, after which nobody can create from it. No template is open to everyone, and none is at this stage of the product.
Why is this true?
WS-KIND-7Fulla fact about the sources, not a reader labelExact identity
public Reserved, no template should be public at the current product stage; restricted default for beta; disabled retires a versionpublic remains reserved, none is public, and the grant-predicate observation is recorded as OPTIONAL future defence-in-depth hardening, not a requirement and not scheduledRuntime evidence is never an authority of its own. An accepted document says the same thing first; the evidence says only that the running system agrees.
WS-START-1A new workspace does not start empty.Partly defined
A workspace someone creates begins with a main project and a chat for it, and its creator is in that project. Partly defined: the main project is established; the rest of the starting structure comes from the template it was created from, whose wider definition is not settled. A Personal Workspace comes from no template — its starting structure arrives with the account.
Why is this true?
WS-START-1Partly defineda fact about the sources, not a reader labelExact identity
WS-LIM-1Not decided. How many workspaces an account may end up with, how they are counted, and whether any limit attaches to the account at all rather than to the template it created from.Not decided
Why is this true?
WS-LIM-1Gapa fact about the sources, not a reader labelExact identity
WS-LIFE-1ChatWell offers no way to delete a workspace.
In the product a workspace is either active or archived; there is no deleted state. The normal Workspace lifecycle uses archival rather than physical deletion of its business history. No one can archive a workspace today.
Why is this true?
WS-LIFE-1Fulla fact about the sources, not a reader labelExact identity
P1.2OwnershipPermalink
WS-OWN-1Every workspace has exactly one owner, at every moment.
There is never an ownerless workspace.
Why is this true?
WS-OWN-1Fulla fact about the sources, not a reader labelExact identity
WS-OWN-2Ownership is not a membership role.
A member's stored role is member or admin — never "owner". Who owns a workspace is recorded separately, and ChatWell states it for each workspace as a separate fact.
Why is this true?
WS-OWN-2Fulla fact about the sources, not a reader labelExact identity
WS-OWN-3The owner is also a member.Partly defined
Whoever creates a workspace becomes its owner and is also recorded as a member with the admin role; the same holds for the Personal Workspace set up with the account, which nobody creates. So today an owner's stored role reads admin, and the role alone can never tell you who owns the workspace. Ownership does not depend on that role. Partly defined.
Why is this true?
WS-OWN-3Partly defineda fact about the sources, not a reader labelExact identity
WS-OWN-4The owner of a workspace owns every project in it.
This project ownership is derived: it is never assigned, stored or handed over on its own, and it changes only when the workspace's owner changes — for every project at once.
Why is this true?
WS-OWN-4Fulla fact about the sources, not a reader labelExact identity
WS-OWN-7The owner is a member of every active project in their workspace, with the admin role, for as long as they can reach the workspace.
This is a standing guarantee, not something anyone grants — and it is a membership like any other, never a role called "owner". It is described in full in P2.2.
WS-OWN-5Ownership is never simply given up or taken away.
No action ends a person's ownership without passing it to someone else, and nobody becomes an owner automatically — not an admin, not by seniority.
Why is this true?
WS-OWN-5Fulla fact about the sources, not a reader labelExact identity
WS-OWN-6The owner cannot leave their workspace, and nobody can remove them from it.Partly defined
Partly defined.
Why is this true?
WS-OWN-6Partly defineda fact about the sources, not a reader labelExact identity
WS-OWN-1P1.3MembershipPermalink
WS-MEM-1A membership is how a person belongs to a workspace.
You become a member by creating a workspace, by accepting an invitation, or — for your Personal Workspace — by creating your account. An invitation on its own is not a membership; the membership starts when the invitation is accepted.
Why is this true?
WS-MEM-1Fulla fact about the sources, not a reader labelExact identity
WS-MEM-2Membership comes in periods.
A period starts when someone joins and ends, with a recorded reason, when they leave or are removed. An ended period is never reopened: if the person comes back, a new period starts. A person has at most one current period in a workspace, and in a project, at a time.
Why is this true?
WS-MEM-2Fulla fact about the sources, not a reader labelExact identity
WS-MEM-3Ending a membership does not erase the person.
ChatWell keeps who belonged when, and a departed person's name still shows on what they created.
Why is this true?
WS-MEM-3Fulla fact about the sources, not a reader labelExact identity
WS-MEM-4A membership alone is not enough to act.
The account must also be active, and so must the workspace.
Why is this true?
WS-MEM-4Fulla fact about the sources, not a reader labelExact identity
WS-MEM-5Leaving a workspace ends that person's project memberships in it too.
Their workspace membership stays on record with the time they left.
Why is this true?
WS-MEM-5Fulla fact about the sources, not a reader labelExact identity
WS-MEM-6The owner and admins can remove other members — never themselves, and never the owner.Partly defined
Removing someone who is the reviewer of an active task in an active project needs a replacement reviewer named as part of the removal: without one, the removal does not go through; with one, each affected task takes the replacement and its history records the change. Partly defined.
Why is this true?
WS-MEM-6Partly defineda fact about the sources, not a reader labelExact identity
WS-MEM-7One replacement stands for a whole project, and it must be someone who is not already doing the work.
The replacement named for a project takes over every affected task in it at once, so a person who is the assignee of any one of those tasks cannot be the replacement for that project — a task's assignee is never its reviewer (P3.4). Where no one can be named, the removal does not go through at all: nothing is half-done. This can even rule out the workspace owner, who can otherwise always be named as the replacement.
Why is this true?
WS-MEM-7Fulla fact about the sources, not a reader labelExact identity
Runtime evidence is never an authority of its own. An accepted document says the same thing first; the evidence says only that the running system agrees.
WS-MEM-2P1.4Roles and what they let you doPermalink
WS-ROLE-1Every member holds one of two roles: member or admin.
Projects use the same two values. There is no third stored role.
Why is this true?
WS-ROLE-1Fulla fact about the sources, not a reader labelExact identity
WS-ROLE-2Authority is compared on a three-step ladder: member, then admin, then owner.
The owner's step comes from owning the workspace — and, in each of its projects, from being the workspace's owner — never from a stored role.
Why is this true?
WS-ROLE-2Fulla fact about the sources, not a reader labelExact identity
WS-ROLE-3Authority is not access.
A role says what you may do; whether you can act at all depends on a current membership, an active account and an active workspace. Admin powers count only while the person is a current member.
Why is this true?
WS-ROLE-3Fulla fact about the sources, not a reader labelExact identity
WS-ROLE-4The role is chosen when someone is invited.Partly defined
The owner or an admin sends the invitation and chooses member or admin; accepting it gives that role. An admin may invite someone as an admin. Partly defined. The governance model describes granting the admin role as the owner's act; no registered document describes admins granting it through an invitation.
Why is this true?
WS-ROLE-4Partly defineda fact about the sources, not a reader labelExact identity
WS-ROLE-5Roles belong to one workspace, or one project.
The same person can be an admin in one workspace and an ordinary member in another — and a workspace admin can be an ordinary member of a project, or not in it at all.
Why is this true?
WS-ROLE-5Fulla fact about the sources, not a reader labelExact identity
WS-ROLE-6This concerns only the workspace role after joining.
Choosing the role at invitation works today, and changing a person's role inside a project works today, for the workspace owner (P2.2).
Why is this true?
WS-ROLE-6Partly defineda fact about the sources, not a reader labelPartly defined. How to read: ✓ may, — may not; a cell that says more than yes or no says it in words, and a cell naming a state label carries that state. "Admin" means a workspace admin. Every action also needs a current membership.
| Action | Member | Admin | Owner |
|---|---|---|---|
| Rename the workspace | — | — | ✓ |
| Invite someone, as member or admin | — | ✓ | ✓ |
| Remove another member (never the owner) ² | — | ✓ | ✓ |
| Create a project | — | ✓ | ✓ |
| Leave the workspace ¹ | ✓ | ✓ | — |
| Change a member's workspace role after joining | — | — | Decided — not currently available (DNA-6) |
¹ Sources disagree on what happens when the person leaving is the reviewer of an active task, or a project's default reviewer, in an active project (SD-1, P3.4). ² Removing someone who reviews active tasks needs a replacement reviewer named as part of the removal, and not everyone can be that replacement: a removal can fail for want of a valid one (WS-MEM-6, WS-MEM-7).
Why is this true?
WS-MX-1Partly defineda fact about the sources, not a reader labelExact identity
What this means for a prototype — WorkspacesPermalink
Every entry names the claim groups or records it derives from. It carries no state of its own; the state shown on each chip is that of the group or record cited.
MUST PRESERVE
- Ownership is its own fact about a workspace, separate from anyone's role; an interface must never derive it from, or present it as, a role value.from
WS-OWN-2WS-OWN-3 - Every workspace has exactly one owner at every moment.from
WS-OWN-1 - The Personal Workspace and user-created workspaces are distinct kinds.from
WS-KIND-1WS-KIND-2 - Roles belong to one workspace or one project; the same person can hold different roles in different places.from
WS-ROLE-5 - An ended membership stays ended; coming back is a new membership.from
WS-MEM-2 - Every account has its Personal Workspace unconditionally; nothing an operator, a catalogue or the beta programme controls can withhold it.from
WS-KIND-1 - Authorization to create a further workspace and permission for a template are two separate permissions; an interface must not merge them into one idea of "access".from
WS-KIND-3
MUST NOT ASSUME
- That a member's role can read "owner", or that the owner can be found from roles.from
WS-OWN-2WS-OWN-3 - That an owner can hand over, or leave, their workspace today.from
WS-OWN-6DNA-1 - That a workspace can be archived, or deleted, from inside ChatWell today.from
WS-LIFE-1DNA-2 - That an owner can change a member's workspace role after they joined, today.from
DNA-6 - That a workspace role is fixed forever: Gen-5 has decided the owner may change it, though that is not available today.from
DNA-6 - That an account can create a further workspace: during beta it needs authorization and a permitted template, and an account has neither until ChatWell's operators grant them.from
WS-KIND-3WS-KIND-6 - That the product offers a way to ask for, or grant, that authorization.from
WS-KIND-6 - That "free" describes a plan, a tier or a price. It describes only that every account has a Personal Workspace.from
WS-KIND-5 - That a template is available to everyone: none is, at this product stage.from
WS-KIND-7 - That removing a member always succeeds without naming a replacement reviewer, or that any member can be that replacement.from
WS-MEM-6WS-MEM-7 - That leaving always succeeds: the owner cannot leave, and for a reviewer of active tasks the sources disagree.from
WS-OWN-6SD-1
Where this comes from — WorkspacesPermalink
Where this comes from32 claim groups
| Claim group | Covers | State | Coverage | Sources |
|---|---|---|---|---|
WS-WHAT-1 | What a workspace is | Works today | Full | Workspace & project lifecycle model · Membership model · Accepted Gen-5 implementation |
WS-KIND-1 | Personal Workspace, unconditional | Works today | Full | Beta workspace creation decision · Default template contract · Workspace templates runbook · Accepted runtime evidence (R1–R4) · Gen-5 lifecycle decisions · Workspace & project lifecycle model · Accepted Gen-5 implementation |
WS-KIND-5 | "Free" is positioning, not a setting | Works today | Full | Beta workspace creation decision · Default template contract · Accepted Gen-5 implementation |
WS-KIND-4 | Others in a Personal Workspace | Works today | Partly defined | Project access policy decision · Membership model · Accepted Gen-5 implementation · Workspace & project lifecycle model |
WS-KIND-2 | User-created workspace | Works today | Full | Gen-5 lifecycle decisions · Accepted Gen-5 implementation |
WS-KIND-3 | A further workspace takes two permissions | Works today | Full | Beta workspace creation decision · Workspace templates runbook · Accepted Gen-5 implementation · Accepted runtime evidence (R1–R4) |
WS-KIND-6 | Operator-conferred, no product screen | Works today | Full | Beta workspace creation decision · Workspace templates runbook · Accepted Gen-5 implementation · Accepted runtime evidence (R1–R4) |
WS-KIND-7 | Template availability today | Works today | Full | Workspace templates runbook · Beta workspace creation decision · Accepted Gen-5 implementation · Accepted runtime evidence (R1–R4) |
WS-START-1 | Starting structure | Works today | Partly defined | Membership model · Default template contract · Accepted Gen-5 implementation |
WS-LIM-1 | How many workspaces | Not decided | Gap | Decision Index · Beta workspace creation decision |
WS-LIFE-1 | No deletion; archival ends the lifecycle | Works today | Full | Workspace & project lifecycle model · Gen-5 lifecycle decisions · Accepted Gen-5 implementation |
WS-OWN-1 | Exactly one owner | Works today | Full | Workspace & project lifecycle model · Accepted Gen-5 implementation |
WS-OWN-2 | Ownership is not a role | Works today | Full | Workspace & project lifecycle model · Accepted Gen-5 implementation |
WS-OWN-3 | Owner is also an admin member | Works today | Partly defined | Workspace & project lifecycle model · Accepted Gen-5 implementation |
WS-OWN-4 | Derived project ownership | Works today | Full | Workspace & project lifecycle model · Accepted Gen-5 implementation |
WS-OWN-7 | Owner is an admin member of every active project | Works today | Full | via PJ-ACC-6 |
WS-OWN-5 | Ownership never simply ends | Works today | Full | Workspace & project lifecycle model · Accepted Gen-5 implementation |
WS-OWN-6 | Owner cannot leave or be removed | Works today | Partly defined | Accepted Gen-5 implementation |
WS-MEM-1 | How membership starts | Works today | Full | Membership model · Accepted Gen-5 implementation |
WS-MEM-2 | Membership periods | Works today | Full | Membership model · Accepted Gen-5 implementation |
WS-MEM-3 | Who belonged when is kept | Works today | Full | Membership model · Identity invariants · Accepted Gen-5 implementation |
WS-MEM-4 | Membership is not enough to act | Works today | Full | Membership model · Accepted Gen-5 implementation |
WS-MEM-5 | Leaving ends project memberships | Works today | Full | Membership model · Accepted Gen-5 implementation |
WS-MEM-6 | Removing members | Works today | Partly defined | Accepted Gen-5 implementation · Membership model · Task lifecycle & assignment model · Task operation contract |
WS-MEM-7 | One replacement per project, never its assignee | Works today | Full | Task reviewer authority decision · Task lifecycle & assignment model · Task operation contract · Accepted Gen-5 implementation · Accepted runtime evidence (R1–R4) |
WS-ROLE-1 | Two stored roles | Works today | Full | Workspace & project lifecycle model · Accepted Gen-5 implementation |
WS-ROLE-2 | Authority ladder | Works today | Full | Workspace & project lifecycle model · Source of Truth Map |
WS-ROLE-3 | Authority is not access | Works today | Full | Workspace & project lifecycle model · Accepted Gen-5 implementation |
WS-ROLE-4 | Role chosen at invitation | Works today | Partly defined | Accepted Gen-5 implementation · Membership model · Workspace & project lifecycle model |
WS-ROLE-5 | Roles are per place | Works today | Full | Workspace & project lifecycle model · Accepted Gen-5 implementation |
WS-ROLE-6 | What the role change does not affect | Works today | Partly defined | via WS-ROLE-4, PJ-ROLE-1 |
WS-MX-1 | Workspace actions by level | Works today | Partly defined | Accepted Gen-5 implementation · Workspace & project lifecycle model |
Coverage is a fact about the sources, not a reader label. Gap is not one of the five labels.