Specification overview

Temporary planning index, written on 5 October 2026 from the owner session of 4 and 5 October. This page introduces the nine specifications in this folder and the design-prototype handoff. It adds no requirement of its own. Every requirement lives in a specification and traces to an owner decision or is labelled PROPOSAL. Feature implementation remains on hold (Chris, 5 October 2026). The owner decisions recorded in these specifications are planning approval only. Brief approval and implementation authorisation are separate, given per gate (D1-04), and both are still on hold. No work has started under these specifications, no gate has passed, G0 is not approved and nothing is enabled in production. Every work item is at most "Brief drafted". Storage shapes and names are PROPOSALs until the F1a storage and naming ADRs fix them, and every numeric threshold is proposed, not approved.

Plain-English companion for Chris: the product-owner guide. Related deliverables: the rollout plan, the implementation tracker, the owner-session integration (count reconciliation, superseded register and coverage matrix) and the archived owner-session bundle.

1. Purpose and status

Why these documents exist. Chris asked for detailed specifications that explain the entities, their storage, their versions and pointers, what loads and writes when, authorisation and blinding, active-work impacts, failure and recovery, user flows, rollout and measurable acceptance evidence. He asked for plain English with examples, because vague policy names had been confusing (consolidation §8, items 4 and 5).

What they are. One specification per workstream brief. Each one turns the owner decisions of 4 and 5 October into a design detailed enough for its brief. The nine were drafted in parallel and then harmonised on 5 October 2026; each records its changes under "Harmonisation notes" in §12.

Authority. The owner-session consolidation wins over every older text. Where a specification and an older package document disagree, the consolidation decides first, then the specification. Each specification's §13 ("Amendments to existing package documents") is the authoritative input for updating the rest of the package.

Status of the decisions. Of the 89 owner decisions that were open before the session, 64 are now resolved, replaced, removed or deferred and 25 are alignment, brief or validation entries; none is open. The session left one open, D2-09 (shared-question accepted answers across two forms), and Chris answered it on the status page on 5 October 2026 (Decided-amended; RD §4.14; decision register §1.16). The 74-entry session register holds 52 resolved, replaced, removed or deferred entries and 22 alignment, brief or validation entries. The session's 30 further agreed requirements are amendments outside both counts, with IDs OS-A01 to OS-A30 (§5.4). The full reconciliation is in the owner-session integration.

2. Index

Each specification uses the same fourteen headings: §1 summary in plain English, §2 decisions covered, §3 concepts, entities and storage, §4 what loads and writes when, §5 rules, §6 authorisation, blinding and provenance, §7 active-work impacts, §8 failure and recovery, §9 user flows and examples, §10 rollout and adoption, §11 acceptance evidence, §12 brief items, specialist inputs and unapproved proposals, §13 amendments to existing package documents, §14 superseded wording.

File	Prefix	Brief row	What it covers	Brief entries it owns (of the 25)
spec-review-domain-and-versioning.md	RD	T-RD-00	The Study as the reviewable item; references and source documents; one shared session per reviewer; autosave, Save progress and Complete; versioned questions, forms and profiles; the standard target inside the form version; Study target overrides and additional-review requests; publication with generated versions; collaborative drafting; D2-09	D2-10; engineering contracts D2-03, D2-04, D2-06
spec-duplicate-merge.md	DM	T-DM-00	One consolidated current Study per merge; conflicts resolved or delegated before an all-or-nothing commit; reversible unmerge with per-item choices; bibliography with per-field provenance; "distinct report" outcome	None
spec-stage-pools-steps-and-history.md	SP	T-SP-00	Stage study filters and pools; reviewer study pools and optional browsing; steps, dependencies and exclusion-stop; finishing started work; capacity, timeouts and in-progress limits; structured history events, required queries and the admin eligibility explanation	D3-09, D3-13, D3-16, D3-17, D3-18, D3-19, D3-20
spec-reconciliation-and-screening.md	RS	T-RS-00	Single annotator and one-candidate human reconciliation; accepted-result versions and authority; completeness; blinding and random candidate order; reconciled-answer hints with click-to-fill; outdated answers; Unsure, ties, discussion and adjudication	None
spec-baseline-conversion.md	BC	T-BC-00	Universal faithful conversion of every project after trials and pilots; the conversion wizard and manifests; legacy-gap states; quarantine; the first-canonical-write recovery boundary; isolated point-in-time recovery; legacy-writer retirement	D2-13
spec-training-and-inference.md	TI	T-TI-00	Training steps with reference answers, scoring, manual assessment, retries, group admission and explicit promotion; the classification inference beta (off by default, designer opt-in)	None
spec-reporting-imports-and-ai-screening.md	RI	T-RI-00	Reporting units; PRISMA priority of actual review through a stage; frozen reports; external counts and previous-review counts; search withdrawal; methods documentation; full-text retrieval; exports; AI-model-generated and external screening decisions; agreement and statistics rules	Q-23, D4-08, Q-17, Q-16, D4-12, D4-21, D3-10, D3-11, D4-06
spec-ux-devices-and-work-discovery.md	UX	T-UX-00	Step selector with one form area; status labels; full annotation on phones, tablets and desktops; legacy-screen refresh; My work and the global badge; tester panel and consented timing telemetry; screens for the eligibility explanation, design presence and impact previews; PWA exploration beyond MVP	D3-01, D3-02
spec-access-communications-and-deletion.md	ACD	T-AC-00	Named attribution after account deletion; contribution exclusion; reversible project deletion and restoration; the CAMARADES catalogue; email content policy, mute, notice resolution and conversations; notification gates; active-work impact previews and Apply anyway	D3-21, D3-23
design-prototype-handoff.md	DH	T-DH-00	Self-contained specification for iterating SyRF Prototype v10 in the original design session, traced to these specifications, with a copy-ready prompt; nothing is sent to the design session (OS-A30)	None

The 22 session-register brief entries split as RD 1, SP 7, BC 1, RI 9, UX 2 and ACD 2. The three engineering contracts with no owner question (D2-03, D2-04, D2-06) are RD's, which makes 25.

Suggested reading order. RD first, because every other specification builds on its Study, session, version and target model. Then SP and RS, which describe how work flows and how results form. Then DM, BC and RI. TI, UX and ACD can be read in any order after that.

3. Entity map in plain English

The tables list every main entity, what it is, what it is not, and which specification owns it. "Derived" means calculated when needed and never stored as a fact. Every storage choice is a PROPOSAL; see each owning section for the proposed collection or document.

3.1 Studies, references and documents

Entity	What it is	What it is not	Owner
Study	The item a project screens and annotates. A mutable parent with a state (Current or Tombstoned) and a pointer to its current content version	A citation, a report or an investigation. It does not belong to a stage	RD §3.1; DM §3.1
StudyVersion	An immutable snapshot of a Study's displayed bibliography (each field with its source, actor and time), its reference links and its source-document links	A citation or a FEAT-011 Publication	RD §3.2; DM §3.2
Reference (citation, shown as "record")	One imported row with its raw fields, search, importer and import time. Immutable; it stays on the Study created for it at import	Never edited, moved or fused with another reference	RD §3.3; RI §3.1
Source document (shown as "report")	A real paper, abstract or file linked from a StudyVersion, optionally with a report identity key	A Study. Grouping distinct reports into one investigation is deferred	RD §3.3; RI §3.1
Current evidence view	A stored projection on the Study of its current sessions, results, outcomes and effective targets, for fast reads	Authoritative. It is rebuildable, and its design is proven before freeze	DM §3.6
Tombstone	The state of a Study after a merge or unmerge, with the reason and the successor Study	Corrupt or deleted. A tombstoned Study stays readable in history	DM §3.1

3.2 Definitions, targets and publication

Entity	What it is	What it is not	Owner
Question and question version	A question's stable identity and its immutable versions; each version carries the publisher's compatibility declaration and any option mapping	A pending edit, which lives in a design draft	RD §3.4
Form and form version	A project-level annotation form. Each published version fixes the question pins, the standard reviewer target (FormVersion.standardTarget) and the reconciliation policy (target-one handling, completeness, blinding, hints, outdated-answer mode)	Stage-owned. A stage owns no target, timeout, limit, blinding or hint setting	RD §3.5; RS §3.4
Screening profile and profile version	Eligibility questions and decision rules. Each version fixes sufficiency, Unsure, tie policy and bound, discussion, rationale, blinding and external source policies	The adjudicator assignment, which sits outside the version	RD §3.6; RS §3.7
Design draft and draft change	A named, unpublished proposal for the next form or profile version; each accepted edit is an attributed change. Presence is live connection state	A change to a published requirement	RD §3.7
Publication operation	The operation that publishes a form or profile version, with its preview digest, recorded treatment and impact manifest. It may write attributable generated session versions	The draft or the version it publishes	RD §3.8, §3.15
Study target override	Immutable versions of one Study × form target decision, set by an admin, an additional-review request or a merge confirmation	A capacity cap. No step-level override exists	RD §3.12
Effective target (derived)	The override value where one exists, otherwise the form version's standard target	A stored fact. It is projected for reads	RD §3.12
Additional-review request	A request for more reviews on one or many Studies, optionally naming people or groups; it writes override versions	An invisible bypass, or a way to set an accepted result	RD §3.12
Capacity cap	The maximum number of places on a Study × form: a form baseline, with an optional stricter cap per stage route. Off by default (proposed)	The target, which is a minimum	SP §3.11

3.3 Review work

Entity	What it is	What it is not	Owner
Review session	One reviewer's work on one Study for one form or profile, shared by every stage, tab and device	Owned by a stage	RD §3.9
Session version	An immutable version: a Save checkpoint, a Complete, a Fix, an Upgrade, a Withdraw, a publication-generated version or a merge-created version	A draft. Only qualifying completed versions count towards targets	RD §3.9
Session draft and draft change log	The reviewer's unsaved work over the current version; each autosave appends only the changed answers	Counted, shown to reconcilers or exported	RD §3.10
Connection and place	One record per tab or device, and one capacity place per reviewer per Study × form however many connections use it	The target or the capacity cap	RD §3.11; SP §3.11

3.4 Results and screening

Entity	What it is	What it is not	Owner
Reconciliation task	One per Study × form with at least one qualifying candidate, with append-only input sets	A separate verification session type	RS §3.1
Accepted result version	An immutable accepted result for one Study × form with its authority (SingleAnnotator, HumanReconciled, Adjudicated, MergeResolved) and full provenance; it publishes a new gold snapshot	A screening outcome. It is never rewritten	RS §3.2
Presentation mapping	The private random table of aliases and positions for one reconciliation session	A persistent pseudonym	RS §3.5
Hint exposure and hint adoption	The records that a reviewer was shown an accepted answer as a hint and that they copied it	Independent evidence. Permission to see hints is not exposure	RS §3.6
Screening outcome	The current collective result per Study × profile, with its resolution state, how it was resolved and its history	An accepted annotation result	RS §3.8
Adjudication task, adjudication version and adjudicator assignment	Adjudication work per Study × profile × trigger; the immutable adjudicated decision; the versioned assignment to a member or group	A permission. Assignment never grants authority	RS §3.9
Screening discussion	One discussion episode between the candidates whose submitted decisions conflict	A step	RS §3.10

3.5 Stages, steps and pools

Entity	What it is	What it is not	Owner
Stage and stage settings version	A named workflow stage; immutable settings versions hold its filter version, steps and stage-level settings	An owner of evidence, targets or sessions	SP §3.2
Stage study filter version	The immutable rule, made of AND/OR clauses on screening outcomes and accepted answers, that decides which Studies are in the stage pool	An admission rule for a reviewer. A filter failure is not a screening exclusion	SP §3.3
Step	A unit of work inside a stage: a review step (screening, annotation or both), a system adjudication step or a training step	An owner of evidence or a target. Display order is never a dependency	SP §3.4
Stage pool (derived)	The current Studies whose evidence satisfies the stage's filter right now	A count of reviewed Studies, or a grant of access	SP §3.5.1
Reviewer study pool (derived)	The part of the stage pool allocated or assigned to one reviewer and currently available to them	A reservation or a permission	SP §3.6
Filter inputs and tracking marker	Small projections on the Study: its accepted answers for filtered questions, and its last recorded pool membership per stage	Read for admission or counts (the marker never is)	SP §3.5.2, §3.5.4

3.6 History

Entity	What it is	What it is not	Owner
History event (C20 envelope)	An immutable, structured record with project, Study, stage and step, actor, effective and recorded time, cause, source versions, before and after state, reason codes and clause evaluation	An event-sourced store, or a source of current truth	SP §3.12
Pool membership events	StagePoolBaselineMember, StagePoolEntered (with full entry justification) and StagePoolDeparted (with reason codes)	Invented history. Baseline events never claim an earlier entry time or cause	SP §3.5.3
Work first released	The first time a Study's work in a stage was released to anyone (renamed from StudyEnteredPool)	Pool entry, a review start or a completion	SP §3.7
Review start eligibility	The record, inside ReviewStarted, of why a reviewer was allowed to start and through which route	An offer log. Opening a Study without editing records nothing	SP §3.8
Admission basis	The basis recorded on each completion: in the pool, or continuation after an exclusion or a pool departure	A setting	SP §3.8

3.7 Duplicate merge

Entity	What it is	What it is not	Owner
Study merge and manifest	One duplicate consolidation, from preview to commit, with the exact inputs, choices, target confirmations, actor and time	An alias between two current Studies	DM §3.3
Merge conflict task	A conflict that must be resolved before commit, assignable to the original reviewer	A reconciliation task	DM §3.4
Study unmerge	The reversal of one committed merge, with an explicit choice for every item created after the merge	An erasure of the merge. "Both" is never a choice	DM §3.7

3.8 External and AI-model screening sources

Entity	What it is	What it is not	Owner
AI screening model configuration	The project's versioned description of an AI screening model: labels and their mapping, thresholds the project supplies, training-set context and any missing metadata	A user, member, login or permission holder	RI §3.11
Screening source policy	Part of a profile version: which external source may contribute decisions, and whether as a contributing vote or the sole screener	A reviewer or a target	RI §3.12
External screening run and decision	One delivery of outputs from one source; one source's versioned decision per Study × profile	A SyRF reviewer's candidate session	RI §3.13

3.9 Training and inference

Entity	What it is	What it is not	Owner
Training step, reference version and policy version	A practice step inside a stage; immutable reference answers; immutable scoring, pass, feedback, retry, admission and promotion rules	Live evidence. Reference answers never become accepted results	TI §3.1 to §3.3
Training attempt and assessment	One reviewer's attempt, with its own training sessions, and each automatic or manual judgement of it	A candidate session. It never qualifies, holds a place or enters live statistics	TI §3.4, §3.5
Classification rule version and inference result	Project rule versions, and derived, recomputable conclusions about cohorts (beta)	A reported answer, a vote or a count	TI §3.8, §3.9

3.10 Conversion and recovery

Entity	What it is	What it is not	Owner
Conversion inventory, manifest and adoption findings	A read-only survey of one project; the approved mapping plan; concrete, project-specific findings with remedies	A migration (the inventory) or a redesign plan (the manifest)	BC §3.3
Legacy-gap states	Named states on the field that lacks information: NotRecordedInLegacy, CurrentSnapshotOnly, UnknownLegacyAuthor, UnknownLegacyTime, UnknownAuthoredUnderDefinition, ValueOrDefaultUnknown, LegacyCompletionUnvalidated	Answer values. They never mean Unknown, Not reported or Not applicable	BC §3.2
Quarantine, wave, parity report, recovery boundary, recovery manifest	Records for blocked projects, scheduled batches, semantic comparisons, the first canonical write (firstCanonicalWriteAt) and forward recovery	Deletions. A failed attempt is kept as non-authoritative history	BC §3.3

3.11 Access, communications and reporting

Entity	What it is	What it is not	Owner
Contribution exclusion	An admin's recorded decision to take one member's contributions out of current use for a form, profile, stage or project	A deletion or a withdrawal	ACD §3.2
Project deletion state and records	Reversible deletion and restoration, each with actor, time and reason	Permanent erasure (T-POL-01, not approved)	ACD §3.3
Catalogue item and version	The one CAMARADES catalogue and its immutable versions; project copies carry provenance	A live link that updates copies	ACD §3.4
Notification content policy	A versioned project setting for what emails and digests may contain	A blinding setting. It can only narrow what disclosure allows	ACD §3.5
Active-work impact preview	The computed preview shown before an admin action that affects reviewers; the command stores its digest	A permission	ACD §3.10; UX §3.9
Frozen PRISMA report	A PRISMA flow report computed at a watermark and frozen, with its manifest	A live view or a place to correct old figures	RI §3.2
External step ledger	Counts for steps done outside SyRF, including explicitly supplied previous-review counts	A source of counts SyRF derives itself	RI §3.4
Methods records	Versioned search documentation, the protocol record with its amendment log, and full-text retrieval actions	A protocol authoring tool. A PDF never confirms retrieval by itself	RI §3.6 to §3.8
Agreement results	Rebuildable agreement figures, with human and machine source classes kept apart	A source of truth or a progress statistic	RI §3.16

3.12 How the main entities relate

graph LR
  REF["Reference (citation)"] -->|linked from| SV["StudyVersion"]
  DOC["Source document (report)"] -->|linked from| SV
  ST["Study"] -->|current version| SV
  FRM["Form"] -->|publishes| FV["Form version: questions, standard target, reconciliation policy"]
  ST -->|may have| OVR["Study target override"]
  FV -->|standard target| ET["Effective target (derived)"]
  OVR -->|override value| ET
  SES["Review session: one per reviewer, Study and form"] -->|belongs to| ST
  SES -->|autosave| DRF["Draft and change log"]
  DRF -->|Save or Complete| VER["Session version: checkpoint or completed"]
  VER -->|pins| FV
  VER -->|qualifying candidates| RT["Reconciliation task"]
  ET -->|readiness| RT
  RT -->|produces| ARV["Accepted result version"]
  PRF["Screening profile"] -->|publishes| PV["Profile version: Unsure, ties, source policy"]
  DEC["Screening decision"] -->|under| PV
  DEC -->|combined into| OUT["Screening outcome"]
  ADJ["Adjudication task"] -->|resolves| OUT
  AIC["AI screening model configuration"] -->|pinned by| PV
  RUN["External screening run"] -->|accepted decisions feed| OUT
  OUT -->|read by clauses| FLT["Stage study filter version"]
  ARV -->|read by clauses| FLT
  FLT -->|defines| POOL["Stage pool (derived)"]
  POOL -->|allocation and availability| RPL["Reviewer study pool (derived)"]
  STP["Steps in the stage"] -->|offer work from| RPL
  POOL -.->|entries and departures| HE["History events (C20)"]
  STP -.->|review starts| HE
  MRG["Study merge"] -->|creates consolidated| ST
  UMG["Study unmerge"] -->|restores originals| ST
  MRG -.->|recorded in| HE
  TRA["Training attempt"] -.->|kept apart from| VER
  TRA -->|a pass may admit to| GRP["Project group"]

In words.

• A Study points at its current StudyVersion, which links its references and source documents. A merge creates a new consolidated Study and tombstones the originals; an unmerge tombstones the consolidated Study and restores the originals (DM).
• A form version carries the standard target. A Study target override can replace it for one Study. Together they give the effective target, which readiness reads (RD).
• Each reviewer has one review session per Study and form. Autosave writes the draft. Save progress and Complete turn the draft into an immutable session version, which pins the form version it was written under (RD).
• Qualifying completed versions are the candidates of the reconciliation task, which produces accepted result versions with a named authority (RS).
• Screening decisions under a profile version combine into a screening outcome, possibly through an adjudication task. Accepted decisions from an AI screening model or another external source feed the same outcome under the profile's source policy (RS, RI).
• Stage study filters read screening outcomes and accepted answers to decide the stage pool. Allocation and availability narrow it to each reviewer study pool, from which steps offer work (SP).
• Pool entries and departures, first releases, review starts and merges are kept as history events under one envelope (C20). Current pools never read them (SP).
• Training attempts reuse the session engine but stay apart from live evidence. A pass can admit the reviewer to a project group whose existing permissions apply (TI).

4. What loads and writes when, at a glance

The table covers the most important user actions across all nine specifications. "Study write" means the per-Study compare-and-set that also updates the Study's summary and current evidence view. Where an action runs in phases, the column says so. Every row is a summary; the cited section is the authority.

Action	Reads	Writes in one transaction	Derived afterwards	Spec
A reviewer opens a Study and form from any stage, tab or device	Admission, the session head, the draft, the pinned and current form versions, hints	A connection record, and a place if capacity tracking is on and none is held. No session is created	Status line; alerts since the reviewer's base version	RD §4.1; SP §4.5; UX W1
Autosave	The draft head	One draft change holding only the changed answers, and the draft head. The first autosave creates the session. Never the Study	"Draft auto-saved". A first start writes ReviewStarted outside the Study transaction	RD §4.2; SP §4.6
Save progress	Session head, draft, form head, admission, dependent work if a Complete is being replaced	Answer revisions, an immutable Save version, the session head, the consumed draft, a Study write	"Version checkpoint saved"; readiness re-derived at query time	RD §4.3
Complete	As Save, plus whole-form validation independent of what is on screen	As Save with kind Complete. At an effective target of one with automatic acceptance, also the Single annotator result and gold snapshot (or a durable effect if too large)	One qualifying contribution; readiness; filter re-evaluation; stage completion	RD §4.4; RS §4.1
Save as incomplete after Complete	Dependent tasks, accepted results and steps, shaped by blinding	As Save. Nothing on the dependent records	One notice per affected author; the task shows "inputs changed"	RD §4.5
Publish a form version with question changes	The draft diff, declarations and treatments, sessions by category, active work, the preview digest	Phase 1 in one short transaction: question versions, form version, form head, policy generation, operation record, notice intent, history event. Then one transaction per Study: generated session versions, mapped revisions, Study write	Impact manifest; in-form alerts; drafts rebase at their next autosave	RD §4.8
Publish a target-only form version	Sufficiency, readiness, accepted results, overrides, reservations	Phase 1 as above, without question versions. Then per Study: result versions under the confirmed treatment, override versions, Study write. No session version	Effective targets and readiness; stage completion; filter re-evaluation	RD §4.9; RS §4.6
Apply a Study target override	Form version, current override, current evidence, active places	One override version, the Study write, a history event and any reservations released by Apply anyway	Readiness and capacity; stage completion; notices	RD §4.10
Request additional reviews for many Studies	The selected Studies and each assignee's existing contributions	The request record, then one transaction per Study: an override version, a scoped assignment, the Study write	One notice per assignee; readiness changes reported to the reconciler	RD §4.11
Publish a screening-profile version	Mismatches with existing decisions, outcomes and adjudications; whether eligibility changed	Phase 1 for the profile, with the protocol amendment entry where eligibility changed. Then per Study: generated profile-session versions, the recomputed outcome, the Study write	Required new screening stays pending; pool re-evaluation	RD §4.12; RI W5
Submit a screening decision	The Study, its filters and steps, the profile version, other candidates' decisions (server only)	Decision revision, profile session version with its admission basis, recomputed outcome, Study write, pool events for dependent filters, ReviewStarted on a first start, the dependent claim at an own Include, WorkFirstReleased where due	Claims released after a departure; notices; readiness	SP §4.2; RS §4.9
A reconciler completes	The draft, the base snapshot and input-set etags, completeness, exposure	Reconciliation version, reconciled revisions, gold snapshot, accepted result (HumanReconciled), task state, claim release, Study write	History event; filter re-evaluation; statistics	RS §4.4
A reconciler bulk-accepts agreeing Studies	The form setting, agreeing Studies, warnings, each Study's etag	An operation record, then per Study the same writes as a reconciler Complete, marked bulk-confirmed	As above, per Study	RS §4.5
A reviewer clicks to fill from a hint	Hint baseline, step override, current gold snapshot, compatibility, applicability	A draft patch with an adoption marker; the next Save or Complete records exposure and adoption	Adopted answers are left out of independent agreement	RS §4.7
An adjudicator resolves	Eligibility, assignment, the exact input vector, the rationale rule	Adjudication version, the outcome's final facet, task resolved, claim release, Study write	Pool re-evaluation; history events	RS §4.11
An admin publishes a stage filter change	Old and new predicates, started work on departing Studies, the preview digest	Fence, drain and recheck; then the settings version with its embedded filter, the pointer and the sweep operation record	A per-Study sweep writes pool events and the marker; readiness; notices	SP §4.1
A reviewer asks for Next, opens a Study or browses	The pool predicate, membership facts, steps, batches, capacity, permissions	A claim only, when tracking is on. No history event	Nothing	SP §4.5
A reviewer completes after the Study left the pool	Continuation settings, permissions, capacity	A session version with basis "continuation after departure", or a refusal that keeps the draft	The explanation timeline shows the basis	SP §4.7
An admin changes capacity, timeout, limit or continuation settings	Affected reviewers, places and temporary reservations	The new settings and, with Apply anyway, release of the named temporary reservations only	Notices to affected reviewers	SP §4.8; ACD §7
An admin opens the eligibility explanation	Events, adapters over existing records, configuration versions, current admission	Nothing	A plain-sentence timeline with coverage gaps stated	SP §4.10; UX W7
An admin commits a duplicate merge	Each input's version and evidence watermark, the active-work digest	Staging first (invisible). Then one activation: the consolidated Study, input tombstones, frozen manifest, events and durable intents	Notices, pool events, stage completion, statistics rebuild	DM §4.5
An admin commits an unmerge	The consolidated Study's version and watermark, every item's choice	Staged copies. Then one activation: tombstone the consolidated Study, restore the inputs, link the copies, write current evidence and events	Notices, pools, statistics	DM §4.10
An admin edits a bibliographic field	The current StudyVersion and its references	A new StudyVersion recording the field's origin, the Study projection and a history event	Nothing else; references never change	DM §4.11
An admin accepts an external or AI-model run	Per Study: current state through merge lineage, profile version, the source's current decision	One transaction per Study: decision version, Study write, outcome with its composition, an adjudication task where needed, history events	Pool events with cause "accepted external screening decision"; notices; statistics	RI W10
An admin freezes a PRISMA report	Every input at a watermark	One frozen snapshot with its manifest and digests	Nothing changes in place	RI W1
An admin withdraws a search	The search, its references, affected Studies, other current searches, active work	The withdrawal event, the search state and its ledger entries	Departures with reason "search withdrawn"; the report's explanation line	RI W3
A trainee submits an attempt	Training sessions and the rubric	Attempt state and the automatic assessment	Feedback; an assessor task if manual items remain; admission adds the group membership with its causation	TI §4.4, §4.6
A designer enables or disables the inference beta	The Design capability and the explanation version	The setting change	On disable, current results are withdrawn; no answer changes	TI §4.10
An admin excludes a member's contributions	Contributions in scope, dependent results, tasks in progress	Exclusion record, operation record, notice intent, history event	A sweep updates summaries; readiness and outcomes recompute; dependent results are flagged	ACD §4.3
An admin deletes or restores a project	The project, active work, running operations	A fence and state change with an operation record; per-Study markers and releases in short transactions; a final commit with the deletion or restoration record	Hidden from lists and notices stop (delete); pools and capacity recomputed (restore)	ACD §4.5, §4.6
SyRF sends an email or digest	The inbox row, resolver, disclosure policy, content policy, the recipient's current access and mute	One delivery-ledger row	Nothing	ACD §4.9
An operator runs a conversion cutover	The shadow copy, the legacy delta under locks, busy markers	Per-batch locks, then one commit write: ownership markers, registry, aliases, baseline pool events	Statistics rebuilt; notices to admins and active reviewers	BC §4.5
The first canonical write after conversion	The project's ownership registry entry	firstCanonicalWriteAt, set inside that command's own transaction	Recovery changes from routing rollback to forward recovery	BC §4.8
A user opens My work or the badge refreshes	Indexed read-time queries filtered by permission	Nothing	A failed query shows "Couldn't load", never a false 0	UX W6

5. ID conventions

5.1 Specification IDs

Pattern	Meaning	Example
<PREFIX>-Rnn	A rule in a specification's §5	SP-R33; a lettered insert such as RS-R04a keeps later numbers stable
<PREFIX>-AEnn	A row of acceptance evidence in §11	DM-AE01
SP-AMB-nn; A1 to A4; B1 to B8	Ambiguities stated once with options and a recommendation. SP numbers its own; BC, RI and UX use A; ACD uses B; RD, DM and TI number them in §12	SP-AMB-01; "BC ambiguity A1"
W1 onwards	A walkthrough in RI and UX §4	"RI W10"
E1 onwards	A user flow in BC and ACD §9	"ACD E10"

The access specification uses the prefix ACD (ACD-Rnn, ACD-AEnn, "ACD §n") so that its IDs cannot be confused with acceptance criteria in acceptance-criteria.md, which carry a release or group, for example AC-R2a-01, AC-R0-09, AC-ALL-07 or AC-T-08. Its tracker rows keep the workstream code (T-AC-00 …). In the round-1 and round-2 reviews, "AC §n" and "review AC-nn" refer to the acceptance criteria and the acceptance-criteria reviewer. One collision needs care: UX-Rnn and UX-AEnn are the UX specification's IDs; UX-01 to UX-22 are round-2 review findings cited in the UX strategy.

Labels inside the specifications: OWNER (an owner decision or a consolidation section), PROPOSAL (the specification's recommendation for the brief), OPEN (an owner decision not yet taken) and BRIEF (an alignment, engineering or validation entry that the brief settles).

5.2 Decision IDs

Q-nn (Batches B and C), D1-nn to D4-nn (Batch D sub-batches) and G0-Dn (G0 dossier items) are package decision IDs. The owner session grouped many of them into packages R1 to R4 (reconciliation and migration), S1 to S5 (screening and training), E1 to E4 (evidence and reporting), U1 to U3 (UX) and O1 to O4 (operations and access). Decision status vocabulary: Decided, Decided-amended, Replaced, Removed, Deferred (beyond MVP), Brief item, Specialist input, Engineering contract (no owner question) and Open owner decision.

5.3 Tracker IDs

ID	Row
T-RD-00, T-DM-00, T-SP-00, T-RS-00, T-BC-00, T-TI-00, T-RI-00, T-UX-00, T-AC-00	One brief row per specification
T-DH-00	The design-prototype handoff
T-SI-01 to T-SI-05	Specialist inputs: Q-17 event counts; Q-16 and D4-12 agreement methods; D4-06 template curation; D4-21 ASySD parity method and thresholds; PRISMA box mapping for pool history versus review through the stage
T-POL-01 to T-POL-03	Policies not approved: permanent physical erasure; an identity-erasure process; automatic acceptance of multiple agreeing candidates
T-G0, T-HOLD	G0 approval; the implementation-hold lift
T-OI-01	The owner-input row for D2-09, the last open owner decision; decided on 5 October 2026
T-<WS>-NN	Implementation rows added by the implementation tracker under each brief row

Work status vocabulary: Planning approved, Brief drafted, Brief approved, Implementation authorised, In progress, Merged dark, Gate passed, Production enabled. Today no row is past Brief drafted.

5.4 Owner-session amendments (OS-A)

The specifications cite these amendments by short name. They sit outside the 74-entry register and the repository count of 89.

ID	Short name	Main specification
OS-A01	Collaborative question-management drafts	RD §3.7, §4.7; UX §3.8
OS-A02	Reconciliation blinding and unpredictable candidate ordering	RS §5.6
OS-A03	No cross-Study identity continuity in blinded reconciliation	RS §5.6 (RS-R25)
OS-A04	Reconciled-answer hints, explicit click-to-fill, step hide-only override	RS §5.7
OS-A05	Finishing started work after a filter-driven pool departure	SP §3.9
OS-A06	Results produced through a stage may change its own pool	SP §4.2
OS-A07	Targeted pool-membership history	SP §3.5, §4.1 to §4.4
OS-A08	Admin explanation of review activity and inactivity	SP §3.14; UX §3.7
OS-A09	Historical pool coverage, with actual review through the stage as reporting priority	SP §3.13; RI §3.3
OS-A10	Explicit entry justification for every pool entry	SP §3.5.3
OS-A11	Structured, queryable history events and required queries	SP §3.12, §3.13
OS-A12	The standard reviewer target versions the form	RD §3.5, §4.9
OS-A13	Screening tie adjudication and member or group adjudicator assignment	RS §5.11
OS-A14	Explicit legacy activity mapping and adoption guidance	BC §3.3, §10.3
OS-A15	Universal faithful baseline conversion, then optional in-engine redesign	BC §1, §3.1
OS-A16	Bounded Unsure handling and adjudication fallback	RS §5.10
OS-A17	Exclusion-reason template is guidance, not a question-count limit	RS §5.13
OS-A18	Training with reference answers, scoring, assessment, retries and group admission	TI §3.1 to §3.6
OS-A19	Inference behaviour and the project-designer opt-in beta	TI §3.7 to §3.9
OS-A20	External and AI-model-generated screening decisions	RI §3.11 to §3.14
OS-A21	"Draft auto-saved" versus "Version checkpoint saved" (illustrative wording)	UX §3.2; RD §4.2
OS-A22	PWA exploration beyond MVP; no offline writes	UX §3.11
OS-A23	Compatible improvements on legacy screens without workflow change	UX §3.4
OS-A24	Admin-controlled contribution exclusion	ACD §3.2
OS-A25	Reversible project deletion and restoration	ACD §3.3
OS-A26	Informative, permission-aware emails	ACD §3.5
OS-A27	Optional, dynamic, blinded reviewer-study-pool browsing	SP §3.6
OS-A28	One candidate plus human reconciliation instead of a verification engine	RS §5.1
OS-A29	Consolidated, atomic, reversible duplicate merge	DM
OS-A30	The design-prototype handoff deliverable	design-prototype-handoff.md

5.5 New contracts

The contracts updater adds three contracts to contracts.md; the specifications reference them.

Contract	Content source	Freeze
C20 Structured history events	SP §3.12 and §3.13 (envelope, families, reason and cause sets, idempotency keys, ordering, effective and recorded time, watermark rule, adapters, access, required queries)	Envelope at F1a; stage-pool and eligibility event types at F3
C21 Duplicate consolidation and reversal	DM §3 to §5 (merge, conflict tasks, activation, unmerge, current evidence view)	F-P
C22 External and AI-model screening sources	RI §3.11 to §3.14 (model configuration, source policy, runs, decisions, acceptance, identity resolution, outcome composition, agreement classes)	With the external screening lane

6. How the specifications relate to briefs, acceptance criteria and the tracker

• Briefs. Each specification is the input to one workstream brief, tracked by its T-XX-00 row. Chris approves a brief; implementation authorisation then follows per gate (D1-04). Both are on hold. Brief-level defaults and the ambiguities each specification resolves with a recommendation are approved with each brief, not individually. Items marked owner-visible in a §12 are listed for Chris in the product-owner guide.
• The 25 alignment, brief and validation entries. Each §12 names the entries that specification owns and the treatment the brief must give them (§2 of this page shows the split).
• Acceptance criteria. §11 rows are PROPOSALs until confirmed at their freeze gate, except where they restate an owner decision as a testable assertion. The "Amends" column names the existing acceptance criteria a row rewrites, extends or replaces; rows marked "New" join the traceability tables. The acceptance criteria stay the release gates.
• Package updates. §13 is the change list for the existing package documents, and §14 lists wording that must not be reintroduced. The owner-session integration records the coverage matrix: owner decision, specification section, contract or entity, acceptance evidence, release or gate, and tracker row.
• Rollout. §10 says where each capability is expected to land. The rollout plan fixes the final placement, including new lanes, and gives reasons for any change.
• Tracker. The implementation tracker carries the brief rows, specialist rows, policy rows, gates and implementation rows, each with scope, owner, dependencies, brief approval, implementation authorisation, PR and status, evidence and blockers. Approved product design is never recorded as work started, a gate passed or production enabled.
• Design handoff. design-prototype-handoff.md translates these specifications into the interaction detail a prototype iteration needs. Producing it messages no design session and builds no new prototype.