ChatWell Gen-5 System atlas

A rendering of the Gen-5 System Guide · derived, never authoritative

ChatWell Gen-5System atlas

Look over a page to see the structure, the relationships and what is settled. Open a line to read the guide's own words; open it again for the sources.

Rendering adopted guide · 120 claims, 8 figuresNot settled: 12 decided but unavailable · 7 not decided · 2 where sources disagree
THE FOUR THINGS·and the four relationships that run between them
membertakes part as a member, only in the ones it has joinedT1-3WS-MEM-1
Workspace
holds a group's projects and the people who take part
T1-1
containseach project sits inside exactly one workspaceXD-CONT-1
Project
groups related work inside one workspace
T1-1
containseach task sits inside exactly one projectXD-CONT-1
Task
one piece of work inside one project
T1-1
FOUR RELATIONSHIPS · none of them is any of the others
Ownership
PersonWorkspace
Ownership is not a membership role.
WS-OWN-1WS-OWN-2
Membership
PersonWorkspace · Project
Belonging to a workspace gives no project membership at all.
WS-MEM-1PJ-ACC-1
Assignment
PersonTask
The assignee is the person responsible for doing the work.
TK-ASG-1
Review
PersonTask
The reviewer is chosen for each task.
TK-REV-1

Derived from the published System Guide. Every row cites the claim groups it renders, and every rule on it is quoted from one of them.

What this is, and what it is not

Adopted — pilot scope. This is the ChatWell Gen-5 System Guide, a system-guide: derived, plain-language explanation of rules that other ChatWell documents and the accepted Gen-5 implementation own. It is never authoritative and it owns no rule. Where it differs from an authoritative source, the source wins and this guide is corrected. Where authoritative sources disagree with each other, this guide says so and does not choose.

Pilot scope: the opening tiers (T0–T2), three domain chapters — Workspaces, Projects, Tasks — and the three lenses (L1–L3). Other parts of ChatWell are acknowledged, not explained. Exact source identities live in the traceability sidecar gen5-system-guide.sources.yaml (see L3).

ShowFiltering hides nothing permanently; everything is present in the page.
T0-1ChatWell organizes work in Workspaces.

A workspace holds Projects, and a project holds Tasks. Each person takes part through their own Account.

Why is this true?
ClaimT0-1
CoversWorkspaces, projects, tasks, accounts
StateWorks today
CoverageFulla fact about the sources, not a reader label
Sourcesrestates T1-1
Exact identity

This restates T1-1. It names no source of its own; the identity lives with the groups it restates.

T0-2People belong to workspaces.

An account reaches only the workspaces it is a member of — nobody sees everything. Every account also has a Personal Workspace of its own.

Why is this true?
ClaimT0-2
CoversPeople belong to workspaces
StateWorks today
CoverageFulla fact about the sources, not a reader label
Sourcesrestates WS-MEM-1, WS-KIND-1
Exact identity

This restates WS-MEM-1, WS-KIND-1. It names no source of its own; the identity lives with the groups it restates.

T0-3Joining a workspace adds no projects.

Belonging to a workspace gives you the workspace and none of its projects — not even its main project, and not that project's chat. To work on a project's tasks, a person needs their own membership in that project. A workspace member may have no projects at all.

Why is this true?
ClaimT0-3
CoversJoining a workspace adds no projects
StateWorks today
CoverageFulla fact about the sources, not a reader label
Sourcesrestates PJ-ACC-1, PJ-ACC-4
Exact identity

This restates PJ-ACC-1, PJ-ACC-4. It names no source of its own; the identity lives with the groups it restates.

T0-4Owning a workspace is not a role.

Members are either member or admin. Who owns the workspace is recorded separately, and every workspace has exactly one owner.

Why is this true?
ClaimT0-4
CoversOwnership is not a role
StateWorks today
CoverageFulla fact about the sources, not a reader label
Sourcesrestates WS-OWN-1, WS-OWN-2
Exact identity

This restates WS-OWN-1, WS-OWN-2. It names no source of its own; the identity lives with the groups it restates.

T0-5A task answers three separate questions:

what state it is in, who is responsible for it, and who reviews it. Changing one does not change the others, and the person responsible for a task is never its reviewer.

Why is this true?
ClaimT0-5
CoversThree questions per task
StateWorks today
CoverageFulla fact about the sources, not a reader label
Sourcesrestates TK-DIM-1, TK-REV-9
Exact identity

This restates TK-DIM-1, TK-REV-9. It names no source of its own; the identity lives with the groups it restates.

T0-6What ChatWell writes into history, it does not rewrite.

A task's history only grows, a membership that ended stays on record, and archiving keeps content rather than deleting it.

Why is this true?
ClaimT0-6
CoversHistory is not rewritten
StateWorks today
CoverageFulla fact about the sources, not a reader label
Sourcesrestates TK-HIS-2, WS-MEM-3, XD-ARCH-2
Exact identity

This restates TK-HIS-2, WS-MEM-3, XD-ARCH-2. It names no source of its own; the identity lives with the groups it restates.

T0-7There is more than this pilot covers.

ChatWell also has chat channels, contacts and companies, and scheduled events. T1.4 introduces them; this pilot does not explain them.

Why is this true?
ClaimT0-7
CoversSupporting capabilities exist
StateWorks today
CoveragePartly defineda fact about the sources, not a reader label
Sourcesrestates XD-SUP-1, XD-SUP-2, XD-SUP-3
Exact identity

This restates XD-SUP-1, XD-SUP-2, XD-SUP-3. It names no source of its own; the identity lives with the groups it restates.

T0.1How to read this guidePermalink

Statements without a label work today. Every other statement starts with one of the four state labels, so a copied sentence keeps its meaning; the Partly defined qualifier sits next to the claim it qualifies.

LabelMeaning
Works todayWhat the accepted Gen-5 implementation does now — the implementation running on ChatWell's hosted LOCAL environment. This guide says nothing about other environments. This is the default, so most statements carry no label.
Decided — not currently availableSettled as how Gen-5 works, but not something anyone can use today. The guide always says what happens today instead.
Not decidedAn open question. The guide does not guess the answer.
Sources disagreeChatWell's own authoritative sources say different things. The guide shows both and does not choose.
Partly definedA qualifier, not a state: the facts shown are established, but the wider meaning is not fully defined — often because only the accepted implementation shows them. It does not mean something is broken or unavailable.

Nothing in this guide is a promise about when, or whether, something becomes available.

T0.2Where this comes fromPermalink

This guide restates ChatWell's canonical Gen-5 models — the workspace and project lifecycle model, the membership model, the task lifecycle and assignment model, the task operation contract and the Gen-5 lifecycle decisions — together with the accepted Gen-5 implementation and accepted runtime evidence. It adds no rule of its own. The decisions on project access, task reviewer authority and beta workspace creation, and the runtime verification that followed them, are carried throughout.

Where this comes from7 claim groups
Claim groupCoversStateCoverageSources
T0-1Workspaces, projects, tasks, accountsWorks todayFullvia T1-1
T0-2People belong to workspacesWorks todayFullvia WS-MEM-1, WS-KIND-1
T0-3Joining a workspace adds no projectsWorks todayFullvia PJ-ACC-1, PJ-ACC-4
T0-4Ownership is not a roleWorks todayFullvia WS-OWN-1, WS-OWN-2
T0-5Three questions per taskWorks todayFullvia TK-DIM-1, TK-REV-9
T0-6History is not rewrittenWorks todayFullvia TK-HIS-2, WS-MEM-3, XD-ARCH-2
T0-7Supporting capabilities existWorks todayPartly definedvia XD-SUP-1, XD-SUP-2, XD-SUP-3

Coverage is a fact about the sources, not a reader label. Gap is not one of the five labels.

Orientation map

Derived from the published System Guide. Every row cites the claim groups it renders; the guide’s eight figures are each drawn once, in the chapter that declares them.

What sits inside what

Personal Workspace
has exactly one of its own, and owns it
WS-KIND-1 T1-2
Workspace
takes part as a member, only in the ones it has joined
WS-MEM-1 T1-3
WorkspaceProject
each project sits inside exactly one workspace
XD-CONT-1
ProjectTask
each task sits inside exactly one project
XD-CONT-1

What exists in every workspace

provisioned with the workspace, not granted to anyone

Workspace
automatic
Main projectPJ-MAIN-1 XD-CONT-1
automatic
Its General ChatWS-START-1 XD-SUP-1
  • Every workspace has one main project. It is created together with the workspace. PJ-MAIN-1
  • A new workspace does not start empty: a workspace someone creates begins with a main project and a chat for it. WS-START-1

Three different things, kept apart

Workspace membership is not project membership, and neither is reach into a project’s chat.

Workspace membership

How a person belongs to a workspace.WS-MEM-1

  • You become a member by creating a workspace, by accepting an invitation, or — for your Personal Workspace — by creating your account. WS-MEM-1
  • Membership comes in periods. An ended period is never reopened; coming back starts a new one. WS-MEM-2
  • The stored role is member or admin. There is no third stored role, and never one called owner. WS-ROLE-1 WS-OWN-2
givesthe workspace
does not giveany project in it, that project's chat, or a project's tasksPJ-ACC-4 PJ-ACC-1

Project membership

A person's own membership in one project.PJ-ACC-1

  • Belonging to a workspace gives no project membership at all: a person needs their own membership in that project. PJ-ACC-1
  • Granted project by project: an admin of the project, or the workspace owner, adds a current workspace member. PJ-ACC-3
  • The person who creates a project becomes an admin of it. PJ-CRE-1
  • Standing, from owning the workspace: the workspace owner is a member of every active project with the admin role, for as long as they can reach the workspace. Nobody grants it. PJ-ACC-6
  • Project memberships that already exist are left alone: memberships made before this rule are still real memberships and are not taken away. PJ-ACC-8
  • A workspace member may hold no project membership at all. That is a correct state, not a fault. PJ-ACC-7
givesthe project — and its tasks only while the account, the workspace, the workspace membership and the project are all currentXD-ACC-1 PJ-ACC-1
does not giveanything in another projectPJ-ACC-1

The project's chat

A project comes with a chat, and the chat is reached with the project.XD-SUP-1 PJ-ACC-4

  • A new workspace begins with a main project and a chat for it — nobody creates that one. WS-START-1 PJ-MAIN-1
  • Creating a project also creates its General Chat. XD-SUP-1 PJ-CRE-1
  • Accepting a workspace invitation gives no project chat — not the main project's, not any other's. PJ-ACC-4
  • A member with no projects sees no project chat, and nothing is wrong. PJ-ACC-7
givesnothing on its own — the chat is reached with the projectPJ-ACC-4 PJ-ACC-7
does not givereach through workspace membership alonePJ-ACC-4

Ownership is not a membership role

PersonrelationWorkspace
owns it — exactly one owner, at every moment, recorded separately from any role
WS-OWN-1 WS-OWN-2
PersonrelationWorkspace
and is also a member, whose stored role reads admin — the role alone can never tell you who owns the workspace
WS-OWN-3
Personderived — worked out, never assignedProject
owner of every project in the workspace — derived, never assigned, stored or handed over on its own
WS-OWN-4 XD-DER-1
Personcauses / guaranteesProject
and therefore holds a membership with the admin role in every ACTIVE project, as a standing guarantee — a membership like any other, never a role called owner
PJ-ACC-6 WS-OWN-7
Personrelation does not existProject
an archived project is outside the guarantee: archiving ends the owner's membership in it along with everyone else's
PJ-ACC-9

Positions on a task add up

A position is a capacity, not a role, and a person who holds several has the powers of all of them.

Creatorcreated the task; may choose its reviewer at creation and on the way into reviewTK-CRE-1 TK-REV-7
Assigneeresponsible for doing the work; may take a lifecycle edge where allowed, and may not choose the reviewerTK-ASG-1 TK-REV-7
Reviewerchecks the result; chosen for each task, a responsibility on that task and not a roleTK-REV-1
Project Adminan admin of this projectPJ-ROLE-1 TK-REV-7
Project Ownerthe workspace owner, through their project capacityWS-OWN-4 TK-REV-7
never bothThe person a task is assigned to is never the person who reviews it — in both directions, however the task got that way, and it binds admins and the owner exactly as it binds everyone else.TK-REV-9
additiveBeing the assignee subtracts nothing from what another position already allows: an assignee who is also the creator chooses as its creator.TK-REV-8
still possibleSomeone can review a task they created, as long as they are not the one it is assigned to.TK-REV-10

History runs across all of it

  • Current state answers what is true now; history answers what happened, in what order, and who did it. XD-HIS-1
  • Every task has one ordered history of both kinds of entry, and history is only ever added to. TK-HIS-1 TK-HIS-2
  • A membership period that ended stays on record; ending a membership does not erase the person. WS-MEM-3

Where to go next

T1Core mental modelThe four main things, and the separations that hold everywhere.P1WorkspacesThe two kinds, ownership as a separate fact, membership periods, roles.P2ProjectsProject membership and access, the owner’s standing membership, archiving.P3TasksThree separate questions: lifecycle, assignment, review — and history.L1Open questions & recordsWhat is decided but unavailable, what is not decided, where sources disagree.L2For a prototypeMust preserve, must not assume, not prescribed — by domain.