Specification: access, catalogue, communications and deletion

Planning specification. Feature implementation remains on hold (Chris, 5 October 2026). The owner decisions cited here are planning approval only. Brief approval and implementation authorisation are separate, per gate (D1-04), and are still on hold. Nothing here enables notifications, sends email, deletes or restores a project, changes a membership, publishes a catalogue item or authorises any migration. Permanent physical erasure is not approved (T-POL-01). A separate identity-erasure process is not decided (T-POL-02). No legal sufficiency is claimed for any wording on this page. Storage shapes are marked PROPOSAL; the F1a storage and naming ADRs fix them.

Sources. "Consolidation" is the owner-session consolidation §6, which wins over older text. "Register" is the 74-entry session register (D3-12, D3-21 to D3-25, D4-20, and the O1 sections at its end). "Condensed" is the condensed packages (O1, O2 and their final clarifications). Package context: notifications integration, contracts C10 and C15, domain model §2.1, §4.5 and §4.10, consistency model §9 and §11.5, and the membership status feature.

1. Summary in plain English

This page covers what happens when people leave, when admins remove work from current use, when a project is deleted, how shared templates are published, what emails may say, and how admins are warned before their changes disturb reviewers.

Leaving and losing access. When someone deletes their SyRF account, they can no longer sign in. Their submitted work keeps their name. When an admin disables someone's project membership, that person loses access, and their submitted work still counts. Reviewers cannot take back submitted work by leaving. Joining a project should explain this.

Excluding contributions. An admin can deliberately take one member's contributions out of current use for one annotation form, one screening profile, one stage or the whole project. They give a reason, see a preview of the effects first, and the action is recorded with their name and the time. The excluded work is never deleted and keeps its attribution in history. Results that already used it (for example an accepted answer) stay as they are; their authors are told and may reconsider, which creates new versions only when somebody chooses to.

Deleting a project. Ordinary deletion is reversible. The project disappears from normal lists, review and editing stop, allocations and notifications stop, and active places are released, while drafts, data and history are kept. An authorised admin can restore it from a restricted "Deleted projects" view. Restoration checks availability and capacity again and does not bring back stale places. Permanently erasing data is a separate policy that Chris has not approved.

The catalogue. SyRF has one application-wide CAMARADES catalogue of templates (question sets, forms, screening profiles and similar), run by users with a system permission. Using a template copies it into a project with a record of where it came from. Later edits on either side never overwrite a copy. Anyone else can ask for something to be published in the catalogue.

Emails and notices. Emails and digests may include useful context such as the project name and study titles. What else they include (answers, free-text notes) is configurable per project. Every email is checked against the recipient's current access and the relevant blinding rules at the moment it is sent. A person can mute email for one project and still see in-app notices. When the work a notice is about is resolved, the notice is marked resolved and leaves the unread count, and its history is kept. Reconciliation conversations are kept as permissioned audit records and never appear in answer exports or agreement statistics. Notifications are switched on only through explicit gates: pilot projects first, test email kept in a test mailbox, and an operator pause switch.

Warnings before admin changes. Any admin action that affects reviewers shows who and what is affected before it is committed, checks again at commit, and tells the affected people afterwards. An explicit "Apply anyway" can release temporary review places that a change makes incompatible (for example after lowering capacity). It keeps drafts and never overrides permissions or invalid configuration.

2. Decisions covered

ID	Decision in one line	Status	Section
D2-14	Ordinary account deletion disables access and keeps named attribution; joining terms explain retention; identity erasure not decided	Decided-amended	§3.1, §5, §9 E1
D4-20	Contributions stay valid after access loss; admins may explicitly exclude them by form, profile, stage or project	Decided-amended (O1)	§3.2, §4.3, §5
O1 amendment (admin-controlled contribution exclusion)	Exclusion with impact preview, reason, actor, time; provenance-based stage scope; dependent results preserved	Decided (amendment outside the register count)	§3.2, §4.3, §7
D3-12	Search withdrawal hides items and keeps history; ordinary project deletion is reversible; permanent erasure is a separate unapproved policy	Decided-amended (O1)	§3.3, §4.5
O1 final clarification (reversible project deletion)	Hide, block, stop allocations and notices, release places, keep data; restore through a restricted view; recheck capacity	Decided	§3.3, §4.5, §4.6
D3-22	Emails and digests may carry project and study context; aliases and content follow recipient permission and blinding; answers and free text configurable; checked at delivery	Decided-amended (O2)	§3.5, §4.9
D3-24	Per-project email mute; in-app notices still recorded	Decided (O2)	§3.6
D3-25	Reconciliation conversations retained as permissioned project audit records; outside answer exports and agreement statistics	Decided (O2)	§3.8
D3-21	Notification environment, kind-family and pilot gates; test email sink; operator delivery pause	Brief item	§3.9, §12
D3-23	Related notices resolve when the work resolves; unread counts consistent; history kept	Brief item	§3.7, §4.10, §12
D2-15	One application-wide CAMARADES catalogue; versioned copies with provenance; publication requests	Decided-amended	§3.4, §4.7
Active-work impact previews and Apply anyway (consolidation §6)	Previews apply broadly to admin actions affecting reviewers; Apply anyway only releases incompatible reservations	Decided	§3.10, §7

Related decisions owned by other specifications (cited, not restated):

ID	Owner spec	What this spec relies on
Q-24	Stage pools, steps and history	Origin of the Cancel or Apply anyway flow for settings that conflict with reservations
Q-27, Q-20	Review domain and versioning	Warning before commit about dependent work; informing affected authors; notice deduplication
D2-10	Review domain and versioning	Publication active-work protection
D3-17, D3-18, D3-20	Stage pools, steps and history	Capacity cap versus target; form-owned limits; presence disclosure (names only with Monitor)
D3-07	UX, devices and work discovery	My work and the global badge work with every notification muted or off
Q-33	Reporting, imports and AI screening	Search withdrawal reporting
D4-06	Reporting, imports and AI screening	Scientific content of curated templates (T-SI-03)
R4 universal baseline	Baseline conversion	Deleted projects convert in their deleted state (BC-R38)
Not approved	T-POL-01, T-POL-02	Permanent physical erasure; identity-erasure process

3. Concepts, entities and storage

3.1 Account deletion and membership status

• Account deletion (existing). Investigator.DeactivateAccount() sets Deactivated = true (Investigator.cs:215-218, read in this worktree). It does not anonymise anything. Under the amended D2-14 this stays the ordinary behaviour: sign-in and access stop, the Investigator record keeps the person's name, and every submitted contribution keeps named attribution.
• Display (PROPOSAL). Names show with an "(account deleted)" suffix wherever attribution is shown and the viewer may see identities.
• What it is NOT. It is not identity erasure. Canonical records keep storing opaque investigator GUIDs, never names (VB-19, PROPOSAL); that rule keeps a future identity-erasure process possible but does not anonymise anyone today.
• Membership status (existing). Project memberships can be Disabled and Enabled with an append-only status history, behind the default-off disableMembership flag (membership status). A disabled member loses project access and review work. Under D4-20 their submitted contributions keep counting.
• Joining terms. The project join and invitation-acceptance screens explain that submitted contributions remain part of the project with the contributor's name after they leave, disable or delete their account (PROPOSAL wording; legal review required before release, §12.3).

3.2 ContributionExclusion

• What it is. An admin's explicit decision to take one member's contributions out of current use for one scope: an annotation form, a screening profile, a stage or the whole project. It carries a reason, the actor, the time and the impact preview that was confirmed.
• What counts as a contribution. The member's candidate form-session versions, their screening decisions and decision-owned answers, and imported contributions mapped to them. Results the member authored as a reconciler or adjudicator are dependent results: the preview lists them and they stay intact (§3.2 "Effects").
• Scopes.

Scope	Which contributions	How they are found
Form	Every contribution of the member to that form, through every stage	Form identity on the session
Screening profile	Every decision and decision-owned answer of the member under any version of that profile	Profile identity on the decision
Stage	Contributions whose recorded route provenance is that stage	Route stage on session versions and decision revisions; never "the stage owns the session"
Project	Every contribution of the member in the project	Project identity

• Effects on current use. Excluded contributions stop counting toward qualification and effective target sufficiency, reconciliation candidate sets and readiness, the candidate facet of collective screening outcomes (and so stage pool evaluation wherever no adjudicated or merge-resolved final facet exists; an existing final facet stays current and flagged, RS-R58), current progress statistics and current agreement statistics. Current exports omit them by default; an exporter with rights may include them, labelled "excluded from current use" (PROPOSAL). As-of views and exports before the exclusion's effective time still include them.
• What stays. Every submitted version, its named attribution, its exposure records and its history. Dependent immutable results (accepted result versions, adjudications, merge-resolved results, hint adoptions) stay current, flagged "inputs changed: contribution excluded", until someone explicitly reconsiders them and creates new versions.
• Identity and versions. (projectId, exclusionId). Immutable. Lifting an exclusion is a separate ContributionExclusionLift record referencing it, with its own reason, actor, time and preview (PROPOSAL; ambiguity B2).
• Time scope (PROPOSAL). An exclusion covers contributions recorded before its effective time. It does not block future work. If the member can still review the scope, the preview says so and offers a link to change their access.
• Storage (PROPOSAL). pmContributionExclusion (append-only), referenced by an operation record (pmCanonicalOperation, kind contributionExclusion) that sweeps affected Studies and updates each Study's canonical summary (per-reviewer standing excluded). ContributionQualificationPolicy reads active exclusions directly, so gates are correct before the sweep finishes.
• What it is NOT. It is not deletion, not a reviewer withdrawal, and not a change to anyone's access. Whole-project deletion is a separate policy.

3.3 Project deletion state and records

• What it is. A reversible removal of a whole project from normal use.
• Shape (PROPOSAL). Project.deletionState ∈ {Active, Deleting, Deleted, Restoring} as a top-level Project field under the N-1 capture rule (C16). Append-only ProjectDeletionRecord (actor, time, reason, preview digest, operation ID) and ProjectRestorationRecord (actor, time, reason, preview digest, operation ID), stored in pmProjectDeletionLedger. A deletion marker on every Study of the project, checked by the composite write guard beside the bulk-lock and ownership guards, so stale legacy and canonical saves are refused on the document they already compare-and-set.
• While Deleted. Hidden from ordinary lists; review, editing and allocation commands refused with "This project has been deleted. Your draft is kept."; no notice capture for the project; reservations and claims released; drafts, evidence, history, conversations and statistics retained; exports unavailable until restored (PROPOSAL).
• Retention. Indefinite until a permanent-erasure policy is approved (T-POL-01). No scheduler physically deletes a deleted project's data.
• Who sees it (PROPOSAL; ambiguity B4). The project owner and holders of the project Delete capability see their deleted projects in the restricted "Deleted projects" view; application administrators with a system permission see all deleted projects.
• What it is NOT. It is not search withdrawal, which hides only Studies supported solely by the withdrawn search and keeps their Citations and evidence (Q-33, D3-12). It is not permanent erasure. The uncommitted deletion-lifecycle design's 24-hour physical deletion does not apply to projects.

3.4 Catalogue

• CatalogueItem and CatalogueItemVersion. One application-wide CAMARADES catalogue (catalogueId = camarades). An item is a reusable definition (question set, annotation form, screening profile, entity type, outcome schema). Its versions are immutable. The catalogueId dimension lets future catalogues with distinct permissions be added without re-keying.
• Administration. Users with a system permission ("Catalogue administrator", an application role authorised by role, never by project grants; domain model principle 5).
• Ways in. Direct entry by a catalogue administrator; sharing a project definition into the catalogue by an authorised user, which creates a catalogue copy with source project, definition, version and sharer provenance; or approval of a CataloguePublicationRequest from any other user.
• Copy provenance on project copies. Copying a catalogue item version into a project creates project-owned definitions with copiedFrom {catalogueId, itemId, versionId, copiedBy, copiedAt} (on the new canonical definition records, so no Project field is added before R0's floor; V2-16).
• No silent overwrite. A new catalogue version never changes a project copy. A project edit never changes the catalogue. Project designers may see "a newer catalogue version exists"; adopting it is an explicit copy into a new project version through ordinary publication (PROPOSAL).
• Storage (PROPOSAL). The system-scoped part of pmDefinitionTemplate becomes the catalogue (CatalogueItem head plus CatalogueItemVersion documents); pmCataloguePublicationRequest holds requests (requester, source definition version, status, reviewer, decision, reason).
• What it is NOT. It is not a live link. It is not a second catalogue with separate permissions (future). It does not settle template scientific content (D4-06, T-SI-03).

3.5 NotificationContentPolicy

• What it is. A versioned project-level setting that says which content classes may appear in emails and digests for that project. The in-app inbox keeps its own read-time detail rules.
• Content classes (PROPOSAL defaults).

Class	Default	Shown only when (checked at send time)
Project name	On	The recipient is an active member
Study title and short bibliographic context	On	The recipient may view that Study
Actor reference	Role or context-local alias	Real names only where the recipient may see identities and the form's or profile's blinding does not apply
Answer values	Off	The policy allows them, the recipient may see those answers, and blinding permits
Free text (notes, rationale, conversation messages)	Off	The policy allows it, the recipient may see it, and blinding permits
Link to the item	Always	Opening it rechecks access in SyRF

• Identity and versions. (projectId, version), immutable versions with actor and time; one current pointer.
• Storage (PROPOSAL). A small pmNotificationContentPolicy collection, owned by the notification programme and read by both email processors after the C15 resolver and disclosure policy.
• Recipients. A recipient may choose minimal emails for themselves; a recipient can never widen the project's policy (PROPOSAL).
• What it is NOT. It is not a blinding setting. Blinding stays owned by the annotation form and screening profile. The policy can only narrow what disclosure already allows.

3.6 Per-project email mute

NotificationEmailPreferences gains a set of muted project IDs with the time each was muted (PROPOSAL). A muted project sends no immediate or digest email to that person. Inbox rows are still captured, and the badge and My work counts are unaffected (D3-07).

3.7 Notice resolution

InboxNotification gains ResolvedAtUtc and resolution {reason, sourceTransition, resolvedByRef} (PROPOSAL; domain model §4.10 already reserves ResolvedAtUtc for D3-23). Reasons: decided, completed, withdrawn, expired, superseded. resolvedByRef is shaped by the disclosure policy on read (an alias or role where blinding applies). The unread count is "unread and unresolved". Workflow state stays in the feature aggregate; read state never resolves a workflow (C15).

3.8 Reconciliation conversations as audit records

StudyConversation (#3944 with #3965's one-to-one changes) is retained as a project audit record while the project exists, including while it is in the reversible deleted state. It has no TTL. Export needs an audit or export capability and follows the identity-disclosure policy (C10 export disclosure contract). Conversation text never appears in candidate-answer exports or agreement statistics; the "questioned in reconciliation" exposure markers remain (ExposureLedger, AC-R5c-07). Ownership moves to lane L6 at R4a.

3.9 Notification enablement controls

• G-NOTIF approvals. Chris approves each environment (preview, staging, production) and each kind family (the email categories in notifications integration §3) separately; approvals are recorded in the flag audit.
• Per-project notification admission. A CanonicalEnrolment scope (NS-04). Pilot projects are admitted first; broader admission follows a pilot exit review.
• Test email sink. Outside production every email goes to Mailpit; the hermetic e2e stack is used for tests; no test mail reaches real users.
• Operator delivery pause. A global and per-family halt that pauses dispatch without cancelling it. Paused items keep their send-time checks, so content is shaped when they are finally sent.
• Flag dependencies. notificationEmail declares its dependency on notificationInbox; inbox reads stay available whenever saved items exist, whatever the capture flag.
• What it is NOT. Approval of this page enables nothing.

3.10 ActiveWorkImpactPreview

• What it is. The shared preview shown before any admin action that affects reviewers: active reviewers and reconcilers (counts for everyone; names only with Monitor, never across blinding), open drafts, reservations and claims, in-progress sessions and tasks, dependent results, pool and eligibility changes, and the notices that will follow.
• Storage. Computed at read in one pinned snapshot; not stored. The command stores the preview's digest and a compact summary for audit (PROPOSAL).
• Commit. The command recomputes the digest in its own snapshot. If it changed, nothing is committed and the actor sees "The impact has changed. Review it again."
• What it is NOT. It is not permission. A preview never grants the actor anything the action does not already allow.
• Screen pattern. The shared preview screen is specified in UX §3.9; this page owns the rules.

4. What loads and writes when

4.1 Summary table

Action	Reads	Writes	Transaction boundary	Derived afterwards
Delete own account	Investigator, memberships, reservations, assignments	Deactivated; reservation and assignment releases through intents	One Investigator write plus durable intents	Presence, capacity, admin notices
Disable membership	Membership, preview inputs	Membership status and history; optional exclusion	One Project write; exclusion as §4.3	Access refused on the next command
Exclude contributions	Member's contributions in scope, dependent results, active tasks	Exclusion record, operation record, notice intent, history event	One short transaction	Sweep updates summaries; readiness and outcomes recompute
Lift an exclusion	Exclusion, preview inputs	Lift record, operation record, notice intent	One short transaction	Sweep restores standing
Delete a project	Project, active work, running operations	Deleting, fence, operation record; then per-Study markers and releases; then Deleted and the deletion record	Fence, sweep in short per-Study transactions, final commit	Hidden from lists; notices stop
Restore a project	Deletion record, current configuration	Restoring, operation; per-Study unmarking; Active and the restoration record	Fence, sweep, final commit	Pools, availability, capacity recomputed; no reservation revived
Catalogue direct entry	Catalogue item draft	Catalogue item version	One write	Catalogue listing
Share a project definition to the catalogue	Project definition version	Catalogue item version with provenance	One write	Catalogue listing
Request publication	Project definition version	Publication request	One write	Catalogue administrators' queue
Decide a request	Request, source version	Request decision; catalogue item version if approved	One transaction	Requester's queue
Copy a catalogue item into a project	Catalogue item version	Project-owned definitions with copiedFrom	One transaction	Project design views
Change the content policy	Current policy	New policy version	One compare-and-set	Applies to emails sent from then on
Mute a project	Preferences	Preferences update	One write	Email workers skip the project
A domain event creates a notice	Source transaction state	Inbox rows inline, or a fan-out intent	Inside the source transaction	Badge hint; email queued per preference
Send an email or digest	Row, resolver, disclosure policy, content policy, recipient's current access, mute	Delivery ledger row	One ledger write per item	n/a
Work item resolves	Feature aggregate transition	Resolution intent keyed by the source	Inside the resolving transaction	Rows marked resolved by the dispatcher
Export conversations	Conversations, capability, disclosure policy	Export job and manifest	Export job	n/a
Pause or resume delivery	Halt state	Halt state with operator and time	One write	Workers stop or resume
Admit a pilot to notifications	Enrolment, G-NOTIF approval	Enrolment scope	One write	Capture starts for that project

4.2 Deleting an account (example of the walkthrough format)

1. Dana confirms account deletion. The confirmation explains that her submitted work keeps her name.
2. One write sets Deactivated = true. The same transaction writes durable intents to release Dana's reservations and claims and her unstarted reconciliation assignments (PROPOSAL).
3. Afterwards the dispatchers release places and notify project admins that assignments were released.
4. Dana's drafts are kept but unusable. Her contributions keep counting (D4-20).

4.3 Excluding contributions

1. The admin opens "Exclude contributions" from a member's page or from the disable-membership dialog.
2. They choose the scope (form, profile, stage or project) and enter a reason.
3. The preview runs in one pinned snapshot. It lists:
4. contributions that will stop counting, grouped by form or profile, with Study counts;
5. Studies whose sufficiency or readiness changes;
6. collective screening outcomes whose candidate facet changes, and resulting pool entries or departures;
7. dependent results that used the contributions (accepted results, adjudications, merge-resolved results) and their authors;
8. reconciliation tasks in progress whose candidate set changes, and their holders;
9. for stage scope, contributions with mixed route provenance, each needing an explicit choice;
10. whether the member can still review the scope.
11. The admin confirms. The command recomputes the digest; if it changed, it stops.
12. One short transaction writes the exclusion record, the operation record, the notice intent and a ContributionExcluded history event (C20).
13. The operation sweeps affected Studies in short transactions, updating each canonical summary. Readiness for affected Studies fails closed until its Study is swept.
14. Afterwards: affected reconcilers and authors of dependent results are told; dependent results are flagged; pool membership changes are recorded as structured events with the exclusion as cause.

4.4 Disabling a membership with optional exclusion

The existing disable dialog gains one optional section, "Also exclude this member's contributions", off by default. Disabling alone preserves contributions. If the admin turns it on, the exclusion flow of §4.3 runs inside the same confirmation, and both changes commit together or not at all (PROPOSAL).

4.5 Deleting a project

1. The owner (or a Delete holder) chooses "Delete project" and gives a reason.
2. The preview shows active reviewers and reconcilers (counts; names with Monitor), reservations, drafts, open tasks, scheduled and running jobs (imports, exports, bulk updates, publications) and what will stop.
3. Running project-wide operations either finish first or are shown as blocking; deletion never starts under a running bulk update (the existing bulk-lock pre-check).
4. On confirmation the command rechecks the digest, raises a deleting fence on the Project, sets deletionState = Deleting and writes the operation record. The project leaves ordinary lists and allocation stops immediately.
5. The operation stamps the deletion marker on each Study and releases its reservations and claims through the existing revocation outbox, in short per-Study transactions. A save that reaches a stamped Study is refused and keeps its draft.
6. A final pass catches late arrivals. The final commit sets Deleted, writes the deletion record and a ProjectDeleted history event, and captures the last project notice to active users.
7. From then on no project notice is captured.

4.6 Restoring a project

1. An authorised admin opens "Deleted projects", selects the project and gives a reason.
2. The preview shows what returns (members, stages, drafts) and that released places are not revived.
3. The command raises a restoring fence, sets Restoring, removes the Study deletion markers in a sweep (ownership markers untouched), recomputes pools and availability, then commits Active with the restoration record and a ProjectRestored event.
4. Members are told. Reviewers start again through normal admission; drafts reappear; capacity is checked when they resume.

4.7 Catalogue copy

1. Ana browses the catalogue and selects "SYRCLE risk of bias" v2.
2. Copying writes project-owned question, form or profile definitions in one transaction, each with copiedFrom provenance. The project copy starts as a draft for Ana to review and publish.
3. Nothing in the catalogue changes. Later catalogue versions leave Ana's copy untouched.

4.8 Catalogue publication request

1. Ben, a project designer, requests publication of his project's form v4.
2. The request records Ben, the exact source version and a note. Catalogue administrators see it in their queue.
3. Approval creates a catalogue item version copied from v4 with Ben as source sharer and the approver recorded. Ben's project definition is unchanged.

4.9 Sending an email or digest

1. A domain event captured an inbox row with a generic title and link (C15).
2. The email worker picks the item according to the recipient's category preference and project mute.
3. At send time it runs the kind's resolver and the disclosure policy with the recipient's current access and the relevant form's or profile's blinding, then applies the project's content policy.
4. If the recipient has lost access, the email is suppressed (PROPOSAL: the ledger records "suppressed: access"). If the item has been resolved, it is dropped from action lists.
5. One delivery-ledger row records the send. An ambiguous send is never retried (existing #3942 behaviour). Sent email cannot be recalled.

4.10 Auto-resolving notices

1. A workflow item resolves in its feature aggregate (for example, one admin approves a completed-stage change request).
2. The same transaction writes a resolution intent keyed by the item's source identity.
3. The dispatcher marks every related row resolved, idempotently, with the reason and resolver reference.
4. Unread counts exclude resolved rows at read time. Opening a row always shows current state from the resolver, so nobody acts on a stale notice even before the dispatcher runs.

5. Rules

ID	Rule	Basis
ACD-R01	Ordinary account deletion disables sign-in and access. The Investigator record keeps the person's name and submitted contributions keep named attribution.	Owner decision; D2-14 amended; consolidation §6
ACD-R02	No identity-erasure process is decided. Nothing on this page claims legal sufficiency. Canonical records keep storing opaque investigator GUIDs so that a future process remains possible.	Owner decision (not decided); T-POL-02; PROPOSAL for the storage rule
ACD-R03	Project joining terms explain that contributions remain attributed after leaving, disabling or deleting an account. The wording is verified before release.	Owner decision; D2-14; register "Decisions already fixed"
ACD-R04	Disabling a membership or deleting an account never invalidates, withdraws or uncounts submitted contributions.	Owner decision; D4-20
ACD-R05	Reviewers cannot unilaterally withdraw submitted contributions by leaving or disabling their account. This rule concerns leaving and account changes; an explicit Withdraw session version made while still a member follows the C5 ADR and the Q-27 warning (RD §3.9, §4.5).	Owner decision; O1 amendment; scope note PROPOSAL
ACD-R06	Authorised project admins may explicitly exclude a member's contributions from current use for a selected form, screening profile, stage or the whole project, including from the membership-disable workflow.	Owner decision; O1 amendment
ACD-R07	Every exclusion requires an impact preview, a reason, the actor and the time.	Owner decision; O1 amendment
ACD-R08	Submitted versions and named attribution remain immutable and accessible in history after exclusion.	Owner decision; O1 amendment
ACD-R09	Stage-scoped exclusion identifies contributions by recorded route provenance and previews effects across all routes and dependent results. Contributions with mixed provenance need an explicit choice before commit.	Owner decision; O1 amendment; PROPOSAL for the mixed-provenance choice
ACD-R10	Dependent results stay intact. Their authors are informed. New result versions are created only through an explicit decision.	Owner decision; O1 amendment; Q-27
ACD-R11	Derived current states (sufficiency, readiness, candidate collective outcomes, pool membership, statistics) recompute from non-excluded evidence. Pool changes caused by an exclusion are recorded as structured events with the exclusion as cause.	PROPOSAL; consolidation §3 structured history
ACD-R12	An exclusion covers contributions recorded before its effective time and does not block future work. Lifting it is a separate recorded action with its own preview and reason.	PROPOSAL; ambiguity B2
ACD-R13	Exclusion is offered only on canonical scopes. Before conversion, membership disable preserves contributions and no exclusion exists.	PROPOSAL; ambiguity B7
ACD-R14	Ordinary whole-project deletion is reversible removal from normal use. It hides the project from ordinary lists, blocks review and editing, stops new allocations and project notifications, releases active reservations, and preserves drafts, immutable evidence and history.	Owner decision; O1 final clarification; D3-12
ACD-R15	Deletion and restoration record actor, time and reason, and alert affected active users under the impact rules.	Owner decision; O1 final clarification
ACD-R16	Stale saves never bypass deletion. The refusal lives on the documents writers already compare-and-set.	Owner decision; O1 final clarification; consistency model §6.1 for the mechanism (PROPOSAL)
ACD-R17	An authorised admin restores a deleted project through a restricted Deleted projects view. Restoration re-evaluates availability and capacity and never revives stale reservations.	Owner decision; O1 final clarification
ACD-R18	Permanent physical erasure is a separate policy and is not authorised by ordinary deletion. No scheduler physically deletes a deleted project's data.	Owner decision; T-POL-01
ACD-R19	Search withdrawal hides only the Studies that the withdrawn search alone supports and keeps Citations and evidence. It stays distinct from project deletion.	Owner decision; D3-12; Q-33
ACD-R20	There is one application-wide CAMARADES catalogue administered by users with a system permission. Future catalogues may have distinct permissions.	Owner decision; D2-15 amended
ACD-R21	Authorised direct entry and project sharing create versioned catalogue copies with source, version and sharer provenance. Copies into projects carry catalogue item and version provenance.	Owner decision; D2-15 amended
ACD-R22	Project and catalogue edits never silently overwrite copies in either direction.	Owner decision; D2-15 amended; DP4, SET1
ACD-R23	Other users may request catalogue publication. A request records the exact source version and is decided by a catalogue administrator.	Owner decision; D2-15 amended
ACD-R24	Emails and digests may include project and study context, including study titles.	Owner decision; D3-22 amended
ACD-R25	Aliases and all email content respect the recipient's permissions and the configured blinding of the relevant form or profile. Answers and free text are configurable per project, not universally omitted.	Owner decision; D3-22 amended
ACD-R26	Authorisation and blinding are checked when each email or digest is prepared for delivery. Sent email cannot be recalled by later access removal.	Owner decision; D3-22
ACD-R27	Answers and free text are off by default in the project content policy; project name, study title and links are on.	PROPOSAL; ambiguity B6
ACD-R28	A person can mute email for one project. In-app notices are still recorded, and My work and the badge are unaffected.	Owner decision; D3-24; D3-07
ACD-R29	Reconciliation conversations are retained as project audit records while the project exists, exported only with the audit or export capability under the identity-disclosure policy, and excluded from candidate-answer exports and agreement statistics. Exposure markers are retained.	Owner decision; D3-25
ACD-R30	Notifications are enabled only per environment and kind family with Chris's approval (G-NOTIF), for admitted pilot projects first, and more broadly only after a pilot exit review.	Brief item D3-21
ACD-R31	Outside production, email goes only to the test sink. An operator delivery pause halts dispatch without cancelling and resumes without loss or duplicates.	Brief item D3-21
ACD-R32	When a workflow item resolves, related notices are marked resolved and leave unread counts. Their history is kept, and opening one shows current state.	Brief item D3-23
ACD-R33	Active-work impact previews apply to every admin action that affects reviewers. They show the impact before commit, recheck at commit and inform affected people after.	Owner decision; consolidation §6; Q-27
ACD-R34	Apply anyway may release temporary reservations made incompatible by a change, such as a capacity reduction, while preserving drafts and saved work. It never bypasses permissions, valid configuration, allocation constraints, validation or mandatory publication and re-review treatment.	Owner decision; consolidation §6; Q-24
ACD-R35	Apply anyway is offered only to an actor authorised for the underlying change, applies to the exact proposal previewed, and is invalidated by any edit to the proposal. The server reloads current impact at commit and keeps the earliest still-valid reservations where capacity remains.	Owner decision; Q-24; review eligibility policy D6 (PROPOSAL for the retention order)
ACD-R36	Reviewer names in previews require the Monitor capability and never cross reconciliation identity blinding.	Brief item D3-20 (SP owns); C10

6. Authorisation, blinding and provenance

Capabilities (PROPOSAL mapping to the C10 catalogue at F1b):

Action	Who	Notes
Delete own account	The account holder	Existing
Disable or enable a membership	Edit memberships holders	Existing; owners, admins and oneself cannot be disabled
Exclude or lift contributions	A new "Exclude contributions" capability, owner-grantable within the delegation envelope	Separate from Edit memberships
Delete a project	The project Delete capability (owner-only today; Q-03 matrix)	Existing catalogue entry
View deleted projects and restore	Project owner and Delete holders for their projects; application administrators with a system permission	Ambiguity B4
Administer the catalogue	Application role "Catalogue administrator"	System-scoped
Share into the catalogue	Catalogue administrators	Others request publication
Request publication	Project Design holders	Request only
Change the content policy	A project notification-settings capability, held by admins by default	Narrowing only
Mute a project	The recipient	Self-service
Export conversations	Audit or export capability under the export disclosure contract	Unmasking audited
Pause delivery	Operators	Audited
Approve enablement (G-NOTIF)	Chris	Per environment and kind family

Blinding.

• Emails, digests, inbox detail and auto-resolve "resolved by" references use the blinding of the relevant annotation form or screening profile, never a stage-owned alias source. Aliases are context-local and must not identify the same reviewer across Studies (consolidation §4).
• Exclusion previews show the excluded member's name to the admin, who already administers memberships. They show candidate answers only where the admin may see them.
• Conversation exports apply the identity-disclosure policy; any unmasking is audited.
• Catalogue items carry no project evidence, so blinding does not arise.

Provenance. Every action here records the real actor (support impersonation records the real actor), the time and the command ID, and writes a structured history event (C20): ContributionExcluded, ContributionExclusionLifted, ProjectDeleted, ProjectRestored, CatalogueItemVersionPublished, CatalogueCopyCreated, CataloguePublicationRequested, CataloguePublicationDecided, NotificationContentPolicyChanged, NotificationDeliveryPaused, NotificationDeliveryResumed (PROPOSAL type names). Notification admission and G-NOTIF approvals use the flag audit.

7. Active-work impacts

The same preview, recheck and notify pattern applies to every admin action that affects reviewers. This table covers the actions owned here and the general Apply anyway rule; other specs own the content of their previews.

Admin action	Preview shows	Recheck at commit	Notified after	Apply anyway
Lower a capacity cap or effective target	Reservations above the new limit, their holders, drafts	Digest; current claims reloaded	Holders whose place is released	Yes: releases the latest incompatible reservations; drafts kept
Lower a form's in-progress limit or change step or allocation settings that invalidate reservations	Reservations that become incompatible	Digest; current claims reloaded	Affected holders	Yes, reservations only
Exclude contributions	§4.3 list	Digest	Dependent-result authors, task holders	No (nothing is released)
Disable a membership	The member's reservations, assignments, drafts; optional exclusion preview	Digest	Admins; task holders affected by released assignments	Not needed (the member's places are released by the action itself)
Delete a project	Active users, reservations, drafts, jobs	Digest; fence	Active users	Not needed (deletion releases places by definition)
Restore a project	What returns; places not revived	Digest	Members	No
Publish a form or profile version	Owned by the review-domain and reconciliation specs	Phase-1 digest	Per Q-20	No, except a publication that lowers the standard target, which may release incompatible temporary reservations only (RD §7)
Merge or unmerge duplicates	Owned by the duplicate-merge spec	At commit	Per DM spec	No
Baseline conversion cutover	Owned by the baseline conversion spec	Lock phase	Per BC spec	Never

Apply anyway walk-through. The first save of a conflicting change commits nothing and explains the impact, for example: "Lowering the cap to two would release Kim's reserved place on 3 Studies. Saved reviews and drafts will be kept." The actor chooses Cancel or Apply anyway. On Apply anyway the server reloads the current impact, validates the proposal, keeps the earliest still-valid reservations where capacity remains, and commits the settings and releases together. Affected reviewers are told; their pages refresh without losing unsaved input. An intervening edit by someone else requires conflict handling; it is never overwritten.

8. Failure and recovery

Failure	Handling	User sees
Preview digest changed before commit	Nothing commits	"The impact has changed. Review it again."
Exclusion sweep crashes	Lease expiry, takeover, resume; gates read exclusions directly meanwhile	Progress; no wrong admission
Deletion sweep crashes	Takeover leads forward to Deleted; marked Studies stay refused	The project stays hidden; "Deleting" in the admin view
Restoration sweep crashes	Takeover leads forward to Active	"Restoring" in the admin view
Save arrives after a Study's deletion marker	Typed refusal; draft kept	"This project has been deleted. Your draft is kept."
Deletion requested during a bulk update	Refused by the bulk-lock pre-check	"Wait for the bulk update to finish"
Recipient lost access before send	Email suppressed; ledger records why	Nothing sent
Ambiguous email send	Never retried (existing behaviour)	Possibly no email; inbox has the item
Delivery paused	Items wait; content shaped at actual send	Delayed email
Resolution intent delayed	Badge may lag; opening the row shows current state	A brief stale badge
Catalogue copy fails	One transaction; nothing partial	Retry
Publication request on a changed source	The request pins the exact version; approval copies that version	Approver sees the pinned version
Conversation export refused mid-flight	Export job fails closed; partial files never delivered	"Export unavailable"

Recovery from data loss follows D2-13 (baseline conversion §8.4). A restore never resurrects a deleted project as active or erases a restoration record.

9. User flows and examples

People and projects are illustrative.

E1. Dana deletes her account (completed, historical)

Dana reviewed 120 Studies in "Sepsis models" and has one unfinished draft. She deletes her account. The confirmation says: "Your submitted reviews will stay in the projects you contributed to, with your name." She can no longer sign in. Her draft is kept but nobody can continue it. Her reservation on one Study is released and the admins are told that her unstarted reconciliation assignment was released. In the project her decisions show "Dana Reid (account deleted)" to people who may see identities, and they keep counting.

E2. Omar disables Sam and excludes his extraction work (pending, completed)

Omar, an admin of "Sepsis models", learns that Sam extracted outcome data without the required training. He opens Disable membership for Sam and turns on "Also exclude this member's contributions".

1. He chooses scope "Form: Outcome extraction" and reason "Not trained for outcome extraction".
2. The preview (pending until confirmed) shows: 14 Studies lose a qualifying contribution and no longer meet the target of two; 3 accepted results used Sam's input (authors Kim and Lee); 2 reconciliation tasks in progress lose a candidate (holders Kim and Priya); Sam's screening decisions are unaffected.
3. Omar confirms. Both changes commit together.
4. Kim, Lee and Priya are told. The 3 accepted results stay current with "inputs changed: contribution excluded". Kim reconsiders one and creates a new accepted version; the other two stay as they are.
5. The 14 Studies reappear in the pool for more extraction. Sam's sessions remain in history with his name and an "excluded from current use" marker.

E3. Stage-scoped exclusion with mixed provenance (conflict)

Form F is used in Stage A and Stage B. Sam's session on Study 42 has version 1 completed through Stage A and version 2 completed through Stage B, which reuses answers first written in Stage A. Omar excludes Sam's contributions for Stage A only. The preview lists Study 42 under "Mixed provenance: the current version was submitted through Stage B but includes answers first written in Stage A". Omar must choose "exclude the whole contribution" or "keep it" for that group before he can confirm.

E4. Deleting and restoring a project (unavailable, historical)

Dr Okafor owns "Pilot 2024". She deletes it with reason "Pilot finished". The preview shows 3 active reviewers, 5 reservations and 2 drafts.

1. During deletion, Kim is mid-form. Her next save is refused: "This project has been deleted. Your draft is kept." (unavailable).
2. The project disappears from lists. No more notices are captured.
3. Two months later, Dr Okafor restores it from Deleted projects with reason "Analysis resumed". The preview says the 5 released places will not come back.
4. Kim reopens her Study. Her draft is there. Admission checks capacity again; a place is free, so she continues. The project's audit timeline shows both actions (historical).

E5. An informative, blinded email (completed)

"Sepsis models" uses the default content policy and blinded reconciliation on form "Outcome extraction". Lee, a candidate, receives: "A reconciler has a question about your review of 'Hypothermia and infarct volume in rats' in Sepsis models." The question text is not in the email, because free text is off. Kim, the reconciler, receives "Reviewer B replied about 'Hypothermia and infarct volume in rats'" using the same context-local alias she sees in that Study's task. If Lee had lost access before the email was sent, it would be suppressed.

E6. Muting one project (empty)

Kim mutes email for "Sepsis models". She still sees its notices in the inbox and her My work count. A week later her digest contains nothing from that project; with no other activity, no digest is sent (empty).

E7. Auto-resolved approval notices (completed, historical)

Three admins receive "A change to the completed stage 'Full text' needs approval". Omar approves it. The other two notices change to "Decided by Omar" and leave the unread counts. All three stay in history.

E8. Catalogue use and a publication request (pending, completed)

Ruth, a catalogue administrator, publishes "SYRCLE risk of bias" v1 (content pending methodologist curation, T-SI-03). Ana copies it into her project; her copy records the catalogue item, version, her name and the time. Ruth later publishes v2; Ana's copy is unchanged and her design page notes that v2 exists. Ben requests publication of his project's "Behavioural outcomes" form v4. The request is pending in Ruth's queue; when approved, a catalogue item copied from v4 appears with Ben and Ruth recorded.

E9. Enabling notifications for a staging pilot (loading, failure)

Chris approves staging for the "Work assigned to me" family. Operators admit two seed projects. Email goes to Mailpit. During a test, the operator pauses delivery: queued items wait (loading state in the operator view) and resume without duplicates. A send to a revoked reviewer fails its send-time check and is suppressed (failure handled safely).

E10. Capacity reduction with Apply anyway (conflict, completed)

Priya lowers the capacity cap on form "Outcome extraction" from three to two (from the effective target plus one to the effective target, which is two; SP §3.11). Two Studies have three reservations. The save is refused with the impact. Priya chooses Apply anyway. The server reloads the current claims, keeps the two earliest, releases the third and commits. The released reviewer keeps their draft and sees "Enough reviewers are working on this Study. Your draft is kept."

10. Rollout and adoption

Capability	Scope class	Lands in (PROPOSAL for the rollout drafter)	Flag	Dependencies
Named attribution on account deletion	Baseline (existing behaviour kept)	R1b (display and joining terms)	None; joining-terms text behind the release	Legal review of wording
Contributions kept after membership disable	Baseline	R1b with the membership programme	Existing disableMembership	#3335 membership schema
Contribution exclusion	Baseline for canonical scopes	Form scope R2a; profile scope R3b; stage scope R3a (route provenance and pools); project scope after both; dependent-result flags R4a and R4p	New default-off contributionExclusion	C20 events; operation records
Reversible project deletion and restoration	Baseline	The deletion-lifecycle programme (X-DEL), amended; canonical parts with R2a (claims, drafts) and R3a (pools)	Existing deletionLifecycle	Composite write guard (R0); before universal conversion waves
Catalogue MVP and copy provenance	Baseline	R1a (questions and forms), R3b (profiles), C1 (entity types), O1 (outcome schemas)	Per release	D4-06 content via T-SI-03
Catalogue publication requests	Baseline	R1a	Same	Catalogue administrator role
Email content policy	Baseline before any production email	Notification programme with C15 v2 disclosure	Under notificationEmail	X-NOTIF stack steps 1 to 5
Per-project email mute	Baseline before any production email	Notification programme	Under notificationEmail	#3942 preferences
Auto-resolve	Baseline	R3c (approvals) first, then R4a (assignments) and R4b (queries)	Under notificationInbox	C19 intents
Conversation retention and export	Baseline	F4 and R4a (L6 ownership); export in R5a	reconciliationConversations	#3965
Enablement gates, test sink, delivery pause	Baseline before any enablement	Notification programme (E74)	Environment flags plus per-project admission	#3975 fixed before relying on runtime overrides
Active-work impact previews and Apply anyway	Baseline	Shared component first in R2c and the guarded settings save; each admin action in its own release	Per action	D3-20 disclosure
Permanent physical erasure	Not approved	None	n/a	T-POL-01
Identity-erasure process	Not decided	None	n/a	T-POL-02
Further catalogues with distinct permissions	Deferred	Later	n/a	Owner decision

Every release passes its acceptance tests with every notification flag off, because feature queues carry confirmed obligations (notifications integration §4.1).

11. Acceptance evidence

ID	Evidence	Method	Amends
ACD-AE01	After account deletion, sign-in is refused; submitted contributions show the person's name to authorised viewers and keep counting; drafts are kept; reservations and unstarted assignments are released with admin notices.	Integration; E2E	Replaces AC-R2a-30
ACD-AE02	Canonical records hold only opaque investigator GUIDs (schema check); no anonymisation runs on account deletion.	Integration; inspection	AC-R2a-30 (storage half kept)
ACD-AE03	The join and invitation screens show the contribution-retention text; legal review is recorded before release.	E2E; inspection	New
ACD-AE04	Disabling a membership leaves the member's completed contributions counted in qualification, reconciliation and statistics.	Integration	AC-R2a-45
ACD-AE05	Each exclusion scope (form, profile, stage, project) removes exactly the expected contributions from qualification, readiness, candidate outcomes, pools and current statistics on fixtures, and nothing else.	Integration	AC-R2a-45
ACD-AE06	Stage-scoped exclusion selects by route provenance; a shared session's versions submitted through another stage are unaffected; mixed-provenance groups block confirmation until chosen.	Integration; E2E	New
ACD-AE07	Exclusion is refused without a reason; the record holds reason, actor, time and preview digest; a changed digest blocks commit.	Integration	New
ACD-AE08	After exclusion, excluded versions remain readable in authorised history with attribution; as-of exports before the exclusion include them; current exports omit them unless an exporter opts in, labelled.	Integration	New
ACD-AE09	Dependent accepted results and adjudications stay current and flagged; their authors receive notices; no new result version appears without an explicit reconsideration.	Integration	New
ACD-AE10	Pool entries and departures caused by an exclusion are recorded as structured events naming the exclusion.	Integration	New
ACD-AE11	Lifting an exclusion restores current use from the lift time with its own record and preview.	Integration	New
ACD-AE12	A deleted project is absent from ordinary lists and searches; review, editing and allocation commands are refused with a draft-keeping message; no project notice is captured.	Integration; E2E	Replaces AC-P1-16 (project part)
ACD-AE13	Under forced interleaving, no save lands on a Study after its deletion marker, for legacy and canonical writers.	Integration with failure injection	New
ACD-AE14	Deletion releases every reservation and claim of the project and keeps every draft, version, history event, conversation and statistics row.	Integration; checksum comparison	New
ACD-AE15	Restoration from the Deleted projects view returns the project to lists, revives no reservation, recomputes pools and availability, and admits returning reviewers through normal capacity checks.	Integration; E2E	New
ACD-AE16	Deletion and restoration records hold actor, time, reason and preview digest; both appear in the audit timeline.	Integration	New
ACD-AE17	No job, TTL or scheduler physically deletes a deleted project's data.	Inspection; integration	Supersedes the deletion-lifecycle 24-hour rule for projects
ACD-AE18	Search withdrawal hides only Studies supported solely by that search and keeps Citations and evidence.	Integration	AC-P1-16 (search part)
ACD-AE19	Only catalogue administrators publish or share into the catalogue; others can only request; requests pin the exact source version.	Integration	AC-R1a-10
ACD-AE20	Copying a catalogue item creates project definitions with full copiedFrom provenance; later catalogue versions and project edits leave each other unchanged.	Integration	AC-R1a-10
ACD-AE21	Email and digest content follows the project content policy and the disclosure policy per channel and role (candidate, reconciler, admin, revoked, blinded) in fixtures: titles appear when allowed; aliases are context-local; answers and free text appear only when the policy and recipient rights allow.	Integration (C15 disclosure fixtures)	Replaces AC-ALL-30
ACD-AE22	Access and blinding are evaluated at send time: revoking a recipient between capture and send suppresses the email.	Integration	New
ACD-AE23	A muted project sends no immediate or digest email to that person while inbox rows, the badge and My work counts continue.	Integration; E2E	AC-ALL-31
ACD-AE24	When a workflow item resolves, every related notice is marked resolved with reason and resolver reference and leaves the unread count; history keeps it; opening a not-yet-marked notice shows the resolved state.	Integration; E2E	AC-R3c-12 (generalised)
ACD-AE25	Conversations are retained with no TTL while the project exists (including deleted), export only behind the audit or export capability with the disclosure policy, and never appear in candidate-answer exports or agreement figures; exposure markers remain.	Integration	AC-R5a-12
ACD-AE26	Capture happens only for admitted projects in approved environments and kind families; email outside production reaches only Mailpit; no notice or email reaches a user outside admitted pilots.	Integration; pilot monitoring	AC-ALL-29; PE-08
ACD-AE27	The delivery pause halts dispatch within one worker cycle and resumes without loss or duplicates; paused items are shaped at actual send.	Integration	AC-ALL-29
ACD-AE28	Every admin action listed in §7 shows a preview, rechecks its digest at commit and notifies affected users; names appear only for Monitor holders and never across blinding.	Integration; E2E	AC-ALL-03 (blinding part)
ACD-AE29	Apply anyway releases only incompatible reservations, keeps drafts and saved work, keeps the earliest valid reservations, refuses any proposal that is unauthorised, invalid or breaks allocation constraints, and is invalidated by any edit of the proposal.	Integration; E2E	New
ACD-AE30	With every notification flag off, each release's acceptance tests still pass and affected users find their work through My work and the badge.	E2E	Notifications integration §4.1

12. Brief items, specialist inputs and unapproved proposals

12.1 Brief items this spec owns

Entry	Required treatment	Tracker
D3-21	Specify per-environment and per-kind-family G-NOTIF approvals, per-project notification admission with pilots first and a pilot exit review, the Mailpit test sink, the operator delivery pause (global and per family), the notificationEmail dependency, inbox reads independent of capture, and no reliance on runtime overrides while #3975 is open. Approval of this specification enables nothing.	T-AC-00
D3-23	Specify resolution reasons, the resolution intent and dispatcher, unread-count consistency, digest behaviour for resolved items, and disclosure of the resolver reference.	T-AC-00

12.2 Policies not approved

• T-POL-01 permanent physical erasure. Ordinary deletion never erases. Any future erasure policy must state what is erased, from which stores, how manifests record it and how restoration is prevented.
• T-POL-02 identity-erasure process. Not decided. AC-R2a-30's anonymisation and the erasure parts of AC-R5a-09 and C11-T05 become conditional on this policy.

12.3 Specialist inputs and reviews

• Legal review of the joining-terms and account-deletion wording (not a T-SI item; owner to route).
• Template content for the catalogue (D4-06, T-SI-03).

12.4 Thresholds (proposed, not approved)

• The inline notification recipient limit above which recorded fan-out is mandatory (proposal: 200).
• The interval within which a resolution must reach every related notice.
• Any retention period for conversation exports or delivery-ledger rows (E32).

12.5 Ambiguities found while drafting

B1. An adjudicated screening outcome whose input decision is excluded (closed, 5 October harmonisation). This is no longer an ambiguity. The owner rule decides it: Q-27 (warn the actor before commit, inform affected authors, never rewrite dependent work automatically), the O1 amendment ("existing dependent results remain intact, with affected authors informed and new result versions created only through an explicit decision") and consolidation §1 ("Existing accepted/dependent work is never silently rewritten"). The admin is warned in the exclusion preview; the adjudicator and other affected authors are informed; the adjudication stays the current final facet, flagged "inputs changed: contribution excluded"; and a new AdjudicationVersion is created only through an explicit reconsideration. RS-R58 applies the same rule to corrections. The recovered 25 September clarification (consistency model §8.4), earlier called the DP2 rule here, no longer applies after resolution.

B2. Lifting an exclusion. The owner did not say whether an exclusion can be reversed. Options: (a) allowed as a separate recorded action with its own preview and reason; (b) not allowed; a new contribution is needed. Recommendation: (a).

B3. Mixed route provenance under stage scope. Options: (a) the admin must choose per group before commit; (b) decide by the route of the current version only; © decide by the route of each answer. Recommendation: (a), with (b) as the suggested default choice in the UI.

B4. Who can see and restore deleted projects. The owner said "an authorised admin". Options: (a) project owner and project Delete holders for their projects, plus application administrators with a system permission for any project; (b) application administrators only; © project owner only. Recommendation: (a).

B5. Project-to-project copying outside the catalogue. The amended D2-15 names direct entry, project sharing and publication requests. The earlier recommendation also allowed "copy from a project I administer" (AC-R1a-10). Options: (a) keep it as an R1a copy with the same provenance shape, outside the catalogue; (b) drop it, so all reuse goes through the catalogue. Recommendation: (a), because guided setup (SET1) and existing plans rely on it; confirm.

B6. Default email content for answers and free text. The owner made them configurable. Options: (a) off by default; (b) on by default. Recommendation: (a), because sent email cannot be recalled.

B7. Exclusion on unconverted legacy projects. Options: (a) canonical scopes only; (b) also through legacy writers. Recommendation: (a); legacy projects keep contributions after membership disable until they convert.

B8. Notices for deleted projects. Options: (a) existing notices leave unread counts and show "Project deleted", returning if the project is restored and the item is still open; (b) leave them unchanged. Recommendation: (a).

12.6 PROPOSALs an owner may want to see

Exclusion time scope (ACD-R12); exclusion capability separate from Edit memberships (§6); current exports omitting excluded work by default (§3.2); the excluded member not notified by default (PROPOSAL: an admin option, off by default); deleted projects' exports unavailable until restoration (§3.3); the email content defaults (§3.5, B6); recipient "minimal email" choice (§3.5); deleted-project notice handling (B8); the "(account deleted)" suffix (§3.1).

12.7 Harmonisation notes (5 October 2026)

• §12.5 B1: closed. The owner rule (Q-27; O1 amendment; consolidation §1) decides it: warn before commit, inform affected authors, keep the adjudication current and flagged, and create a new version only through explicit reconsideration. RS-R58 now states the same rule for corrections.
• §3.2 "Effects on current use": clarified that stage pools read an existing adjudicated or merge-resolved final facet, which stays current and flagged, so only the candidate facet changes.
• E10: the capacity numbers are tied to SP §3.11's cap values (effective target plus one, then the effective target), matching UX §9.6.
• ACD-R05: added a scope note so the rule is not read as forbidding RD §3.9's explicit Withdraw version by a current member (C5 ADR; Q-27 warning).
• §7 publication row: Apply anyway is available for a target-lowering publication's incompatible reservations, as RD §7 already said; the row previously said "No" outright.

13. Amendments to existing package documents

• contracts.md
• C15 Disclosure bullet: replace "Email and digest: title, project name (D3-22) and link only; never study titles, aliases or free text" with the content policy of §3.5 (study titles allowed; aliases and content follow recipient permission and form or profile blinding; answers and free text configurable; checked at send time; sent email cannot be recalled).
• C15 Disclosure bullet: replace "reviewer references are BL1 aliases from one stage-owned alias source" with "context-local aliases under the blinding of the relevant form or profile".
• C15 Enablement bullet: cite D3-21 as a brief item with §3.9's controls; add per-project email mute and notice resolution (D3-23).
• C10: add the "Exclude contributions" capability, the Deleted projects view and restore permission, the catalogue administrator application role, the notification-settings capability, and contribution exclusion to the disclosure policy for exports and statistics.
• domain-model.md
• §2.1 deletion lifecycle row: replace "whole-project deletion keeps ADR-014's removal with a tombstone" with reversible deletion and T-POL-01.
• §2.1 Identity row, §3 Investigator row and §5 Investigator row: replace "erasure anonymises the Investigator record" and "answers stay attributed to the anonymised identity" with named attribution retained, opaque GUIDs kept, identity erasure not decided (T-POL-02).
• §4.5 DefinitionTemplate: rename the system scope to the catalogue (CatalogueItem, CatalogueItemVersion), add CataloguePublicationRequest and the catalogueId dimension.
• §4.10: InboxNotification ResolvedAtUtc and resolution; StudyConversation retained in the deleted state; NotificationEmailPreferences muted projects; add NotificationContentPolicy.
• Add ContributionExclusion, ContributionExclusionLift, Project.deletionState, ProjectDeletionRecord and ProjectRestorationRecord as PROPOSALs.
• consistency-model.md
• §7.1 fence kinds: add deleting and restoring.
• §7.2 operation kinds: add contributionExclusion, projectDeletion, projectRestoration.
• §9.3: add the resolution intent (D3-23).
• §11.5 erasure: replace "account deletion anonymises the Investigator record" with ACD-R01 and ACD-R02; erasure-in-manifests becomes conditional on T-POL-02.
• §6.3: add the project deletion marker to the composite write guard.
• migration-adoption-rollback.md §1 principle 8: replace "Answers stay attributed to an anonymised identity ... (D2-14)" with named attribution retained and identity erasure not decided; keep the retention-rules requirement (E32).
• notifications-integration.md
• §3: the email-category table gains the content policy note; the "Changes affecting my reviews" category gains contribution exclusion notices; "Project changes" gains project deletion and restoration.
• §4 point 5: shape details with the content policy after the disclosure hook.
• §5 gates: the content policy and per-project mute are prerequisites before any email category is enabled outside Mailpit.
• §6: D3-21 and D3-23 are brief items; D3-22, D3-24 and D3-25 are decided (O2).
• acceptance-criteria.md: replace AC-ALL-30 with ACD-AE21; AC-ALL-31 status becomes confirmed; AC-ALL-29 and PE-08 stay pending-D3-21 as brief items; replace AC-R2a-30 with ACD-AE01 and ACD-AE02; AC-R2a-45 becomes ACD-AE04 and ACD-AE05 (status confirmed); replace AC-P1-16 with ACD-AE12 and ACD-AE18; AC-R1a-10 becomes ACD-AE19 and ACD-AE20 (status confirmed); AC-R3c-12 becomes ACD-AE24 (brief item D3-23); AC-R5a-12 status becomes confirmed; AC-R5a-09 and C11-T05 become conditional on T-POL-02; add ACD-AE06 to ACD-AE17 and ACD-AE28 to ACD-AE30.
• open-questions-and-assumptions.md: D2-14, D2-15, D3-12, D3-22, D3-24, D3-25 and D4-20 rows marked decided or decided-amended with the new wording; D3-21 and D3-23 marked brief items; E32 amended for named attribution.
• integrated-plan.md: P1 row "whole-project deletion follows ADR-014" becomes reversible deletion; the X-DEL join becomes "reversible project deletion and restoration cover the canonical collections; no physical deletion of projects without T-POL-01"; the deletion row in §8's programme table updated likewise; §5.11 G-NOTIF row cites D3-21 as a brief item.
• source-status-inventory.md: the deletion-lifecycle rows note the owner's reversible-deletion decision. The uncommitted deletion design is labelled "ADR-014" in its worktree, but docs/decisions/ADR-014-integrated-study-pdf-viewer.md already uses that number, so the deletion ADR needs a new number when committed.
• decision-register.md: record O1 (contribution exclusion and reversible deletion), O2 (email content, mute, conversations), D2-14 and D2-15 as amended, D3-21 and D3-23 as brief items.
• ux-strategy.md: add the Deleted projects view, the exclusion dialog and preview, the catalogue browser and request queue, and the project notification-content settings to the screen inventory (the UX spec owns the preview UI).
• owner ledger: add O1, O2, D2-14 and D2-15 owner-session entries.

14. Superseded wording

Old wording	New wording	Where it appears today
"account deletion anonymises the Investigator record and answers stay attributed to the anonymised identity (D2-14)"	Named attribution is retained; identity erasure is not decided (superseded wording 10)	Domain model §2.1, §3, §5; consistency model §11.5; migration §1 principle 8; open questions D2-14 and E32; AC-R2a-30
"Notification emails and digests may name the project; never study titles, aliases, answers or free text"	Study titles allowed; aliases and content follow permission and blinding; answers and free text configurable; checked at send time	Open questions D3-22; C15 Disclosure; AC-ALL-30
"reviewer references are BL1 aliases from one stage-owned alias source"	Context-local aliases under form or profile blinding	C15 Disclosure; notifications integration §2 (#3950 item 10 proposal)
"deleting a whole project keeps ADR-014's physical removal with a tombstone"	Ordinary deletion is reversible; permanent erasure is a separate unapproved policy	Open questions D3-12; AC-P1-16; integrated plan P1 row, X-DEL row and programme table; domain model §2.1
"an audited admin action can exclude a reviewer's contributions from a form"	Exclusion by form, screening profile, stage or project, with preview, reason, actor and time, and provenance-based stage scope	Open questions D4-20; AC-R2a-45
"A CAMARADES-curated system catalogue (an application role), plus 'copy from a project I administer'"	One application-wide catalogue with versioned copies, copy provenance and publication requests; project-to-project copy pending confirmation (B5)	Open questions D2-15; AC-R1a-10; domain model §4.5
"Auto-resolve ... Yes" as an open owner question	Brief item D3-23	Open questions D3-23; notifications integration §6
"Notification enablement" as an open owner question	Brief item D3-21; G-NOTIF unchanged	Open questions D3-21; notifications integration §6

15. Existing work reused

2224, custom project groups by nurikarakaya, is the main earlier work for this workstream. Its

API shape, domain rules and tests feed R1c's group management (Q-09), and two of its web pieces feed the R1b Members & groups page. PR-A's subtree-copy algorithm (#2572) and #3934's import receipt feed the catalogue's copy path. The harvest map is authoritative; nothing is ported or closed while the hold lasts.

Entries	Verdict	Target section
H-GRP-01, H-GRP-02, H-GRP-09, H-GRP-10, H-GRP-11	Adapt	R1c groups and grants under C10; §3.10 impact previews; §6 capabilities (T-AC-10)
H-GRP-07, H-GRP-12	Reference only	R1c dialog (T-AC-10)
H-GRP-14	Adapt	R1b Members & groups page (T-AC-11)
H-GRP-13	Reference only	R1b page (T-AC-11)
H-DOM-24	Reference only	§3.4 catalogue copy (T-AC-04)
H-IMP-03	Adapt	§3.4, §4.7 copy provenance (source.kind; AC-R1a-08; T-RD-11)
H-GRP-05, H-GRP-06	Reference only	Outside the programme (#3335 WP-M2; a follow-up issue)
H-GRP-03, H-GRP-04, H-GRP-08, H-GRP-15	Avoid	C10; #3335 gate G-D; owner-reserved activities

What this specification and C10 require that the earlier work lacks.

• Rename, as well as create and delete (AC-R1c-01).
• Schema 1 only, after the authorization programme's membership migration; #2224 invents a schema-0 shape that older binaries would drop.
• AssignPermissions stays owner-reserved until R1d; #2224 grants it to Administrators by default.
• Anti-escalation, audit and notification capture on every group change, and claim release when a Review grant is revoked (AC-R1c-02, AC-R1c-06, AC-R1c-10).
• An active-work impact preview before a group is deleted (§3.10), and refusal or conversion while a training policy or an adjudicator assignment references the group.
• One atomic group-grants command with a base version, and a dialog driven by the catalogue's 22 project and 4 stage activities; #2224's dialog lists 13 and saves by client-side read-modify-write.
• ProblemDetails responses with the right status codes, registered in the endpoint catalogue.
• Copy provenance on every catalogue or file copy (copiedFrom, source.kind), and copies that never change when their source does (§3.4).