Tasks
TK-REV-8TK-REV-11TK-REV-9Derived 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: Tasks. This assumes only the core model (T1).
P3.1Three separate questionsPermalink
TK-WHAT-1A task is one piece of work inside one project.
Everyone who currently has access to the project can see all of its tasks.
Why is this true?
TK-WHAT-1Fulla fact about the sources, not a reader labelExact identity
TK-DIM-1Every task answers three questions, independently:
what state it is in (its lifecycle), who is responsible for doing it (its assignee), and who checks the result (its reviewer). Changing the answer to one never changes the other two. Independent does not mean unconstrained: the last two answers may not name the same person (P3.4).
Why is this true?
TK-DIM-1Fulla fact about the sources, not a reader labelExact identity
TK-DIM-2Assignment is not a state.
There is no "assigned" state, and no step in which an assignee accepts or declines a task.
Why is this true?
TK-DIM-2Fulla fact about the sources, not a reader labelExact identity
TK-CRE-1Anyone with access to a project can create a task in it, and every new task starts as Open.
A member may name only themselves as its assignee; the owner or a project admin may name anyone with access to the project. Whoever creates the task may also name its reviewer: anyone with access to the project, except the person they named as its assignee (P3.4).
Why is this true?
TK-CRE-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.
P3.2LifecyclePermalink
TK-LC-1A task is always in one of six states:
Open, In Progress, Blocked, Ready for Review, Complete, Canceled. The first four are active; Complete and Canceled are finished.
Why is this true?
TK-LC-1Fulla fact about the sources, not a reader labelExact identity
TK-LC-2What the states mean.
Open: work has not started, or must restart from the beginning. In Progress: being worked on. Blocked: work started, but something prevents it from continuing. Ready for Review: a review stage, not an execution stage — the work awaits review. Complete: finished. Canceled: no longer relevant.
Why is this true?
TK-LC-2Fulla fact about the sources, not a reader labelExact identity
TK-LC-3How a task moves.
A task that is not finished can move to any other state except the one it is already in, and it can enter Ready for Review only with a reviewer (P3.4). A finished task never moves again. A person who moves a task to Blocked, or cancels it, must add a comment.
Why is this true?
TK-LC-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.
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.
TK-LC-4Who may move it before review.
The owner, a project admin, the task's creator and its assignee can move it between Open, In Progress and Blocked, and send it to review — though someone who is only the assignee sends it to review without choosing who reviews it (P3.4). The owner, a project admin or the creator can mark it Complete or Canceled; being its assignee does not by itself allow this. A person who holds several positions on a task has the powers of all of them — except that assignee and reviewer are never held together (P3.4). In review, see P3.4.
Why is this true?
TK-LC-4Fulla fact about the sources, not a reader labelExact identity
TK-LC-5Finished tasks are frozen and listed as archived.
Complete and Canceled tasks move to the project's archived task list, which ChatWell works out from their state. People with access to the project can still read them; nobody can change them, reassign them or comment on them.
Why is this true?
TK-LC-5Fulla fact about the sources, not a reader labelExact identity
TK-DEL-1Tasks are not deleted.Partly defined
There is no way to delete a task today. Partly defined.
Why is this true?
TK-DEL-1Partly defineda fact about the sources, not a reader labelExact identity
TK-DEL-2Not decided. Whether a task can ever be deleted or restored.Not decided
Why is this true?
TK-DEL-2Partly defineda fact about the sources, not a reader labelExact identity
TK-CONT-1Not decided. Whether a finished task can be continued, or copied into a new task.Not decided
Why is this true?
TK-CONT-1Gapa fact about the sources, not a reader labelExact identity
Complete and Canceled have no outgoing move. Who may take each move is set out in TK-LC-4 and TK-REV-4; who may choose the reviewer the move into review requires is a separate question (TK-REV-7). The four archival moves are made by the archive action itself, not by someone moving each task; whom their history entries name as having acted is a Sources disagree question (SD-2, P2.3).
TK-LC-1P3.3AssignmentPermalink
TK-ASG-1The assignee is the person responsible for doing the work.
A task has one assignee or none, and needs none in any state.
Why is this true?
TK-ASG-1Fulla fact about the sources, not a reader labelExact identity
TK-ASG-2Who may assign.
The owner or a project admin can assign a task to anyone with access to the project, or clear its assignee. A member can make themselves the assignee of a task they created — and nothing more: not someone else, and not clearing it. Whoever assigns, and whatever their standing, the person assigned cannot be the one currently reviewing the task (P3.4).
Why is this true?
TK-ASG-2Fulla fact about the sources, not a reader labelExact identity
TK-ASG-3Only someone with access to the project can be its assignee — and never the person currently reviewing it (P3.4).
Why is this true?
TK-ASG-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.
TK-ASG-4Assigning does not start the work.
Assigning or changing the assignee leaves the state as it is, and moving the task leaves the assignee as it is. Once a task is finished, its assignee no longer changes.
Why is this true?
TK-ASG-4Fulla fact about the sources, not a reader labelExact identity
P3.4ReviewPermalink
TK-REV-1The reviewer is chosen for each task.
Being a task's reviewer is a responsibility on that task — not a membership role, and not a rank. It is a different position from the assignee: the assignee does the work, the reviewer checks it, and on any one task those are never the same person (TK-REV-9). Other positions do combine — a reviewer who is also the task's creator has the powers of both.
Why is this true?
TK-REV-1Fulla fact about the sources, not a reader labelExact identity
TK-REV-2A reviewer must have access to the project when chosen, and again at the moment they act.
A recorded reviewer is a record, not a grant: on a finished task, or on any task in an archived project, the reviewer stays as recorded after their access ends, and nothing ever replaces a reviewer on its own. When an owner or admin removes someone who reviews active tasks, they name a replacement as part of the removal — one person for the whole project, and never someone already responsible for one of those tasks (P1.3).
Why is this true?
TK-REV-2Fulla fact about the sources, not a reader labelExact identity
Sources disagree. What happens when a reviewer of active tasks leaves on their own — see SD-1 below.
TK-REV-3A task enters Ready for Review only with a reviewer.
Someone who may choose reviewers can name one as part of the handoff; someone who may not — an assignee with no other position on the task — can only send on a task that already has one (TK-REV-7). Whoever that reviewer is, they must have access to the project. Before review, no one switches a task's reviewer directly: it is set when the task is created, or by someone with that authority as the task goes into review, or replaced when an owner or admin removes the reviewer (P1.3).
Why is this true?
TK-REV-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.
TK-REV-7Choosing who reviews a task takes its own authority, and doing the work is not it.
Deciding who reviews is a question of what someone is on that task, not of who happens to be moving it along. The task's creator, an admin of the project, and the workspace owner can choose the reviewer — when the task is created, and on its way into review. Once review has begun, changing it belongs to the owner or a project admin alone (TK-REV-5). Being the person the task is assigned to gives nobody that say at any of those moments.
Why is this true?
TK-REV-7Fulla fact about the sources, not a reader labelExact identity
owner roleRuntime 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.
TK-REV-8Positions add up; they never cancel each other out.
This is not a rule that assignees can never choose a reviewer. Someone who is both the assignee and the task's creator chooses as its creator; someone who is both the assignee and an admin of the project chooses as an admin. Being the assignee takes nothing away from what another position already allows.
Why is this true?
TK-REV-8Fulla fact about the sources, not a reader labelExact identity
not (v_is_owner or v_is_admin or v_is_creator) and never tests whether the caller is the assignee, so another held capacity still selectsRuntime 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.
TK-REV-9The person a task is assigned to is never the person who reviews it.
This is a fact about the task, not about who is acting: it holds however the task got that way, and it binds admins and the owner exactly as it binds everyone else. Both directions are closed — a task's reviewer cannot be set to the person it is assigned to, and a task cannot be assigned to the person reviewing it. It governs every change made from here on; nothing already recorded is rewritten or repaired to satisfy it. A task with nobody assigned to it is not affected: anyone with access to the project can be named its reviewer, including whoever is doing the choosing, and it is the later assignment that must not collide.
Why is this true?
TK-REV-9Fulla 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.
TK-REV-10Creating a task and reviewing it are not in conflict.
Someone can review a task they created, as long as they are not the one it is assigned to. There is no rule against it.
Why is this true?
TK-REV-10Fulla fact about the sources, not a reader labelExact identity
TK-REV-11If no reviewer is in place and nobody with the authority has named one, the handoff to review does not happen.
The person doing the work cannot resolve it themselves; someone who may choose reviewers has to name one first.
Why is this true?
TK-REV-11Fulla 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.
TK-REV-4Closing out a task in review.
From Ready for Review, a task can be marked Complete or Canceled by the owner, a project admin, or the task's reviewer. Its creator and its assignee, as such, cannot close it out from review — unless they are the owner or a project admin, or, for the creator, also its reviewer. For the assignee that last route does not exist at all, since a task's assignee is never its reviewer (TK-REV-9). The assignee, the creator, the owner, a project admin and the reviewer can all send it back to active work.
Why is this true?
TK-REV-4Fulla fact about the sources, not a reader labelExact identity
TK-REV-5Changing the reviewer during review.
While a task is in Ready for Review, the owner or a project admin can switch it to a different reviewer — never to the person the task is assigned to (TK-REV-9). Being the current reviewer, or the assignee, does not by itself allow this.
Why is this true?
TK-REV-5Fulla 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.
TK-REV-6"My tasks" means assigned to me or reviewed by me.
A person's own task list covers tasks where they are the assignee or the reviewer, across all their workspaces, in projects they can currently access. Having only created a task does not put it there.
Why is this true?
TK-REV-6Fulla fact about the sources, not a reader labelExact identity
How to read: ✓ may, — may not; a cell that says more than yes or no says it in words. Every row assumes current access to the project. A person with several positions gets all of their powers, and no one is ever both assignee and reviewer of the same task. "Owner" is the workspace owner; "Admin" is an admin of this project.
| Position | Edit details | Assign | Move among active states, or into review | Choose the reviewer entering review | Finish before review | Finish from review | Send back from review | Change reviewer in review | Comment |
|---|---|---|---|---|---|---|---|---|---|
| Owner | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Admin | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Creator | ✓ | only themselves, on their own task | ✓ | ✓ | ✓ | — | ✓ | — | ✓ |
| Assignee | — | — | ✓ | — | — | — | ✓ | — | ✓ |
| Reviewer | — | — | — | — | — | ✓ | ✓ | — | ✓ |
| Other project member | — | — | — | — | — | — | — | — | — |
Nobody in any row may be both the assignee and the reviewer of the same task (TK-REV-9), and a person holding several positions gets the whole of each — being the assignee subtracts nothing (TK-REV-8).
Anyone with access to the project can create a task and read every task in it.
Why is this true?
TK-MX-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.
Sources disagree: when a reviewer leavesPermalink
Sources disagree. 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.
The task lifecycle & assignment model says The task operation contract and the Gen-5 task implementation specification say Leaving must not leave active tasks with a reviewer whose membership has ended. The leaving person's review responsibilities pass to a replacement as part of leaving, and each affected task's history records the change. The person cannot leave while they hold such responsibilities. The attempt is refused and nothing is written. An owner or admin must first reassign them — or remove the person, naming a replacement. This guide does not choose between them. The disagreement stands until the owners of those sources resolve it. Related, and part of the same record: the sources also differ on whether replacing a project's default reviewer during a departure is itself recorded.
Meanwhile: assume neither outcome — neither that leaving hands the reviews on, nor that leaving is refused.
Not affected: the reviewer is a responsibility on a task, not a role (TK-REV-1); who can be a reviewer, and what happens to a recorded reviewer, outside departure (TK-REV-2); who can close out a task in review (TK-REV-4); removal by an owner or admin, which names a replacement, and the entry each affected task's history then carries (WS-MEM-6) — the open recording question above is about the project's default reviewer, not about those task entries; who may be named as that replacement, and that one name covers a whole project (WS-MEM-7); that the assignee of a task is never its reviewer (TK-REV-9), which holds whichever way this question is eventually settled; ordinary workspace membership (P1.3); changing roles inside a project (PJ-ROLE-1); and workspace ownership (P1.2).
Classification is the owner-frozen 'Sources disagree' recorded in the Task authority decision record. The accepted implementation was not used to adjudicate it.
Exact identity
P3.5The task's historyPermalink
TK-HIS-1Every task has a history: an ordered account of what happened to it.
It holds changes of state and the other activity on the task — being created, assigned, given a reviewer, edited and commented on. Both kinds of entry share one order, so they read as a single timeline.
Why is this true?
TK-HIS-1Fulla fact about the sources, not a reader labelExact identity
TK-HIS-2History is only ever added to.
Entries are never edited or removed, and later changes — including later changes to someone's role — never rewrite earlier ones.
Why is this true?
TK-HIS-2Fulla fact about the sources, not a reader labelExact identity
TK-HIS-3Each entry says who acted, and for whom.
It records the person who acted where a person did, the person it concerns where there is one, and whether the actor was the task's creator, assignee or reviewer at that moment. The cancellations written when a project is archived carry none of those three markers.
Why is this true?
TK-HIS-3Fulla fact about the sources, not a reader labelExact identity
TK-HIS-4Assignee and reviewer changes are their own entries, showing the previous and the new person.
A reviewer change is never shown as a change of state. The assignee and the reviewer named when a task is created get no entries of their own: creating a task writes one entry.
Why is this true?
TK-HIS-4Fulla fact about the sources, not a reader labelExact identity
TK-HIS-5Comments belong to the history.
Discussion comments, and the comments that go with state changes, are entries in it. The owner, project admins, the creator, the assignee and the reviewer can comment on an active task, each only with current access to the project. Nobody can edit or delete a comment, and a finished task accepts no new ones.
Why is this true?
TK-HIS-5Fulla fact about the sources, not a reader labelExact identity
TK-HIS-6Not decided. Whether comments can ever be edited or deleted.Not decided
Why is this true?
TK-HIS-6Gapa fact about the sources, not a reader labelExact identity
TK-HIS-7Not decided. Whether comments will have unread counts or read status.Not decided
Today they have none.
Why is this true?
TK-HIS-7Fulla fact about the sources, not a reader labelExact identity
- Leo created the task
- Leo moved it from Open to In Progress
- Leo commented
- Leo moved it from In Progress to Ready for Review
- Anna, as reviewer, moved it from Ready for Review to Complete
Read top to bottom, in the order written. Entries are only ever added at the end.
Leo named himself assignee and Anna reviewer when creating the task; creating a task writes one entry (TK-HIS-4). Nothing above is edited later; new entries are only added at the end.
TK-HIS-1What this means for a prototype — TasksPermalink
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
- State, assignee and reviewer are three separate facts; changing one never changes another.from
TK-DIM-1TK-ASG-4 - A task's reviewer is a responsibility on that task, never a role, and a different position from its assignee.from
TK-REV-1 - The assignee and the reviewer of one task are never the same person, in either direction and whoever is acting.from
TK-REV-9 - Choosing a task's reviewer is a separate authority from moving the task; the assignee has the second and not the first.from
TK-REV-7 - Positions combine: an assignee who is also the creator, a project admin or the owner keeps everything those positions allow.from
TK-REV-8 - Exactly six states, with the display names Open, In Progress, Blocked, Ready for Review, Complete, Canceled.from
TK-LC-1 - Finished tasks never move again; entering Ready for Review needs a reviewer, and only someone who may choose reviewers can supply one on the way in; a person moving a task to Blocked, or canceling it, adds a comment.from
TK-LC-3TK-REV-3 - From Ready for Review, close-out belongs to the owner, a project admin or the task's reviewer.from
TK-REV-4 - A task's history is one ordered timeline of both kinds of entry, and entries are never edited.from
TK-HIS-1TK-HIS-2 - "My tasks" covers tasks a person is assigned to or reviews.from
TK-REV-6
MUST NOT ASSUME
- That "assigned" is a state, or that an assignee accepts or declines a task.from
TK-DIM-2 - That assigning someone starts the work.from
TK-ASG-4 - That close-out from review is reserved to the reviewer: the owner and a project admin can close it out too.from
TK-REV-4 - That whoever may send a task to review may also choose its reviewer on the way.from
TK-REV-3TK-REV-7 - That an assignee can always hand their work on: with no reviewer in place and nobody who may name one, the handoff does not happen.from
TK-REV-11 - That assignees may never choose a reviewer — an assignee who is also the creator, an admin or the owner may.from
TK-REV-8 - That a task's creator may not review it: they may, unless it is assigned to them.from
TK-REV-10 - That the reviewer or the assignee can change a task's reviewer.from
TK-REV-5 - That a recorded reviewer is replaced without an owner or admin naming someone.from
TK-REV-2 - That a task's creator belongs in "my tasks" as creator.from
TK-REV-6 - That tasks can be deleted, or comments edited, today.from
TK-DEL-1TK-HIS-5 - That a finished task can be reopened, continued or duplicated today.from
TK-LC-3TK-CONT-1 - That comments have unread counts.from
TK-HIS-7 - That a project's default reviewer can be chosen today.from
DNA-11 - That a reviewer who leaves on their own either hands their reviews on or is refused: the sources disagree.from
SD-1
NOT PRESCRIBED
- Gen-5 does not prescribe how a task's state is rendered, for example as a pill or a colour.from
TK-LC-1
Where this comes from — TasksPermalink
Where this comes from35 claim groups
| Claim group | Covers | State | Coverage | Sources |
|---|---|---|---|---|
TK-WHAT-1 | What a task is | Works today | Full | Gen-5 task implementation specification · Task lifecycle & assignment model · Accepted Gen-5 implementation |
TK-DIM-1 | Three independent questions | Works today | Full | Task lifecycle & assignment model · Task operation contract · Accepted Gen-5 implementation |
TK-DIM-2 | No assignment state | Works today | Full | Task lifecycle & assignment model · Accepted Gen-5 implementation |
TK-CRE-1 | Creating a task | Works today | Full | Task operation contract · Gen-5 task implementation specification · Accepted Gen-5 implementation · Task reviewer authority decision · Accepted runtime evidence (R1–R4) |
TK-LC-1 | Six states | Works today | Full | Task lifecycle & assignment model · Accepted Gen-5 implementation |
TK-LC-2 | What the states mean | Works today | Full | Task lifecycle & assignment model |
TK-LC-3 | How a task moves | Works today | Full | Task lifecycle & assignment model · Accepted Gen-5 implementation · Accepted runtime evidence (Gate-25) · Accepted runtime evidence (R1–R4) |
TK-LC-4 | Who moves it before review | Works today | Full | Task lifecycle & assignment model · Gen-5 task implementation specification · Accepted Gen-5 implementation |
TK-LC-5 | Finished tasks are frozen | Works today | Full | Task lifecycle & assignment model · Task operation contract · Accepted Gen-5 implementation |
TK-DEL-1 | No task deletion | Works today | Partly defined | Accepted Gen-5 implementation · Gen-5 task implementation specification |
TK-DEL-2 | Whether deletion will exist | Not decided | Partly defined | Gen-5 task implementation specification · Workspace & project lifecycle model |
TK-CONT-1 | Continuing a finished task | Not decided | Gap | Gen-5 task implementation specification · Task lifecycle & assignment model |
TK-ASG-1 | The assignee | Works today | Full | Task lifecycle & assignment model · Accepted Gen-5 implementation |
TK-ASG-2 | Who may assign | Works today | Full | Task lifecycle & assignment model · Task operation contract · Accepted Gen-5 implementation |
TK-ASG-3 | Assignee needs access | Works today | Full | Task operation contract · Task reviewer authority decision · Accepted runtime evidence (R1–R4) · Accepted Gen-5 implementation |
TK-ASG-4 | Assignment and state are independent | Works today | Full | Task lifecycle & assignment model · Accepted Gen-5 implementation |
TK-REV-1 | Reviewer is per task | Works today | Full | Task lifecycle & assignment model · Workspace & project lifecycle model · Accepted Gen-5 implementation |
TK-REV-2 | Reviewer access; a record, not a grant | Works today | Full | Task lifecycle & assignment model · Task reviewer authority decision · Task operation contract · Accepted Gen-5 implementation |
TK-REV-3 | Entering review | Works today | Full | Task lifecycle & assignment model · Task reviewer authority decision · Accepted runtime evidence (R1–R4) · Task operation contract · Accepted Gen-5 implementation |
TK-REV-7 | Reviewer selection takes its own authority | Works today | Full | Task reviewer authority decision · Task lifecycle & assignment model · Task operation contract · Gen-5 task implementation specification · Accepted Gen-5 implementation · Accepted runtime evidence (R1–R4) |
TK-REV-8 | Positions add up | Works today | Full | Task reviewer authority decision · Task lifecycle & assignment model · Gen-5 task implementation specification · Accepted Gen-5 implementation · Accepted runtime evidence (R1–R4) |
TK-REV-9 | Assignee is never the reviewer | Works today | Full | Task reviewer authority decision · Task lifecycle & assignment model · Task operation contract · Gen-5 task implementation specification · Accepted Gen-5 implementation · Accepted runtime evidence (R1–R4) |
TK-REV-10 | A creator may review their own task | Works today | Full | Accepted Gen-5 implementation · Task reviewer authority decision · Task lifecycle & assignment model |
TK-REV-11 | No reviewer, no handoff | Works today | Full | Task reviewer authority decision · Task lifecycle & assignment model · Gen-5 task implementation specification · Task operation contract · Accepted Gen-5 implementation · Accepted runtime evidence (R1–R4) |
TK-REV-4 | Close-out from review | Works today | Full | Task lifecycle & assignment model · Gen-5 task implementation specification · Accepted Gen-5 implementation |
TK-REV-5 | Changing the reviewer | Works today | Full | Task lifecycle & assignment model · Task reviewer authority decision · Task operation contract · Accepted runtime evidence (R1–R4) · Accepted Gen-5 implementation |
TK-REV-6 | My tasks | Works today | Full | Task operation contract · Gen-5 task implementation specification · Accepted Gen-5 implementation |
TK-MX-1 | Who may act on a task | Works today | Full | Gen-5 task implementation specification · Task reviewer authority decision · Accepted runtime evidence (R1–R4) · Task lifecycle & assignment model · Accepted Gen-5 implementation |
TK-HIS-1 | One ordered history | Works today | Full | Task lifecycle & assignment model · Accepted Gen-5 implementation |
TK-HIS-2 | History only grows | Works today | Full | Task lifecycle & assignment model · Task operation contract · Accepted Gen-5 implementation |
TK-HIS-3 | Who acted, for whom | Works today | Full | Task lifecycle & assignment model · Membership model · Gen-5 task implementation specification · Accepted Gen-5 implementation |
TK-HIS-4 | Assignee and reviewer entries | Works today | Full | Task lifecycle & assignment model · Accepted Gen-5 implementation |
TK-HIS-5 | Comments in the history | Works today | Full | Task lifecycle & assignment model · Task operation contract · Accepted Gen-5 implementation |
TK-HIS-6 | Editing comments | Not decided | Gap | Gen-5 task implementation specification · Accepted Gen-5 implementation |
TK-HIS-7 | Unread counts | Not decided | Full | Task lifecycle & assignment model · Gen-5 task implementation specification · Accepted Gen-5 implementation |
Coverage is a fact about the sources, not a reader label. Gap is not one of the five labels.