Source authority and traceability
L3.1How provenance is shownPermalink
- At the claim group. Each statement group carries a quiet identifier (in this source, a comment line such as
cg: WS-OWN-1). - At the chapter foot. Where this comes from lists every claim group with its state, its authority coverage and its sources by name. A claim group that restates others names no source of its own: its row reads
viaand the groups it restates. Records are not listed there — aDNArecord's state is Decided — not currently available and anSDrecord's is Sources disagree, each fixed by the register it belongs to, and their sources are in the sidecar. - On demand. Exact identities — repository, path, document status, immutable commit, content checksum, section and line locator, and authority scope — live in the traceability sidecar
gen5-system-guide.sources.yaml, next to this file.
Coverage values: Full — a registered authority owns and states it. Partly defined — established by the accepted implementation where registered documents are silent, or its wider meaning is not defined. Gap — no registered document supports it: the canonical documents say otherwise, or nothing addresses it; where it works today, only the accepted implementation shows it. Sources disagree — applicable authorities conflict.
Coverage is a fact about the sources, not a reader label. A statement that works today carries the Partly defined qualifier whether its coverage is Partly defined or Gap, because Gap is not one of the five labels; the two are told apart only in these tables and in the sidecar. Sources disagree describes a question held as a record rather than a claim group, so no row at a chapter foot carries it; those records are listed in L1.3.
L3.2The sourcesPermalink
| Source | What it is cited for, here |
|---|---|
| Workspace & project lifecycle model | Workspace and project lifecycle, archival, ownership transfer, and governance: roles, derived Project Owner, the role vocabulary, the authority ladder, and that the owner's project membership is not derived ownership |
| Membership model | Membership periods, access rules, event identity, the data classes of stored content, and the project-access policy for every workspace type |
| Task lifecycle & assignment model | Task lifecycle, transitions, permissions, assignment, reviewer selection and the assignee/reviewer separation, archive semantics and task history |
| Task operation contract | The public task operation contract: callable behaviour, authorization and refusal |
| Gen-5 task implementation specification | How the task model and contract are realized; its records of deferred and out-of-scope items |
| Gen-5 lifecycle decisions | Decisions G5-01 to G5-17: ownership transfer, owner-elected archival, the personal-workspace carve-out, deny-by-default access after archival, operator access, export, task disposition on archival |
| Task authority decision record | The Task authority layering, and the record of the departure disagreement |
| Project access policy decision | The workspace owner's standing project membership in active projects, and that workspace membership alone grants no project membership |
| Task reviewer authority decision | Reviewer selection as its own authority, and that a task's assignee is never its reviewer |
| Beta workspace creation decision | The Personal Workspace as unconditional, and the two permissions an additional workspace needs during beta |
| Workspace templates runbook | How workspace templates are permitted and authorized today, and what each template setting means |
| Identity invariants | Account identity and attribution |
| Default template contract | The default workspace template (with an unresolved amendment), the unconditional Personal Workspace guarantee, and that "free" is positioning rather than a system setting |
| Source of Truth Map | Which document owns which topic, at the accepted documentation base |
| Decision Index | The identity and status of an open question — here, how many workspaces an account may have |
| Accepted Gen-5 implementation | What is deployed: the accepted Gen-5 migration chain, which is also the applied hosted LOCAL ledger |
| Accepted runtime evidence (Gate-25) | Runtime acceptance of the task work on hosted LOCAL, scoped to tasks (evidence, not a registered authority) |
| Accepted runtime evidence (R1–R4) | Runtime acceptance on hosted LOCAL of the project-access, reviewer-authority and beta-creation decisions (evidence, not a registered authority) |
The sidecar also records the Checkpoint-X closure and the accepted LOCAL integration record. Neither is cited for an individual claim: together they are what ties the accepted implementation to the hosted LOCAL ledger.
Runtime evidence is never an authority of its own. Where a statement here is marked as working today on the strength of it, an accepted document says the same thing first; the evidence says only that the running system agrees.
L3.3Reader terms and source termsPermalink
This guide uses its own words. The mapping back to the sources' vocabulary:
| Reader term | Source term |
|---|---|
| membership period | membership episode (workspace_membership_episode, project_membership_episode) |
| who owns the workspace | the open workspace_ownership_episode |
| being able to act / access | workspace_effective_access, project_effective_access |
| stored role: member, admin | workspace_member.role, project_member.role ∈ {member, admin} |
| owner / derived project owner | effective authority owner; Project Owner ≡ Workspace Owner |
| finished task | terminal status: complete, canceled |
| task history | task_status_event and task_activity_event, merged on a shared sequence |
| Open · In Progress · Blocked · Ready for Review · Complete · Canceled | open · in_progress · blocked · ready_for_review · complete · canceled |
| main project | project of kind workspace_main |
| Personal Workspace / user-created workspace | workspace_origin = system_personal / user_created |
| the owner's separate ownership signal | is_owner, returned per workspace by the account bootstrap |
| the reason a task closed | the task's closed_reason (for archival: project_archived) |
| the owner's standing project membership | G5-PA-01 — an open project_membership_episode with project_role = admin |
| the two permissions a further workspace needs | G5-WC-02 — account authorization and template permission, today carried by one workspace_template_grant row |
| a position on a task | a capacity — Creator, Assignee, Reviewer, Project Admin, Project Owner |
L3.4Conventions of this sourcePermalink
For maintainers, and for the rendering of Representation B.
- Markers. A comment line directly above a block:
cg(claim group),rec(record),block,emphasis,figure,link,anchor, joined by|. A block runs until the next marker. A record's title is the heading immediately above itsrecmarker.linknames the claim groups or records a block restates, illustrates or points to; a block withlinkand nocgcarries no claim of its own and gets no provenance row.figureon ablock: figuremarker declares that block to be that figure;figureon acgorrecmarker names the figure that illustrates it, which may be declared in another chapter. A figure is rendered once, where it is declared; every other binding is a reference to it. - Blocks.
opener,rule,statement,aside,scenario,figure,matrix,prototype,provenance. No other block exists. Amatrixcell is ✓, —, a state label with its record, or a short phrase where yes or no is not the whole answer. - Emphasis. At most one
leadper section. - Labels. Only the five in T0.1. A statement that does not work today starts with its state label; the Partly defined qualifier sits next to the claim it qualifies.
- Figures. Fenced
structure-map,state-maportimelinedeclarations. Nodes are reader concepts only — Account, Person, Personal Workspace, Workspace, Project, Task — or named states. Each declares what it shows; a figure of current behaviour contains only current behaviour. Every figure declaresid,captionandshows; a structure map declaresnodesand may declarecontainsandedges; a state map declaresstatesandtransitions; a timeline declaresentries, read top to bottom in the order written. An optionalnoteis a footnote: it may restate or point to claim groups, never carry a claim of its own. A node written as a bare kind name —Project— stands for the kind, so it may sit under more than one container; a node writtenKind (Name)stands for one named thing, and sits under exactly one. Grammar:A > Bundercontains:— B sits inside A;A -> B : label— a relation, or in a state map a transition;A ..> B : label— a derived relation;A -x B : label— a relation that does not exist;overlay:— ownership or access drawn over the same outline;[person]/[system]— who makes a transition. Every endpoint is a declared node or state. - Records. Each
DNArecord carries the capability, the decision and today's consequence, and either an anchor list or a register-only reason. The notice at each anchor is written there, names the record's capability, and adds nothing the record does not state. - Prototype entries end with
— fromand the claim groups or records they derive from. - Provenance. Every claim group appears once in its chapter's Where this comes from, and has an exact record in the sidecar.
Exact source identities
From the traceability sidecar — a component of the guide, not a separate document. Each card leads with the scope the source may be cited within: several of those scopes are the only thing preventing a reasonable over-reading.
Beta workspace creation decision
D-BWC7 citationscited only withinDecision anchor for owner ruling R4, both limbs: G5-WC-01 (the Personal Workspace is provisioned unconditionally, independent of grants, creation eligibility, catalog availability and visibility, beta authorization and instance limits; `free` is positioning only and no billing semantic follows) and G5-WC-02 (an additional Workspace during beta needs account authorization AND template permission). canonical-for: —; the operative rules live with product/default-template-contract.md §1.1, §4.1 and runbooks/workspace-templates.md §2, §3.
Identity invariants
D-ID2 citationscited only withinCanonical for identity invariants: account lifecycle, attribution and deletion.
Decision Index
D-IDX1 citationcited only withinThe register of adopted decisions and open questions. Cited only for the identity and status of an open question — here P-1, whether the dev-only workspace-limits changes amend the Default template contract — never for a semantic.
Gen-5 lifecycle decisions
D-LIFE15 citationscited only withinRegistered canonical for decisions G5-01..G5-17 (ownership transfer, owner-elected archival, personal-workspace carve-out, deny-by-default post-archival access, export before archival, operator access, task disposition on archival, invitations).
Membership model
D-MEM35 citationscited only withinCanonical for membership episodes and historical identity, the live access predicates (the two historical predicates are superseded for Gen-5 by G5-09), the event identity model, and the data-class classification of stored content (section 5B).
Project access policy decision
D-PAP18 citationscited only withinDecision anchor for owner rulings R1 (G5-PA-01, the Workspace Owner's standing `admin` project membership in ACTIVE projects, conditioned on the owner's current workspace access) and R2 (G5-PA-02, workspace membership alone never grants project membership). canonical-for: —; the operative rules live with membership-episodes-model.md §3 and workspace-lifecycle-model.md §6.
Source of Truth Map
D-SOT5 citationscited only withinRegistry of topic ownership. Ref-specific: its contents differ between refs, so it is cited only at this ref.
Gen-5 task implementation specification
D-TASKI28 citationscited only withinCanonical for the implementation realization of the task model and contract only (never product semantics); cited here for realization facts and for its records of deferred and out-of-scope items (sections AK, I.4).
Task lifecycle & assignment model
D-TASKP41 citationscited only withinCanonical product semantics for task lifecycle states and transitions, task permissions, assignment, reviewer, archive semantics and the task event model.
Task operation contract
D-TASKR21 citationscited only withinCanonical for the public task operation contract: callable behaviour, authorization and refusal, externally meaningful validation and errors, the read layer, task realtime and replica identity.
Task authority decision record
D-TAUTH1 citationcited only withinDecision anchor for the Task authority layering; records the departure-handling contradiction between the task lifecycle model and the RPC contract/implementation specification without resolving it. canonical-for: —.
Default template contract
D-TMPL3 citationscited only withinCanonical for the default template and the `default_personal` lifecycle rules L1-L9, with the P-1 amendment (instance limits and their counting) unresolved — neither version of that to be treated as settled. Cited to mark the starting structure as not settled, and for §1.1's unconditional Personal Workspace provisioning guarantee and its positioning-not-pricing rule (LOCKED — A4).
Workspace templates runbook
D-TMPLR5 citationscited only withinRegistered owner of workspace template operations: the visibility policy and the beta creation gate (§2), the operator procedures that confer authorization (§3), and instance limits (§3.7). Cited only for template visibility and the beta authorization mechanism; it owns no workspace, project or task semantic.
Task reviewer authority decision
D-TRA15 citationscited only withinDecision anchor for owner ruling R3, both limbs: G5-TR-01 (reviewer selection requires a capacity other than Assignee, and capacities are additive) and G5-TR-02 (the current Assignee is never the Reviewer of the same task). canonical-for: —; the operative rules live with task-lifecycle-and-assignment-model.md §1.9, §2, §3 and task-domain-rpc-contracts.md. Explicitly does NOT decide reviewer departure (SD-1).
Workspace & project lifecycle model
D-WSL39 citationscited only withinCanonical for workspace and project lifecycle, archival, ownership transfer, deletion policy, project archival, and workspace/project governance: the four roles, derived Project Owner, the stored role vocabulary {member, admin} and the effective-authority ladder.
Accepted Gen-5 implementation
B-MIG108 citationscited only withinThe registered non-document authority for what is deployed (schema, access rules, operations, realtime). Establishes current behaviour and absence of operations; never product intent. The last definition in chain order governs, and an operation is user-reachable only where EXECUTE is granted to authenticated. Sixteen units at this ref; equal to the hosted LOCAL applied ledger, head 20260911102642 (R-R1R4). The eleven-unit predecessor is recorded by R-CX and R-INT.
16 units in the chain
20260901022656_baseline_gen5_1of4_schema.sql20260901201626_baseline_gen5_2of4_functions_and_triggers.sql20260902061658_baseline_gen5_3of4_security_rls_realtime.sql20260902212802_correct_gen5_scheduled_worker_advisory_locks.sql20260902235207_baseline_gen5_4of4_seed_and_schedules.sql20260904234359_correct_gen5_mailbox_first_principal_and_invitation_identity.sql20260905163747_gen5_task_domain_types_schema_stores_retirement.sql20260905175604_gen5_task_domain_predicates_rpcs_and_security.sql20260905202219_gen5_task_domain_archival_and_departure_integration.sql20260907070001_correct_gen5_task_whitespace_validation.sql20260907173509_correct_gen5_workspace_departure_serialization_timestamp.sql20260911101829_correct_gen5_invitation_project_chat_fanout_removal.sql20260911102001_correct_gen5_task_reviewer_authority_and_collision.sql20260911102134_correct_gen5_departure_replacement_reviewer_collision.sql20260911102459_correct_gen5_workspace_owner_project_membership_writers.sql20260911102642_backfill_gen5_workspace_owner_project_membership.sql
Accepted runtime evidence (Checkpoint-X)
R-CXrecorded for identity; not cited for an individual claimcited only withinCheckpoint-X hosted LOCAL closure, CLOSED / PASS: ledger 11, head migration 20260907173509 — the ELEVEN-UNIT PREDECESSOR of the chain B-MIG now names; superseded as the current tie by R-R1R4. Asserts nothing about DEV, STAGING or PROD. Evidence, not a registered authority. Recorded for identity, with R-INT, as what ties the accepted chain to the hosted LOCAL environment; not cited for an individual claim.
Accepted runtime evidence (Gate-25)
R-G25recorded for identity; not cited for an individual claimcited only withinGate-25 hosted LOCAL runtime acceptance, formally CLOSED / PASS. Scoped to the Task / Checkpoint-X work only; it proves nothing about non-task domains. Evidence, not a registered authority. Recorded for identity; behaviour-level claims cite the specific block (R-G25-R4).
Accepted runtime evidence (Gate-25)
R-G25-R41 citationcited only withinGate-25 block G25-R4: terminal task immutability runtime acceptance on hosted LOCAL. Evidence, not a registered authority; scoped to the task work.
Accepted LOCAL integration record
R-INTrecorded for identity; not cited for an individual claimcited only withinRecords that chatwell-supabase local was fast-forwarded to 38a7075, so the eleven-unit chain equalled the hosted LOCAL applied ledger at that time. Historical identity evidence for the predecessor checkpoint; superseded as the current tie by R-R1R4. Not cited for any claim.
Accepted runtime evidence (R1–R4)
R-R1R420 citationscited only withinHosted LOCAL runtime acceptance of the R1-R4 conformance work, scoped to the assertions the script makes: R1 (owner admin membership on project creation; owner cannot leave, be removed from, or be demoted in an active project), R2 (invitation acceptance opens a workspace membership and no project episode, project member row or chat membership), R3 (reviewer selection capacity, capacity additivity, the reviewer-required refusal, the non-review-edge refusal, and the assignee/reviewer collision on every mutation path including departure replacement) and R4 (Personal Workspace provisioned with zero grants; zero public templates; no direct workspace insert; no create_workspace/_v2). It proves nothing outside those assertions and nothing about DEV, STAGING or PROD. Evidence, not a registered authority: every claim it supports is stated first by an accepted document.
The committed artifact is the verification script itself — the assertions it makes and the conditions each asserts. The recorded outcome of the hosted-LOCAL execution above is the accepted checkpoint result and is NOT committed as a file in any repository; no result artifact exists to cite.