Claim states and records
DNA-1DNA-10DNA-11DNA-12DNA-13DNA-2DNA-3DNA-4DNA-5DNA-6DNA-7DNA-8TK-CONT-1TK-DEL-2TK-HIS-6TK-HIS-7WS-LIM-1XD-ARCH-3XD-SUP-0SD-1SD-2Derived from the published System Guide. Every row cites the claim groups it renders, and every rule on it is quoted from one of them.
Three registers, three different things. Decided — not currently available is a decision held in a register. Not decided means the product meaning itself is not frozen. Sources disagree means two authorities state incompatible outcomes and the guide chooses neither. They are never one list, one filter value or one count.
The five labels are defined in T0.1. This lens holds the records the chapters point to. Records take two shapes. A DNA record is written in full in the L1.1 register, and each of its anchors carries a short notice that names the record's capability and adds nothing the record does not state. An SD record is written in full at its anchor, where the disagreement arises; L1.3 lists it with its question, and any other section that meets it carries a short notice pointing to it. Representation B — the rendered presentation of this same guide, which carries nothing this guide does not state — shows each notice as written and renders the full records in its registers.
L1.1Decided — not currently available: recordsPermalink
Each record states the capability, the decision, and what happens today. The decision is never written as current behaviour. Entries are ordered by domain, not by priority. A record leaves this register once its capability works: the guide then states the behaviour where it belongs, and the record's identifier is retired rather than reused, so the numbering here has gaps.
DNA-1Transferring ownership of a user-created workspacePermalink
handing ownership of a user-created workspace to another member.
no one can transfer a workspace. The owner of a workspace cannot hand it to someone else, cannot leave it, and cannot be removed from it.
The decision, and where it is anchored
the decision is that ownership moves only by an explicit transfer, in two steps: the owner offers ownership to an existing active member, and it moves only if that member accepts. An offer can be declined or cancelled, and expires after 14 days; only one offer can be open at a time. A transfer moves who owns the workspace: nobody's workspace role changes and nobody's access is interrupted. Inside each active project the incoming owner takes up the standing membership that comes with owning the workspace (PJ-ACC-6) — joining it if they were not in it, or moving up to the admin role if they were an ordinary member, without their membership being broken and started again. The outgoing owner keeps every project membership they hold: losing ownership removes none of them. A Personal Workspace is never transferred.
P1.2.
Exact identity
admin membership in every ACTIVE project; the outgoing owner keeps every project membership, transfer alone removes none, and no transfer end reason is created or overloadedDNA-2An owner choosing to archive a workspacePermalink
the owner of a user-created workspace choosing to archive it.
no one can archive a workspace from inside ChatWell.
The decision, and where it is anchored
the decision is that only the owner may choose this, after confirming their identity again and confirming explicitly. If other members remain, a 14-day notice period runs, during which the owner can cancel; every member is given notice of the effective date and its effect on their access. Archiving a workspace archives all its projects, closes their unfinished tasks and ends everyone's access at once.
P1.1.
Exact identity
DNA-12Archiving a Personal WorkspacePermalink
a Personal Workspace being archived.
no Personal Workspace can be archived; a request to delete an account is only recorded.
The decision, and where it is anchored
the decision is that a Personal Workspace is archived only together with its account, when the account is deleted — confirming the deletion is the owner's authorization. It cannot be deleted on its own while the account exists, and its ownership never moves.
P1.1.
Exact identity
DNA-13Restoring a workspace owner's accessPermalink
a workspace owner who has lost access to their own workspace being brought back to it.
nothing in ChatWell ends an owner's access to their own workspace, and nothing restores it.
The decision, and where it is anchored
the decision is that whatever operation restores that access must, in the same step, put the owner back into every active project of the workspace with the admin role — opening a membership where they have none, or raising an ordinary membership to admin without breaking it. Any membership opened begins at the moment of restoration; nothing is written back over the period when the person could not act.
P2.2.
Exact identity
DNA-3Governed access to archived contentPermalink
support, legal or operator staff reaching archived content.
no such channel exists; tasks in an archived project cannot be reached through ChatWell by anyone.
The decision, and where it is anchored
the decision is that archived content can be reached outside the ordinary product only through a separately governed channel: tied to a case, time-limited, least-privilege, attributed and fully audited. It never makes anyone a member again and never changes ownership.
T2.6.
Exact identity
DNA-4What restoring an archived project or workspace would doPermalink
the shape of restoring an archived project or workspace, should restoration be offered.
there is no way to restore an archived project, and no workspace can be archived in the first place.
The decision, and where it is anchored
the decision covers only restoration's shape: restoring would make the container active again, and almost nothing else. It would reinstate no former member, no former admin, no assignee, no reviewer and no chat membership; anyone who needs access would have to be added again, as a new membership, and tasks that archiving canceled would not reopen. One exception was decided later, and it is narrow: restoring a project would give the workspace's current owner back the standing membership that comes with owning the workspace (PJ-ACC-6), in the same step, provided they can still reach the workspace — and as a new membership beginning then, never the closed one reopened. Whether restoration will be offered at all is not decided (XD-ARCH-3).
T2.6.
Exact identity
DNA-5Export before a workspace is archivedPermalink
exporting a workspace's data before it is archived.
ChatWell offers no export.
The decision, and where it is anchored
the decision is that an export must be offered before a workspace is archived, and before the account loses the access needed to produce or collect it. For a user-created workspace with other active members, completing the export or explicitly waiving it is part of the closing process. Export never restores ordinary access.
T2.6.
Exact identity
DNA-6Changing a member's workspace role after they joinPermalink
the owner making a workspace member an admin, or taking the admin role away again, after they have joined.
the owner has no way to change a member's workspace role after they have joined.
The decision, and where it is anchored
the decision is that the owner may do both. Taking the admin role away is allowed only while governance stays valid — the owner can act, or another active workspace admin remains. A role change neither ends nor restarts anyone's membership.
P1.4.
Exact identity
DNA-7Suspending an account or a memberPermalink
pausing a person's ability to act without ending their relationship — for a whole account, or for a member in one workspace.
nothing in ChatWell suspends an account or a member, and nothing makes an account inactive.
The decision, and where it is anchored
the decision is that a suspended account keeps its memberships but cannot act in any workspace or project, and that suspension is not departure: it hands no one's work to anyone else.
P1.3.
Exact identity
DNA-8Governance recoveryPermalink
restoring administration of a workspace whose owner can no longer act.
no recovery operation exists in ChatWell, and only the owner can appoint project admins.
The decision, and where it is anchored
the decision is that an active workspace admin restores project administration — including appointing project admins — and that where no admin is active, a verified support process outside the product may help restore administration. Nothing ever moves ownership automatically.
the pilot describes no situation in which an owner can no longer act, and its statement about project roles is explicitly scoped to today (PJ-ROLE-1).
Exact identity
DNA-10Recording role changes in historyPermalink
every change between member and admin being recorded — who changed what, and when.
changing a project role leaves no record of the change.
The decision, and where it is anchored
the decision is that every such role change is recorded as part of the organization's history, and that an ownership transfer is never recorded as a role change.
P2.2.
Exact identity
DNA-11Choosing a project's default reviewerPermalink
setting a project's default reviewer, applied to new tasks.
no one can choose a project's default reviewer, so a task starts with a reviewer only if one is named when it is created.
The decision, and where it is anchored
the decision is that a project's owner or admins may choose a default reviewer. A new task takes it at creation unless someone names a reviewer, and later changes to the default never change existing tasks.
P3.4.
Exact identity
L1.2Not decidedPermalink
XD-SUP-0T1 · T1.4The wider Gen-5 model for these three capabilities — their lifecycle, who may do what with them, and what their states mean. No registered document defines it.XD-ARCH-3T2 · T2.6Whether restoring an archived project or workspace will be offered at all.WS-LIM-1P1 · P1.1How 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.TK-DEL-2P3 · P3.2Whether a task can ever be deleted or restored.TK-CONT-1P3 · P3.2Whether a finished task can be continued, or copied into a new task.TK-HIS-6P3 · P3.5Whether comments can ever be edited or deleted.TK-HIS-7P3 · P3.5Whether comments will have unread counts or read status. Today they have none.
7 open questions. Each is shown in place, where it arises; this view only gathers them.
L1.3Sources disagreePermalink
Two disagreements between ChatWell's authoritative sources touch this pilot, each bounded to its own question. SD-1 — what happens when a member who is the reviewer of an active task, or a project's default reviewer, in an active project leaves that project, or the workspace, on their own (P3.4). SD-2 — whom a task's history names as having acted, for the cancellations written when a person archives a project (P2.3).
SD-1's classification is itself recorded by ChatWell: the Task authority decision record states that the two sides describe different outcomes, chooses neither, and leaves the question to those sources' owners. A later decision about who may choose a task's reviewer looked at this question again and deliberately left it where it stood, so the disagreement is open by choice rather than by oversight. SD-2 is surfaced here by this guide's own reading of its sources; reporting it settles nothing and registers nothing.
Classification is the owner-frozen 'Sources disagree' recorded in the Task authority decision record. The accepted implementation was not used to adjudicate it.
Classification: Sources disagree (newly surfaced in this pilot; bounded to the actor named on archival cancellation entries). The accepted implementation was not used to adjudicate it.