How the system behaves
- 1a current membership in the workspace
- 2an active account
- 3an active workspace
- 4a current membership in that project
- 5an active project
XD-ACC-1Derived from the published System Guide. Every row cites the claim groups it renders, and every rule on it is quoted from one of them.
T2.1What sits inside whatPermalink
XD-CONT-1Containment is strict.
Each project sits inside exactly one workspace, and each task inside exactly one project. Every workspace begins with a main project.
Why is this true?
XD-CONT-1Fulla fact about the sources, not a reader labelExact identity
XD-CONT-1T2.2Belonging, and being able to actPermalink
XD-ACC-1To work on a project's tasks, several things must hold at once:
a current membership in the workspace, an active account, an active workspace, a current membership in that project, and an active project. If any of them fails, the person cannot see or change the project's tasks.
Why is this true?
XD-ACC-1Fulla fact about the sources, not a reader labelExact identity
XD-ACC-2For a project's tasks, roles and ownership decide what you may do — not whether you are in.
There they never replace membership: even a workspace's owner works on a project's tasks only through a membership in that project. What ownership does give the owner, for as long as they can reach the workspace, is that membership itself, in every active project, as a standing guarantee (P2.2) — not a way round the rule.
Why is this true?
XD-ACC-2Fulla fact about the sources, not a reader labelExact identity
T2.3Owning and administeringPermalink
XD-GOV-1Authority has three steps: member, admin, owner.
Members hold a stored role — member or admin. The owner outranks both, but not through a stored role: ownership is its own fact, and the owner of a workspace is automatically the owner of every project in it. While they hold workspace access they are also an ordinary member, with the admin role, of every active project (P2.2).
Why is this true?
XD-GOV-1Fulla fact about the sources, not a reader labelXD-DER-1Some facts are stored; others are worked out.
A member's role and a task's reviewer are stored. Who owns a project, and which tasks are in a project's archived list, are derived: ChatWell works them out from other facts — the workspace's owner, and each task's state — and never stores them separately.
Why is this true?
XD-DER-1Fulla fact about the sources, not a reader labelT2.4Now, and what happenedPermalink
XD-HIS-1Current state answers "what is true now"; history answers "what happened, in what order, and who did it".
Current state changes. What is recorded only grows: a task's earlier history entries are never edited, and a membership period that ended is never reopened — coming back starts a new one.
T2.5When the system actsPermalink
XD-SYS-1Most changes are a person's own action. Some happen as the consequence of another action.
When someone archives a project, the archive action itself cancels every unfinished task in it. These are not ordinary cancellations: the archive action closes them all at once rather than each being moved on its own, and the comment a person's cancellation requires is not asked for. Each task records the archival as the reason it closed, and its history records the move to Canceled.
Why is this true?
XD-SYS-1Fulla fact about the sources, not a reader labelExact identity
T2.6Finished, frozen and archivedPermalink
XD-FIN-1Finished and archived answer different questions.
Finished — Complete or Canceled — is about a task's lifecycle: it is over. Archived means frozen. A finished task is frozen and appears in its project's archived task list, but its project stays active and people with access can still read it. Archiving a project freezes the work in it: none of its tasks can change any more, whatever their state.
Archiving a project has three separate sides. They are kept apart on purpose.
Why is this true?
XD-FIN-1Fulla fact about the sources, not a reader labelExact identity
XD-ARCH-11 · Access todayOnce a project is archived, nobody can open or change its tasks through ChatWell — not its members, not former members, not the workspace owner — and its members lose the project.
There is currently no way in the product to reopen an archived project, and no way to export its content. Current exceptions, outside tasks, are described in P2.3.
Why is this true?
XD-ARCH-1Fulla fact about the sources, not a reader labelExact identity
XD-ARCH-22 · The content itselfArchiving keeps content rather than deleting it.
The tasks, their history, and who was assigned or reviewing are kept as they were, and ChatWell offers no way to delete a workspace, a project or a task. The normal Workspace lifecycle uses archival rather than physical deletion of its business history.
3 · Routes back to kept content.
Why is this true?
XD-ARCH-2Fulla fact about the sources, not a reader labelExact identity
XD-ARCH-3Not decided. Whether restoring an archived project or workspace will be offered at all.Not decided
Why is this true?
XD-ARCH-3Fulla fact about the sources, not a reader labelExact identity
Where this comes from — How the system behavesPermalink
Where this comes from11 claim groups
| Claim group | Covers | State | Coverage | Sources |
|---|---|---|---|---|
XD-CONT-1 | Strict containment | Works today | Full | Workspace & project lifecycle model · Membership model · Accepted Gen-5 implementation |
XD-ACC-1 | Conditions for task work | Works today | Full | Membership model · Gen-5 task implementation specification · Accepted Gen-5 implementation |
XD-ACC-2 | For tasks, roles are not access | Works today | Full | Workspace & project lifecycle model · Gen-5 task implementation specification · Project access policy decision · Accepted Gen-5 implementation |
XD-GOV-1 | Authority ladder | Works today | Full | via WS-ROLE-2, WS-OWN-4, PJ-ACC-6 |
XD-DER-1 | Stored versus derived | Works today | Full | via WS-OWN-4, TK-LC-5, TK-REV-1, WS-ROLE-1 |
XD-HIS-1 | Now versus history | Works today | Full | via TK-HIS-2, WS-MEM-2 |
XD-SYS-1 | System-side cancellation | Works today | Full | Gen-5 lifecycle decisions · Task lifecycle & assignment model · Gen-5 task implementation specification · Accepted Gen-5 implementation |
XD-FIN-1 | Finished task vs archived project | Works today | Full | Task lifecycle & assignment model · Task operation contract · Accepted Gen-5 implementation |
XD-ARCH-1 | Access after archiving | Works today | Full | Workspace & project lifecycle model · Gen-5 lifecycle decisions · Source of Truth Map · Task lifecycle & assignment model · Gen-5 task implementation specification · Accepted Gen-5 implementation |
XD-ARCH-2 | Content is kept | Works today | Full | Workspace & project lifecycle model · Gen-5 lifecycle decisions · Accepted Gen-5 implementation |
XD-ARCH-3 | Whether restoration is offered | Not decided | Full | Workspace & project lifecycle model · Accepted Gen-5 implementation |
Coverage is a fact about the sources, not a reader label. Gap is not one of the five labels.