Specification: review domain and versioning

Planning specification (prefix RD; tracker row T-RD-00). 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 on this page says that work has started, that a gate has passed or that anything is enabled in production. Storage shapes and names are PROPOSALs until the F1a storage and naming ADRs fix them. Thresholds quoted from earlier documents are proposed and not approved.

Sources. "Consolidation" is the owner-session consolidation, which wins over older text. "Register" is the 74-entry session register, including its appended owner amendments. "Condensed" is the condensed packages. The owner ledger is review-form-owner-decisions-2026-10-02.md. Package context: domain model, versioning model, consistency model, contracts C1 to C5 and C9. Neighbouring specifications: duplicate merge (DM), stage pools, steps and history (SP), reconciliation and screening (RS), baseline conversion (BC), UX, devices and work discovery (UX) and access, communications and deletion (AC). Owner-session amendments outside the register count are cited by short name; their OS-A IDs are in the owner-session integration.

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

1. Summary in plain English

The Study stays the thing a project reviews. A form session, a screening decision, a reviewer target override and an accepted result always belong to one Study. Each imported reference (a citation) and each source document (a report, for example a PDF) stays its own record. SyRF never fuses two imported references into one invented original. A conference abstract and the journal article that followed it may stay as two Studies.

One reviewer, one session, one place. A reviewer has one session per Study and form. Every stage, browser tab and device that reaches that form opens the same session. It holds one place in the capacity count. The form decides how long an inactive session keeps its place and how many studies a reviewer may have in progress. When the place expires, the draft stays.

Three ways of writing. Autosave keeps a recoverable draft by sending only the changes; it never submits anything. Save creates an immutable version checkpoint, which may be incomplete. Complete checks the whole form and creates a completed checkpoint. Only explicit versions count towards targets. Saving a completed session as incomplete stops it counting, and SyRF warns the reviewer first about any reconciliation or other work that depends on it.

Definitions change through published versions. Questions, forms and screening profiles each have immutable versions. The form's standard reviewer target is part of the form version, so changing it is a publication with an impact preview, even when no question changes. A single Study can have its own target through an override with its own version history. A request for additional reviews, for one Study or many, raises those Studies' targets openly and counts each reviewer once.

Publishing is previewed, chosen and rechecked. The admin sees which existing and active work is affected and how, chooses the treatment, and SyRF rechecks at commit. Publication may now create session versions that record the chosen treatment, each attributed to the publication and the publishing admin (D2-01 reversed). Reviewers' drafts are kept. The publisher declares whether a changed question is compatible with its previous version and whether old answers may be mapped to new options. That declaration never changes afterwards; a mistake is corrected by a guided rollback and a new publication.

Several people can draft at once. Designers see who else is viewing or editing, changes appear in every open view, and a conflicting edit is kept for recovery. Only one publication per form runs at a time.

No owner decision is open. Of the 89 owner decisions open before the session, D2-09 was the only one the session left open. It concerns how accepted answers to a question shared by two forms are revised. Chris answered it on 5 October 2026, agreeing with the recommendation and adding two points: the second form's reconciler may revise them in their own final submission, producing a new snapshot with provenance; they are prompted for a reason, which is never required; and they may also raise a query on the accepted answer (§4.14).

2. Decisions covered

ID	Decision in one line	Status	Section
Consolidation §1 (Study unit)	The Study is the reviewable item; forms, sessions and targets attach to Study × form across stages	Decided	§3.1, §3.3
Consolidation §1 (references and reports)	References and source documents stay distinct records; storage is chosen deliberately; grouping distinct reports is deferred	Decided	§3.2, §3.3
Consolidation §1 (shared session)	One session and place per reviewer per Study × form across stages, tabs and devices; route provenance stays on versions	Decided	§3.9, §3.11, §4.1
Consolidation §1 (autosave, Save, Complete)	Autosave is a diff-based recoverable draft; Save is a checkpoint that may be incomplete; Complete is a validated checkpoint	Decided	§3.10, §4.2 to §4.4
Q-27	Readiness from current evidence; warn the actor before commit; inform affected authors; never rewrite dependent work automatically	Decided	§4.5, §7
Q-20	Admin impact preview; alerts to affected reviewers; in-form warnings for a reviewer's own edits; deduplicated notices	Decided	§4.8, §5, §7
Q-34	The publisher explicitly declares compatibility and whether mapping applies; mapping writes attributable revisions	Decided-amended	§3.4, §4.8
Q-26	Immutable profile versions; mismatches with existing decisions and outcomes detected and treated before publication	Decided	§3.6, §4.12
D2-11	Many drafts; one publication operation per form; the next publication rechecks against the resulting state	Decided	§3.7, §4.7
Collaborative question drafts (owner-session amendment)	Presence, live updates, preserved local edits, base checks, recoverable conflicts, attributed changes	Decided	§3.7, §4.7
Target-versions-form (owner-session amendment)	The standard reviewer target is part of the immutable form version	Decided	§3.5, §4.9
Overrides and additional-review requests (consolidation §1; D3-13 clause)	Study × form overrides keep their own history; requests raise the effective target explicitly and count reviewers once	Decided (the D3-13 entry itself stays a brief item owned by SP)	§3.12, §4.10, §4.11
D2-01	Publication may create attributable generated session versions (reverses the round-2 proposal)	Decided-amended	§3.15, §4.8
D2-02	Compatibility belongs to immutable question versions; the publisher declares it; corrections use guided rollback and republication	Decided-amended	§3.4, §4.13
D2-03	A data-type or multiplicity change is an incompatible version of the same question	Engineering contract (no owner question)	RD-R30
D2-04	A stage binds the form identity; the live route presents the session's resolved version	Engineering contract (no owner question)	RD-R31
D2-05	The standard target versions the form; every other setting is classified in the brief	Decided-amended (in part)	§3.5
D2-06	System questions stored as versioned data and adopted only through a form publication	Engineering contract (no owner question)	RD-R32
D2-07	Form-owned inactivity timeout and per-reviewer in-progress limit; one place across tabs and routes; expiry keeps the draft	Decided	§3.11, §4.6
D2-08	One shared session and place across tabs and devices; connections tracked separately; base-version checks	Decided	§3.10, §3.11
D2-09	Shared-question accepted answers across two forms: the second form's reconciler may revise them as a new snapshot with provenance; an optional reason is prompted for; a query may also be raised	Decided-amended (Chris, 5 October 2026, status page)	§4.14, §12
D2-10	Tested publication active-work protection; measured pause and operation limits	Brief item	§7, §12
D2-16	No size-based exclusion; the largest project is an acceptance case	Replaced	RD-R33, §11
Q-29 (target-change part)	A new target may lead to a new accepted-result version; history kept (owned by RS)	Decided-amended (owned by RS)	§4.9
D3-03 (status meaning)	Draft auto-saved, version checkpoint saved and completed stay distinct (wording owned by UX)	Decided-amended (owned by UX)	§4.2, §9.1

3. Concepts, entities and storage

Each entity below says what it is, how it is identified, which versions and pointers it has, what may change, where it is proposed to live, and what it is not. Storage follows two package rules: immutable records live where an append-only repository can enforce insert-only writes (versioning model §12.2), and a new collection is proposed only when that rule or a measured need requires it, never merely because a record is a distinct domain concept (consolidation §1).

3.1 Study

• What it is. The item a project screens and annotates. Forms, sessions, targets, decisions and accepted results attach to a Study.
• Identity. The existing Study GUID (CSUUID). It is never re-keyed.
• Versions and pointers. A mutable parent with state (Current or Tombstoned) and currentVersionId, which points to the current StudyVersion (§3.2). A tombstone records its reason and operation (DM §3.1).
• Mutability. The parent changes by compare-and-set on its Audit.Version, as every planned canonical command does under CR-1. Content versions never change.
• Proposed storage (PROPOSAL). The existing pmStudy document gains state, currentVersionId, tombstone and the currentEvidence projection (DM §3.6). Its existing top-level bibliographic fields stay as the projection of the current StudyVersion, so legacy readers keep working. A missing state reads as Current.
• What it is not. It is not a citation, a report or an investigation. It does not belong to a stage. A stage's pool is computed from Studies (SP).

3.2 StudyVersion

• What it is. An immutable snapshot of a Study's content: the displayed bibliographic fields with per-field provenance, the links to its references, and the links to its source documents.
• Identity. (studyId, seq) with a GUID.
• Versions and pointers. Study.currentVersionId points to one. Earlier versions stay readable.
• Mutability. None. A bibliographic edit, a merge and an unmerge each append a version (DM §4).
• Proposed storage (PROPOSAL). An append-only pmStudyVersion collection, chosen for enforcement. Older binaries replace the Study document whole, so immutable content inside it cannot be proven unchanged. A P1 import writes version 1 from its single reference. A Study created before P1 gets version 1 on first need (a bibliographic edit, a merge or baseline conversion), labelled CurrentSnapshotOnly because its earlier history was not recorded (BC).
• What it is not. It is not a citation and not a FEAT-011 Publication. Cross-project Publication enrichment never changes a Study's displayed fields silently (DM-R17).

The rules for field provenance and overrides are in DM §3.2.

3.3 Reference (citation) and source document (report)

• Reference. A citation is the bibliographic reference and import record: the raw imported fields, the search and import job, the importer, the import time and the original identifiers. It is immutable. Its identity is citationId. Its home Study is the Study created for it at import, and it never moves.
• Proposed storage for references (PROPOSAL). Keep citations as immutable entries in the home Study's citations[] array, the FEAT-011 shape. Because citations never move, a Study usually holds exactly one. A consolidated Study links its inputs' citations by ID through StudyVersion.referenceLinks[] ({citationId, homeStudyId, linkedBy, linkedAt, reason}), so no chain of merges is ever walked to find a reference. This deliberately adds no collection. F-P revisits it only if measured document sizes require it.
• Source document. A file that reports the work: a full text, a supplement or an abstract. The existing PDF and file records stay as they are. StudyVersion.sourceDocumentLinks[] ({documentRef, kind, linkedBy, linkedAt, sourceStudyId}) can hold several documents, which is the prepared multi-source link (D4-08, carry-forward). Which distinct report a reference or file belongs to is RI's sourceDocumentKey with its basis (RI §3.1): it sits on referenceLinks[] entries, and a sourceDocumentLinks[] entry may carry the same key (PROPOSAL, added in the 5 October harmonisation). The workflow for grouping distinct reports into one investigation is deferred (RI owns Q-23 and D4-08).
• What they are not. Two imported citations are never collapsed into one fabricated original. A report is not a Study. Linking a source document never merges review evidence. A conference abstract and a journal article may remain separate Studies under the protocol (consolidation §1).

3.4 Question definition and question version

• What it is. A question's stable identity (versioning model §3.1) and its immutable content versions.
• Identity. QuestionRef plus structural identity; a version is (QuestionRef, seq).
• Versions and pointers. Form and profile versions pin exact question versions.
• Compatibility declaration (D2-02 amended, Q-34; OWNER). Each version carries compatibility {suggestedBySyrf, declared, declaredBy, declaredAt, rationale} and, where the publisher allows it, optionMapping {oldOptionId → newOptionId, declaredBy, declaredAt}. SyRF suggests a default from the change (versioning model §3.5 table). The authorised publisher confirms or changes it explicitly. A version is normally committed as part of publishing the first form or profile version that pins it, so the declaration is made by the publisher at that moment.
• Mutability. None after commit, including the declaration and the mapping. This replaces the versioning model's rule that a declaration may change until a revision pins the version. A wrong declaration is corrected by a guided rollback and republication (§4.13).
• Proposed storage. pmQuestionDefinition and pmQuestionDefinitionVersion, as in the versioning model §12.1.
• What it is not. A pending edit is not a version. Pending edits live in a design draft (§3.7).

3.5 Form and form version

• What it is. An annotation form is a project-level evidence and requirement owner (SF1). A form version is its immutable published requirement.
• Identity. (projectId, formId); a version is (formId, seq).
• Versions and pointers. The form head holds currentPublishedSeq, publicationSeq, policyGeneration and the active publication marker. Sessions, accepted results, tasks and stage bindings pin form versions.
• Content of a form version. The ordered question-version pins with ancestors, requiredness, minimum instance counts, the validated applicability graph and the renderability result (versioning model §4.1), plus FormVersion.standardTarget (OWNER, target-versions-form) and ReconciliationPolicy (targetOneHandling ∈ AutoAccept, RequireHumanReconciliation, OWNER R1; baseline conversion alone may also set NoAcceptance, RS-R04a PROPOSAL; the other members are classified below).
• Proposed storage. pmAnnotationForm, pmAnnotationFormVersion, and the audited operational settings record on the form head with entries in pmDefinitionSettingsAudit.
• What it is not. A stage does not own a form's target, timeout, limits, blinding or hint availability (consolidation §4; SP and RS).

Setting classification (D2-05 amended in part). The owner fixed one row: the standard target is inside the version. Every other row is a PROPOSAL for the brief. A setting goes inside the version when it changes what counts as valid evidence, how evidence is produced or how an accepted result is formed, because the records it affects must pin it. A setting stays operational when it changes only who is offered work and when; operational changes are audited, read live and recorded on the events that use them.

Setting	Owner	Classification	Basis
Question pins with ancestors, requiredness, minimum instances, applicability graph, renderability result	Form	Inside the form version	FV1; versioning model §4.1
Standard reviewer target (FormVersion.standardTarget)	Form	Inside the form version	OWNER (target-versions-form)
Target-one handling (AutoAccept or RequireHumanReconciliation; conversion-only NoAcceptance, RS-R04a)	Form	Inside the form version	OWNER (R1: "publish the relevant versioned form policy"); NoAcceptance is PROPOSAL
Accepted-answer completeness override	Form	Inside the form version (PROPOSAL)	Q-04: it changes what an accepted result must contain
Reconciliation identity blinding	Form; the profile for screening reconciliation	Inside the version (PROPOSAL); profiles already version it (naming registry)	Q-28, Q-30
Reconciled-answer hint availability baseline	Form	Inside the form version (PROPOSAL)	Q-28: it changes exposure, which the session version records
Outdated-answer completion mode (warn or block)	Form	Inside the form version (PROPOSAL)	D4-17 (O3): "record the policy and evidence versions used"
Inactivity timeout; per-reviewer in-progress limit	Form	Audited operational setting (PROPOSAL)	D2-07; Q-28
Capacity cap (separate from the target)	Form	Audited operational setting, off by default (PROPOSAL)	D3-17 (SP)
Unstarted reconciliation-assignment expiry	Form (reconciliation tasks); the profile for adjudication tasks (RS §3.12); admin-configured	Audited operational setting, optional, off by default	Q-30
Bulk acceptance of agreeing candidates	Form	Audited operational setting, off by default	Q-11 (RS)
Comparison display settings; guidance text	Form	Audited operational setting	D2-05

3.6 Screening profile and profile version

• What it is. A screening profile owns eligibility questions, decision rules and its reconciliation and adjudication policies. A profile version is its immutable published content.
• Identity. (projectId, profileId); a version is (profileId, seq).
• Versions and pointers. Decisions, profile-owned answers, outcomes, adjudications and stage filter clauses pin profile versions.
• Mutability. None after publication (Q-26, OWNER). Changes publish a new version through the impact process in §4.12.
• Proposed storage. pmScreeningProfile, pmScreeningProfileVersion, pmProfileVersionIssue.
• What it is not. This page covers how profiles version and publish. RS covers what a profile version contains (Unsure, tie policy, discussion, rationale, blinding, sufficiency and source policies, ScreeningProfileVersion in the naming registry).

3.7 Design drafts, draft changes and presence

• What they are. A DesignDraft is a named, unpublished proposal for the next version of one form or one profile, including pending question edits. Several drafts may exist for one form (D2-11). A DesignDraftChange is one accepted edit to a draft. DesignPresence says who is viewing or editing which draft or question right now.
• Identity. A draft has a GUID and a scope (form F or profile P). Each change has (draftId, draftRevision).
• Versions and pointers. A draft records the published version it is based on and its current draftRevision. Each change records its actor, time, the item it changed (question, option, form composition element or policy field), the item revision it was based on, and the before and after values.
• Mutability. A draft's working state changes only by appending a change. A change is never edited. Discarding a draft is an audited status change.
• Proposed storage (PROPOSAL). pmDesignDraft (head) and an append-only pmDesignDraftChange. Presence is not stored: it lives in connection state on the existing hub, shown only to users who may view the design (collaborative question drafts amendment: "presence is not a substitute for an audit record").
• What it is not. A draft never changes a published requirement or a reviewer's form. Editing a draft never starts an impact flow (Q-20). Presence never grants or blocks an edit.

3.8 Publication operation

• What it is. The operation that publishes a form version (FormVersionIssue) or a profile version (ProfileVersionIssue), with its recorded policy and its impact.
• Identity. An operation GUID; at most one active per form or profile (D2-11).
• Versions and pointers. An append-only policy record per generation (FV4 adds generations), the preview digest, the generated-version plan, progress, and the impact manifest built after commit.
• Proposed storage. pmFormVersionIssue with chunks, and pmProfileVersionIssue, as in the domain model §4.5.
• What it is not. It is not the draft and not the version it publishes.

3.9 Review session and session version

• What it is. A reviewer's work on one Study for one form (FormSession) or one profile (ProfileSession), shared by every stage, tab and device (SF1, consolidation §1).
• Identity. Deterministic ID from (project, study, form or profile, reviewer). It is created by the first autosave; opening a study creates nothing.
• Versions and pointers. The session head points to its latest explicit version. Each version is (sessionId, seq) with its kind, declared form version, route (stage, step, settings version), the full pin map, the resolved question set, exposure state, actor, effective author, operation, command ID, clock stamp and digest.
• Mutability. Versions are immutable. The head moves by compare-and-set.
• Proposed storage. pmFormSession and pmFormSessionVersion (versioning model §12.1).
• What it is not. A session does not belong to a stage. A draft is not a version. A reconciliation session is a separate entity of the reconciliation task (RS).

Version kind	Created by	Becomes current	Counts towards targets
Save	Reviewer	Yes	Never as completed
Complete	Reviewer, after whole-form validation	Yes	Yes, once per reviewer per Study × form, while its standing qualifies
Fix	Reviewer, from an outdated flag (SF5)	Yes	No (incomplete)
Upgrade	Reviewer (re-pins to the current form version)	Yes	As its status and standing allow
Withdraw	Reviewer or admin (C5 ADR)	Yes	No
PublicationGenerated	A publication operation, attributed to the publisher (D2-01 amended)	Yes; it is computed against the latest head and never overwrites a newer reviewer version	As its status and standing allow; never a Complete that fails validation
MergeResolved, MergeCarriedForward, UnmergeCarriedForward	A merge or unmerge operation (DM §3.5)	Yes, on the Study the operation targets	As their status and standing allow

3.10 Session draft and draft change log

• What it is. The reviewer's unsaved work over the session's current explicit version (SL1).
• Identity. One draft per session.
• Versions and pointers. The draft head records the base explicit version, the base form version and an increasing draftVersion. Each accepted autosave appends a SessionDraftChange: {draftVersion, basedOnDraftVersion, per-answer base, patch, connectionId, tabId, actor, at}.
• Mutability. The head moves by compare-and-set; changes are append-only. Save and Complete consume the draft atomically and link its changes to the version they produced.
• Proposed storage (PROPOSAL). pmSessionDraft (head, with the materialised current draft as a cache) and an append-only pmSessionDraftChange. The change log is kept with the session's history so the draft history is fully reconstructable (consolidation §1). This replaces the earlier rule of no autosave trail beyond the current draft (PH-33). Retention and any compaction are a brief item (§12); compaction never removes an explicit version.
• What it is not. A draft never counts, never qualifies, is never shown to reconcilers and never appears in exports (AC-R2a-08). It never writes Study.

3.11 Connections and the shared place

• Connection. One record per tab or device (ReviewSessionConnection), with the session it serves, the route it came through and its last activity. Connections are tracked separately (D2-08, OWNER).
• Place. One capacity claim per reviewer per Study × form (claim contract v2), however many connections or stages use it. The form owns the inactivity timeout and the per-reviewer in-progress limit (D2-07, Q-28, OWNER).
• Release rule (OWNER). One idle or closed tab never releases the place while another connection remains active. The place is released only when every connection has been idle beyond the form's timeout or has closed. Release keeps the draft.
• What it is not. The place is not the target and not the capacity cap (SP owns D3-17 and D3-18). The in-progress limit counts sessions, never connections.

3.12 Study target override, effective target and additional-review request

• StudyTargetOverride (OWNER, consolidation §1). An immutable, versioned requirement decision for one Study and one form, applying across every route. Identity: deterministic from (project, study, form); versions (overrideId, seq). Each version records value, basis (SetByAdmin, AdditionalReviewRequest(requestId, raiseBy), MergeConfirmation(mergeId) or Removed), madeAgainst {formVersionSeq, standardTarget}, reason, actor, time and clock stamp. Proposed storage (PROPOSAL): an append-only pmStudyTargetOverride, with the current value projected into the Study's currentEvidence. There is no step-level override (OWNER).
• EffectiveTarget (derived). The current override's value if one exists and is not Removed, otherwise the current published form version's standardTarget. It is computed, never stored as a fact, and it is projected for fast reads. Accepted results and readiness snapshots record both the form version and the override version they used (target-versions-form amendment).
• AdditionalReviewRequest (OWNER, consolidation §1; D3-13 clause). A request record naming one form, one or many Studies, the number of additional reviews, optional assignees (members or groups), a reason and the requester. Each Study item writes an override version with basis AdditionalReviewRequest and, where assignees are named, a scoped assignment for that Study × form. Proposed storage: the existing pmAdditionalReviewRequest, reshaped as a batch with per-Study items. The Request an additional review capability (RA5) is still required. An assignment never grants a permission.
• What they are not. An override is not a capacity cap. A request is not an invisible bypass that leaves the target unchanged; that earlier behaviour is superseded (§14).

3.13 Accepted-result version (as targets affect it)

RS owns AcceptedResultVersion and its authority values (SingleAnnotator, HumanReconciled, Adjudicated, MergeResolved). This page fixes only what a target change does to it: applying a new form version or override may lead to a new result version under the agreed authority rules, it never rewrites an old result, never invents a missing review and never invalidates a recorded answer (target-versions-form amendment; Q-29). Automatic acceptance of several agreeing candidates is not approved (T-POL-03).

3.14 Derived values and where they live

Value	Derived from	Kept where	Currentness
Per-answer state and session standing	Latest explicit version, pin map, current form version, recorded policy generations, validity	Computed on read; projected for lists	Projection carries its definition-version vector; gates fail closed when stale
Qualifying contribution	Status completed and qualifying standing and eligibility	Computed on read; projected	As above
Effective target	Override or standard target	Projected in currentEvidence	Written in the same transaction as the override or publication item
Reconciliation readiness	Qualifying contributions against the effective target	Computed at query time, or read from a projection guaranteed current for its input versions (Q-27)	A stale projection never authorises work
Current evidence of a Study	Its sessions, decisions, accepted results and targets	currentEvidence on Study (DM §3.6)	Written in every study-scoped canonical transaction (CR-1)

3.15 What D2-01's reversal changes

The decision. The round-2 proposal said publication writes no evidence, so a published policy would change only what readers derive. Chris rejected it. Publication may create attributable generated session versions (OWNER; register "Decisions already fixed"; consolidation §1). SF6 already anticipated this ("an applicable recorded admin update treatment creates a new incomplete session version"), so SF6 now applies literally.

When publication generates a version (PROPOSAL for the brief). For each affected session whose latest explicit version pins an older form version and falls in a category the admin chose to treat:

Outcome of the recorded treatment for the session	Generated version?	What the generated version holds	Resulting status
Every changed question is doNothing, or no question changed (a target-only or policy-only version)	No	Nothing	Standing derived: pinned to the older version, counted or not as the admin chose; unchanged questions satisfy the new version
autoUpdate on compatible changes and every pinned answer is valid	Yes, PublicationGenerated	The same revision pins, re-pinned to the new form version	Completed stays completed only if the pin map validates under the new version
Option mapping (Q-34)	Yes	New revisions for mapped answers with provenance {sourceRevisionId, mappingRef, operationId, generation}; pins moved to them	As validated
requireReanswer on an answered question	Yes	Pins kept; the answer shows Needs updating; re-pinned to the new version	Incomplete; a completed session stops qualifying
New required question with requireAnswerBeforeCounting	Yes	Re-pinned to the new version; the new question needs an answer	Incomplete
New required question with countEarlierCompletes	No	Nothing	Standing derived: pinned older and counted
Category outside the admin's chosen scope	No	Nothing	Standing derived
Draft-only session (no explicit version)	Never	The draft is rebased (RD-R24)	Not applicable

One session gets at most one generated version per publication generation, combining all its questions' treatments. Generated versions are attributed to the publication operation and the publishing admin; the reviewer stays the effective author of the answers. A generated version never records a Complete that fails validation under its declared form version.

Changes to the versioning model.

Versioning model	Before	After
§1.1 model paragraph; §2 rule 4	Publication is a recorded policy and never writes evidence, with option mapping as the only exception	Publication records a policy and may write attributable generated session versions and mapped revisions under the table above; where it writes none, effects stay derived
§2 rule 6; §4.4	Operational settings never version; the minimum target is an operational setting	The standard target is inside the form version; other settings follow §3.5
§3.5	A declaration may change until a revision pins the version	Immutable from commit; declared by the publisher; corrected by guided rollback and republication
§3.9	One designer pending record with a lease and take-over	Collaborative design drafts with per-item base checks (§3.7)
§7.2, §7.3	Kinds Save, Complete, Withdraw; "there is no publication-written transition"	Kinds include PublicationGenerated (and DM's merge kinds); generated transitions follow the table above
§7.5	SF6 read as "changes the effective standing"	SF6 applies literally when a version is generated; derived standing remains for the no-generation rows
§7.6	No autosave trail; second tab read-only with take-over	Draft change log kept; concurrent tabs reconciled by base checks; the take-over presentation is a brief detail
§8.1, §8.4	"Nothing is applied to a session"	Generated versions apply the chosen treatment explicitly
§8.5	Phase 2 rewrites projections only	Phase 2 also writes generated versions and mapped revisions, per Study, idempotently
§8.7	FV4 appends a policy generation	Unchanged, and a new generation may generate further versions; earlier generated versions stay in history
§8.8	A late Save on a superseded version is accepted pinned to it	Still true where no version was generated; where one was, the Save is refused as stale and the draft is rebased (RD-R24)
§8.9	Option mapping as the only derived-revision writer, OPEN	Q-34 decided; mapping is one of the generated-version cases
§9.3	Any candidate version change drifts the task	A generated version drifts only the questions whose pinned revision or class changed, or a candidate that stopped qualifying

Changes to the consistency model.

Consistency model	Before	After
§4.2 publication phase 2 item	Rewrites the Study summary; writes no evidence	Per Study, one short transaction: generated versions by compare-and-set on each session head, mapped revisions, Study (version CAS, summary, currentEvidence), notice intents; deterministic version ID per (sessionId, operationId, generation)
§7.4	"It writes no evidence (D2-01)"	Writes generated versions; the admission and readiness pause for the form stays; the operation limit is measured (D2-10)
§4.4 drafts	A stale autosave after a newer explicit version is rejected and discarded by the client	A draft or autosave whose base was superseded, by a generated version or by the reviewer's own Save in another tab, is rebased onto the new version at the next autosave or Save; non-overlapping changes apply; overlapping ones are kept as a conflict copy; nothing is discarded silently
§15 conflict map	No row	New row: a generated version never overwrites a newer reviewer version (session head CAS; recompute against the new head)
§16 failure modes	Phase 2 crash rewrites projections again	Phase 2 crash resumes; replays return existing generated versions
§19.3	D2-01 "publication writes no evidence"	D2-01 decided as amended; D2-07 and D2-08 decided; D2-12 and D2-16 replaced

What does not change. Phase 1 still does constant work (fence, drain, digest recheck, head compare-and-set, policy and operation records). One publication per form. Policy records are append-only generations. The impact manifest is built after commit and is never an input to an effect. Admission and readiness for the form pause while phase 2 runs.

4. What loads and writes when

Each action lists what is read, what is written, the transaction boundary, and what is derived afterwards with how it stays current. "Study write" means the per-study compare-and-set with the canonical summary and currentEvidence (CR-1).

4.1 Open a Study and form from any stage, tab or device

Aspect	Detail
Reads	Admission (permissions, allocation, availability, step rules; SP); the session head and its latest explicit version; the draft head and materialised draft; the form versions pinned and current; applicable reconciled-answer hints and their provenance (RS); the reviewer's own answers on other forms (SF5)
Writes	A connection record. A capacity claim if the reviewer has no place yet and capacity allows (SP). Nothing else: opening creates no session
Transaction boundary	The claim is one atomic conditional update on Study; the connection is its own write
Derived afterwards	The form host shows the status (draft auto-saved, version checkpoint saved, completed), any Needs-updating or outdated marks, and any alert left by a publication since the reviewer's base

4.2 Autosave

Aspect	Detail
Trigger	A debounce after edits (the earlier 2-second figure is proposed, not approved)
Reads	Draft head (draftVersion, base explicit version, base form version)
Writes	One SessionDraftChange holding only the changed answers, each with its per-answer base; the draft head (draftVersion + 1, materialised draft). The first autosave also creates the session by upsert on its deterministic ID
Transaction boundary	Draft head compare-and-set on draftVersion; never Study
Concurrency	Two tabs or devices may autosave. A change whose answers did not change since its per-answer base is applied. A change to an answer that moved since its base is kept as a recoverable conflict copy and both values are shown (D2-08; the take-over or read-only presentation is a brief detail)
Derived afterwards	Status "Draft auto-saved" (illustrative wording; UX). Status, current explicit version and qualification are unchanged

4.3 Save (version checkpoint)

Aspect	Detail
Reads	Session head, draft etag and changes, declared form version, form head (fence), admission, dependent work for the warning in §4.5 when the session was completed
Writes	Revisions for changed answers; one immutable Save version with the full pin map; session head CAS; draft consumed; Study write (member savedIncomplete); on the first explicit version, the slot claim is released and presence replaced exactly once (RT-05)
Transaction boundary	One interactive transaction with the command-bearing record
Derived afterwards	Status "Version checkpoint saved". A Save after Complete removes the completed qualification at once (SL3). Readiness and sufficiency are re-derived at query time

4.4 Complete

Aspect	Detail
Reads	As Save, plus the applicability evaluator over the whole form under the declared version, independent of which questions are rendered (virtual scrolling)
Writes	As Save, with kind Complete; member completed with its standing
Transaction boundary	One interactive transaction
Refusals	ValidationFailed naming the blocking question and context; StaleBase keeps the draft; OutcomeUnknown is retried with the same command ID
Derived afterwards	One qualifying contribution per reviewer per Study × form, whichever route was used (SF2). Readiness and automatic stage completion re-derive (SP)

4.5 Save as incomplete after Complete, with dependent work (Q-27)

Aspect	Detail
Reads before commit	The session's current completed version; reconciliation tasks whose input set pins it; accepted results that used it; dependent steps whose readiness it supports; all shaped by blinding
Shown before commit	"Saving this as incomplete removes your completed review from S-101, Risk of bias. A reconciliation in progress for this study uses it and will need re-checking. Accepted answers published on 3 October used it; they stay as they are and may be reconsidered." No reconciler name or other candidate is shown to a blinded reviewer
Writes	As Save. Nothing is written to the dependent records
Recheck at commit	The dependency set is recomputed in the commit snapshot; if it grew, the reviewer confirms again
Notified after	Each affected author once (the reconciler holding the task; the reconciler who published the accepted answers), through a deduplicated in-app notice explaining the change at their level of access
Derived afterwards	Readiness from current evidence; the task shows "inputs changed · re-check"; accepted results stay effective until someone explicitly reconsiders them, which creates a new immutable result version (RS); automatic stages re-evaluate remaining work, manually completed stages stay complete (SP)

4.6 Inactivity timeout and expiry

Aspect	Detail
Trigger	Every connection to the session idle beyond the form's timeout, or closed
Reads	All connections' last activity; the draft's last activity; the claim
Writes	Claim released on Study through the claim release path. No history event is written; claims and their releases are not retained as history (SP §3.14, §4.9). The draft is kept
On return	Admission and capacity are rechecked. If a place is available the reviewer continues with the draft. If not, SyRF says so honestly and keeps the draft; the reviewer may discard it or wait (SP owns capacity behaviour)

4.7 Edit a design draft with others present; publish from one of several drafts

Aspect	Detail
Open	Reads the current published version, open drafts and a presence snapshot; joins the presence group for that form or profile (only users with design access)
Edit	The client sends {draftId, itemPath, baseItemRevision, value, clientChangeId}. The server appends a DesignDraftChange and bumps draftRevision by compare-and-set when the item's revision equals the base. A duplicate clientChangeId returns the original result
Conflict	A stale base is refused. The client keeps the local edit beside the current value and offers "keep mine" (a new change on the current base) or "discard mine". Nothing is overwritten silently
Live updates	Accepted changes send a hint to other open views; they fetch and merge per item while keeping their unsaved local edits
Publish	Starts the publication in §4.8 from one draft. The unique active-publication index refuses a second publication (PublicationInProgress). If another draft published since this draft's base, the draft is rebased item by item, conflicting items are resolved, and the impact preview is recomputed against the resulting state (D2-11)
Derived afterwards	Every published version and its history keep the actor, time and base revision of each change

4.8 Publish a form version with question changes

1. Preview (no authoritative writes). Reads the diff between the draft and the current published version; each changed question's change class and SyRF's compatibility suggestion; usage evidence at the protected boundary (C8; draft-only counts from drafts); sessions by category (completed, saved incomplete, draft only), prior form version and route; active connections; reconciliation tasks in progress; accepted results built on affected answers; dependent steps; any Study overrides if the target also changes. Stores a preview digest.
2. Declarations and treatments. The publisher declares compatibility for each changed question, allows or refuses option mapping per option, and chooses treatments per question and per category, as attributed draft changes. Meaning changes must be declared incompatible; mapping never bypasses option or type validation or a mandatory re-review (Q-34).
3. Phase 1 (constant work). Fence the form; drain; recompute the digest in a pinned snapshot; on a change return PreviewDigestChanged for re-confirmation. Otherwise, in one short transaction: commit the new question versions with their declarations and mappings, insert the form version, compare-and-set the form head, write policy generation 1 and the operation record, write the notice fan-out intent, and record a FormVersionPublished history event. Release the fence.
4. Phase 2 (per Study item). For each Study with an affected session: read the sessions in scope, apply the generation table (§3.15), compare-and-set each session head against the version the plan used (recompute if the reviewer saved meanwhile), write generated versions and mapped revisions, write Study, capture notices once per recipient. Admission of new studies to the form and reconciliation-readiness changes pause until phase 2 ends; reviewers keep saving.
5. After. The impact manifest is built from authoritative records at the operation's stamp. The publisher gets a completion or stall notice. Reviewers see an in-form alert when they next open the session. Drafts rebase at their next autosave.

4.9 Publish a form version that changes only the standard target

Aspect	Detail
Preview	Studies whose sufficiency changes (below or above the new target), reconciliation readiness changes, accepted results that would change authority, Studies with overrides and their treatment (RD-R16), active places beyond the new target where capacity enforcement uses it (SP)
Treatments the admin confirms	For a raised target: keep existing accepted results current, labelled "below current target" (RS-R10), or suspend them pending reconciliation with the new number of reviewers (RS defines the result record). For a lowered target with AutoAccept: create SingleAnnotator results now, or at the next qualifying completion, for Studies that now have exactly one qualifying candidate and no accepted result (RS §4.6, RS-R11). For each override group: an explicit treatment (RD-R16)
Writes	Phase 1 as §4.8 (no question versions). Phase 2 per Study: result versions under the confirmed treatment, override versions where the admin chose to change them, Study write. No session version is generated
Derived afterwards	Effective targets and readiness at query time; automatic stage completion re-evaluates; stage filters that use reconciled answers re-evaluate the affected Studies (SP)

4.10 Apply a Study target override

Aspect	Detail
Reads	The current published form version and its standard target; the current override version; qualifying contributions for the Study × form from currentEvidence (verified current); active places and drafts; the open reconciliation task and the current accepted result
Shown before commit	Old and new effective target; readiness change; active reviewers affected (counts, names only with Monitor, D3-20); whether lowering the target leaves temporary reservations beyond it, with Cancel or Apply anyway (Apply anyway releases those reservations only and keeps drafts; Q-24)
Writes	One StudyTargetOverride version; Study write (currentEvidence.effectiveTarget); a StudyTargetOverrideChanged history event; reservation releases if Apply anyway was chosen
Transaction boundary	One study-scoped interactive transaction
Derived afterwards	Readiness and capacity; automatic stage completion; notices to the reconciler if readiness changed and to reviewers whose reservation was released. No form version is created

4.11 Bulk additional-review request

Aspect	Detail
Preview	The selected Studies (a list or a saved selection resolved at preview); per Study the standard target, any override, current qualifying count, the new effective target, and each named assignee's eligibility; assignees who already have a qualifying contribution on a Study are flagged because they cannot count twice; active work
Writes at commit	The request record and, for large selections, an operation record. Per Study, one short transaction: an override version with basis AdditionalReviewRequest(requestId, raiseBy), a scoped assignment per named member or group, and the Study write. Each item is idempotent per (requestId, studyId)
Notified after	One notice per assignee per request listing their Studies; the requester gets progress and completion
Derived afterwards	Sufficiency uses the raised effective target; qualifying reviewers count once across routes; the extra assessments see no other candidate's answers; the reconciler is told when readiness changes. Nothing sets an accepted result automatically (RA5)

4.12 Publish a screening-profile version

Aspect	Detail
Preview	The proposed version against every profile version still in use by existing decisions, collective outcomes and adjudications; mismatches and their consequences per Study; active screeners and adjudicators; dependent pools (SP) and accepted results (RS); whether eligibility changes and therefore needs a protocol amendment entry (RI, D4-05)
Treatments the admin resolves	Keep decisions pinned to their version; request new decisions; or carry compatible decisions forward as attributable generated profile-session versions. Policy is recorded at profile scope, never per stage
Writes	Phase 1 as §4.8 for the profile. Phase 2 per Study: generated profile-session versions where the treatment carries forward or requests renewal, the collective outcome recomputed under the chosen policy, the Study write, notices
Derived afterwards	Required new screening stays visibly pending; original decisions, outcome history and frozen reports are untouched; changed outcomes trigger targeted pool re-evaluation with structured history (SP); accepted or adjudicated results whose inputs changed follow the explicit reconsideration rule

4.13 Revise a publication policy (FV4) and guided correction

• FV4 revision. Reads the operation and its current policy generation. Writes a new generation by compare-and-set. Phase 2 re-sweeps under the new generation and may generate further versions, for example restoring a completed status by re-pinning a session to the form version under which its Complete was validated. Earlier generated versions stay in history.
• Guided correction of a wrong compatibility declaration or mapping. Reads the publications that used the declaration and every generated version and mapped revision they produced. The preview shows what rolling back changes. The commit creates a corrected question version (same content, corrected declaration), publishes a new form version through §4.8, and generates versions that restore the pre-mapping values or apply the corrected treatment, each attributed to the correction. The wrong declaration stays in history with a "corrected by" link. Nothing is edited in place.

4.14 Shared-question accepted answers across two forms (D2-09, decided)

Decided-amended by Chris on 5 October 2026 (programme status page, 03:37 BST; recorded as answers/D2-09: "agree", with the note "But should be encourage to provide a reason (though not compulsory). They can also raise query if need be."; decision register §1.16). The recommendation is adopted with two amendments. This supersedes the earlier text of this section, which carried both options behind a parameterised fixture until Chris answered.

When two forms share a question and the first form's reconciler has already accepted an answer for a Study:

• What the second reconciler sees. The second form's reconciliation task reads the existing accepted answer with its source snapshot and reconciler. It is shown as a labelled hint with an explicit "Use accepted answer" action (click-to-fill), never prefilled (OS-A04; RS-R32, RS-R33); the reconciler's name follows RS-R32's history-access rule. The original question's word "prefilled" is superseded by OS-A04.
• Revision. The second reconciler may revise the accepted answer in their own final submission. The Complete publishes a new snapshot (RS §3.3); where the answer changed, the new reconciled revision carries provenance {supersedesEntry, task, reconciler} and, when given, the reason. Where the reconciler keeps the existing answer, the snapshot keeps the existing entry unchanged (GS1; PROPOSAL). Earlier snapshots stay in history, and RE4 still holds: there is one shared accepted answer, never competing gold.
• Reason (amendment 1). When the reconciler's answer differs from the existing accepted answer, an optional reason field is shown and prompted for. Save progress and Complete never require it. A given reason is stored with the revision's provenance and shown in accepted-answer history. The prompt's wording and placement are a UX brief detail (PROPOSAL).
• Query (amendment 2). The reconciler may also raise a query on the accepted answer when needed, through the queries release R4b (QY1; AC-R4b-01, AC-R4b-10): the query targets the accepted-answer version they saw. Queries remain the route for everyone else.
• Placement. Forms that overlap on reconciled questions need R2d (A-19), so pilots before R2d still use forms that do not overlap. The query action needs R4b.

Tests: FX-VM-45 (RD-AE25). Tracker rows T-OI-01 (Decided) and T-RD-06.

5. Rules

ID	Rule	Source
RD-R01	The Study is the project's reviewable item. Forms, sessions and targets attach to Study × form and are shared across stages.	OWNER consolidation §1
RD-R02	A reference is an immutable import record and a report is a source document. Original imports, identities, sources and import times are kept; two references are never collapsed into a fabricated original. Storage follows §3.3.	OWNER consolidation §1; storage PROPOSAL
RD-R03	A conference abstract and a journal article may remain separate Studies. Linking distinct reports to one investigation is deferred.	OWNER consolidation §1; D4-08 (RI)
RD-R04	One session per reviewer per Study × form, reached from every stage, tab and device. Route and stage provenance stay on submitted versions; stages never own the evidence.	OWNER consolidation §1; SF1
RD-R05	Autosave sends diffs with base-version checks, keeps a recoverable draft and a reconstructable history, and never submits, creates a version or changes qualification.	OWNER consolidation §1; SL1
RD-R06	Save creates an immutable checkpoint that may be incomplete and becomes current. A Save after Complete removes the completed qualification.	OWNER consolidation §1; SL2, SL3
RD-R07	Complete validates every required applicable answer on the server, independent of what is rendered, and creates a completed checkpoint.	OWNER consolidation §1, §6
RD-R08	Status text keeps draft auto-saved, version checkpoint saved and completed distinct; the words may iterate.	OWNER U1 (D3-03); UX
RD-R09	Readiness uses current applicable evidence at query time, or a projection guaranteed current for its input versions. A stale projection never authorises work.	OWNER Q-27
RD-R10	Before an explicit change that affects dependent work, the actor sees which work is affected and how, within their access and blinding; the dependency set is rechecked at commit; affected authors are informed afterwards. Dependent work and accepted results are never rewritten automatically; reconsideration is explicit and creates new immutable versions.	OWNER Q-27
RD-R11	The form owns the inactivity timeout and per-reviewer in-progress limit across routes and tabs. One idle tab never releases the place while another connection is active. Expiry keeps the draft.	OWNER D2-07, Q-28
RD-R12	The standard reviewer target is part of the immutable form version. Changing it creates a new form version and goes through the publication impact process, even without question changes.	OWNER target-versions-form
RD-R13	Every other form setting is classified as inside the version or operational, using the rule and table in §3.5.	PROPOSAL (D2-05 brief)
RD-R14	A Study target override is an immutable, audited, versioned Study × form decision applying across routes. There is no step-level override. Changing one override creates no form version.	OWNER consolidation §1
RD-R15	Results and readiness snapshots record the form version and any override version they used.	OWNER target-versions-form
RD-R16	When a new standard target is published, every existing override gets an explicit admin treatment in the preview (keep its effective value, rebase it, or remove it). The suggested default keeps each Study's effective target unchanged and flags overrides that become redundant or fall below the new standard. No effective target changes silently.	OWNER requires an explicit definition; the treatment set is a PROPOSAL
RD-R17	An additional-review request may name people or groups and many Studies. It raises each Study's effective target explicitly through an override version, and qualifying reviewers count once across routes.	OWNER consolidation §1; D3-13 clause
RD-R18	The reviewer target is a minimum and stays separate from any enforced capacity cap.	OWNER consolidation §1; D3-17 (SP)
RD-R19	General statistics show the standard target and explain study-specific exceptions separately.	OWNER consolidation §1; reading in §12
RD-R20	Compatibility belongs to the immutable question version. SyRF suggests a default; the authorised publisher declares compatibility and whether mapping is appropriate, with actor and time. The declaration never changes; corrections use guided rollback and republication.	OWNER D2-02 amended, Q-34
RD-R21	Option mapping is explicit per option, allowed only where meaning is unchanged, and writes new immutable revisions with mapping provenance while keeping the originals. It never bypasses type or option validation or a mandatory re-review.	OWNER Q-34
RD-R22	Publication previews the impact on existing work under every prior version and every route and on active reviewers, records the admin's treatment, and rechecks the inputs at commit.	OWNER consolidation §1; Q-20; FV2
RD-R23	Publication may create attributable generated session versions under the table in §3.15. A generated version is attributed to the operation and the publisher, never claims a Complete that fails validation, and never overwrites a newer reviewer version.	OWNER D2-01 amended; table PROPOSAL
RD-R24	Drafts survive publication. A draft whose base was superseded, by a generated version or by the reviewer's own Save in another tab, is rebased: non-overlapping changes apply, overlapping ones are shown as a conflict with both values, and nothing is discarded silently. A late Save on a superseded base is refused as stale where a version was generated.	OWNER Q-20, D2-10 ("prevent stale saves … overwriting"); mechanism PROPOSAL
RD-R25	Many drafts may exist; one publication operation per form or profile is active at a time; the next publication rechecks its impact against the state the previous one produced.	OWNER D2-11
RD-R26	Design pages show authorised presence (viewing and editing), reflect accepted changes live, keep local unsaved edits, refuse silent overwrites by base checks, keep conflicting edits recoverable, and stamp each accepted change with actor, time and base revision. Presence is never an audit record. Drafts never alter a published requirement.	OWNER collaborative question drafts
RD-R27	Screening profiles have immutable versions. Publication detects mismatches with the exact versions of existing decisions, outcomes and adjudications, previews them, and applies the admin's treatment after a final recheck. Originals and frozen reports are kept; required new screening stays pending.	OWNER Q-26
RD-R28	A reviewer's own edit that makes another answer need attention produces an in-form warning only. A change by someone else produces a deduplicated in-app notice per recipient and cause. Notices for generated versions follow the recorded impact policy.	OWNER Q-20
RD-R29	A target change may lead to a new accepted-result version under the agreed authority rules. It never rewrites an old result, invents a missing review or invalidates a recorded answer.	OWNER target-versions-form; Q-29 (RS)
RD-R30	A data-type or selection-multiplicity change is an incompatible version of the same question identity.	PROPOSAL D2-03 (BRIEF)
RD-R31	A stage binds the form identity and records the version it bound; the live route presents the session's resolved version; the effective target comes from the form version and any override, never from the stage.	PROPOSAL D2-04 (BRIEF)
RD-R32	System questions are stored as versioned data and reach a project only when its admin publishes a form version that pins the new system version.	PROPOSAL D2-06 (BRIEF)
RD-R33	No form is excluded from the new engine because of its size. The largest project is an acceptance case; commit, draft and pin limits are engineered and measured to fit it.	OWNER D2-16 replaced; consolidation §6
RD-R34	Retired 5 October 2026: D2-09 is decided (§4.14). It read "Until D2-09 is answered, pilots avoid forms that overlap on reconciled questions"; overlapping reconciled questions still wait for R2d (A-19). The decided behaviour is RD-R37.	OWNER D2-09 (decided)
RD-R35	Publication pauses only the affected form, lets in-flight saves finish, keeps drafts, and has tested pause and operation limits; the earlier 90-second and 30-minute figures are proposed, not approved.	BRIEF D2-10
RD-R36	Nothing on this page authorises implementation, migration, activation or notification delivery.	OWNER hold, 5 October 2026
RD-R37	When two forms share a question, the second form's reconciler sees the existing accepted answer as a labelled hint with click-to-fill (never prefilled) and may revise it in their own final submission, writing a new snapshot with provenance. An optional reason is prompted for when the answer differs and is never required; the reconciler may also raise a query on the accepted answer (R4b).	OWNER D2-09 (Decided-amended, 5 October 2026); OS-A04; reason storage and prompt placement PROPOSAL

6. Authorisation, blinding and provenance

• Capabilities (names are placeholders until A-03; Q-03 approved the list). Review writes sessions and drafts. Design edits design drafts. Publish publishes form and profile versions and makes compatibility and mapping declarations. Applying a Study target override needs Publish on the form or a separate adjust-targets grant (PROPOSAL; settled in the C10 catalogue). An additional-review request needs Request an additional review (RA5). Seeing active reviewers' names in a preview needs Monitor (D3-20). Seeing design presence needs design access.
• Server authority. Every read and command checks scope, permission and admission on the server; hiding a control is never the control.
• Blinding. Warnings and notices about dependent reconciliation never reveal a reconciler's identity or another candidate's answers to a blinded reviewer. Notices about generated versions name the publishing admin, which reveals no candidate. Reconciliation identity blinding and hint availability are form-owned (profile-owned for screening), as RS specifies.
• Provenance on every record. Session versions record actor, effective author, operation, route, declared form version and exposure. Generated versions add the operation, policy generation and publisher. Mapped revisions add the source revision and mapping. Question versions record the publisher's declaration with actor and time. Overrides record basis, actor, reason and the standard target they were made against. Design changes record actor, time and base revision.

7. Active-work impacts

Action	Warned before commit	Rechecked at commit	Notified after	Apply anyway
Form publication (§4.8)	Sessions by category, prior version and route; active connections and drafts; reconciliations in progress; accepted results and dependent steps affected	Preview digest in a pinned snapshot after the drain	Each affected reviewer once (in-form alert and in-app notice); reconcilers with drifted tasks; the publisher on completion or stall	Not applicable; drafts are always kept
Target-only publication (§4.9)	Sufficiency, readiness and authority changes; overrides; reservations beyond a lowered target where enforcement applies	As above	Reconcilers whose readiness changed; reviewers whose reservation was released	Releases incompatible temporary reservations only; keeps drafts; never bypasses permissions or legal configuration
Study target override (§4.10)	Effective target change; readiness; active reviewers	Study version CAS	Reconciler; affected reviewers	As above
Additional-review request (§4.11)	Assignees' existing contributions; capacity	Per-Study item CAS	Assignees; requester	Not applicable
Profile publication (§4.12)	Mismatched decisions and outcomes; active screeners and adjudicators; dependent pools	Preview digest	Affected screeners and adjudicators; admins	Not applicable
Incomplete Save after Complete (§4.5)	Dependent reconciliation, accepted results and steps, shaped by blinding	Dependency set recomputed	Affected authors once	Not applicable
Operational form setting change (timeout, in-progress limit, capacity cap)	Active reviewers whose places or limits change	Settings CAS	Affected reviewers	For a lower cap or in-progress limit, releases conflicting temporary reservations only (SP §7); a shorter timeout counts from the change and needs none

8. Failure and recovery

Failure	Handling	What the user sees
Network loss during autosave	The client retries with the same change ID; a duplicate is success. Whether unacknowledged edits are held on the device, and how, is UX ambiguity A1 (recommended: a bounded in-session holding area cleared at logout, completion and access loss)	"Offline. Your latest edits are held until you reconnect." then "Draft auto-saved" (UX §3.2; illustrative)
Conflicting autosave from another tab	Conflict copy kept; both values shown	Conflict panel with both values
Stale base on Save or Complete	Typed StaleBase; draft kept	The changed answers, with a way to continue
Indeterminate commit	OutcomeUnknown; retry with the same command ID resolves through the ledger	"Checking whether your save landed"
Preview changed before phase 1	PreviewDigestChanged	The publisher reviews the impact again
Second publication attempt	PublicationInProgress	Which publication is running and its progress
Phase 2 crash	Lease expiry, takeover, resume; deterministic generated-version IDs make replays return the existing version	Progress resumes
Phase 2 beyond its limit	The operation stalls, the publisher is notified, admission for the form stays closed on stale projections	"Publication stalled" with progress
Reviewer saved during phase 2	The item recomputes against the new head or skips if the reviewer already declared the new version	Nothing
Late Save after a generated version	Refused as stale; the draft is rebased; overlaps shown	An alert explaining the publication and the rebased draft
Bulk request partly applied	Per-Study items are idempotent; the operation resumes; no Study is half-applied	Progress, then completion
Design draft conflict	Conflicting edit kept beside the current value	"Keep mine" or "Discard mine"
Data loss needing restore	D2-13 isolated point-in-time recovery (BC); this is separate from merge reversal	A recorded history discontinuity

9. User flows and examples

The examples use one project, "Stroke neuroprotection review". Priya Shah is the project admin and publisher. Elena Rossi is a designer. Alice Martin, Ben Okoro and Carmen Diaz are reviewers. Dev Patel reconciles. The Risk of bias form (RoB) has a standard target of 2 and is bound to the Full text and Extraction stages. Studies are S-101 (Okafor 2018), S-102 (Lindqvist 2020) and S-103 (Tanaka 2019).

9.1 Alice works across two stages, two tabs and a phone

1. Loading. Alice opens S-101 RoB from the Full text stage on her laptop. The form shows a loading state, then "No answers yet". No session exists until she types.
2. Draft. She answers Q1 to Q4. Autosave sends four small changes. The status reads "Draft auto-saved". Her place is held.
3. Second tab. She opens S-101 RoB from the Extraction stage in another tab. It is the same session with the same draft and the same place. She edits Q6 there; the change merges.
4. Conflict. She edits Q2 in both tabs within seconds. The second change arrives on a stale base. That tab shows a conflict panel with both values; she keeps the later one.
5. Checkpoint. She presses Save progress. Version 1 is a checkpoint, incomplete. The status reads "Version checkpoint saved". Her draft is consumed.
6. Phone. On the train she continues on her phone (UX: full annotation on phones). She answers the rest and presses Complete. Server validation finds Q11 required and unanswered although it was below the visible area; the error names Q11. She answers it and Completes. Version 2 is completed and counts once for RoB on S-101, in both stages.
7. Failure. Her phone loses signal mid-edit. The status reads "Offline. Your latest edits are held until you reconnect." (UX §3.2; how edits are held is UX ambiguity A1); the change is sent when she reconnects.

9.2 Alice saves an incomplete correction while Dev is reconciling

Dev has started reconciling S-101 RoB with Alice's and Ben's completed versions. Alice reopens S-101 and changes Q5. Autosave alone leaves her completed version current. She presses Save progress. Before commit she sees: "Saving this as incomplete removes your completed review. A reconciliation in progress for this study uses it and will need re-checking." She confirms. Version 3 is incomplete and current; S-101 RoB now has one qualifying contribution. Dev gets one notice: "Inputs changed for S-101 Risk of bias: a candidate review is no longer complete." His draft reconciliation is kept and shows "inputs changed · re-check". Nothing in his work or in any accepted answer was rewritten.

9.3 Priya publishes RoB version 3 with a mapped option and a new question

RoB v3 replaces Q7's option "Unclear" with "Some concerns" (a new option ID; Priya declares the meaning unchanged, so Q7 is compatible with a mapping Unclear → Some concerns) and adds a required Q12.

1. Preview. 40 completed sessions, 12 saved incomplete, 5 draft only, across both stages. Q7: SyRF suggests incompatible (an option was replaced); Priya declares compatible with the mapping and records why. Q12: she chooses "require an answer before counting" for completed sessions.
2. Commit. Phase 1 takes a short drain and commits. Phase 2 runs per Study.
3. Alice (completed under v2). A generated version 4 pins v3, carries her Q7 "Unclear" as a new mapped revision "Some concerns" with provenance, and leaves Q12 unanswered. It is incomplete, so S-101 RoB loses her qualifying contribution. Her history shows "Version 4 · generated by publication of Risk of bias v3 · Priya Shah". She gets one notice and an in-form alert.
4. Ben (saved incomplete). He gets a generated version re-pinned to v3 with his Q7 mapped.
5. Carmen (draft only, active). No version is generated. Her next autosave rebases the draft on v3; her Q7 draft value shows "mapped on publication" beside the original. She keeps working.
6. Race. Ben pressed Save on v2 while phase 2 ran. His Save committed first; the phase 2 item recomputed against his new head and generated on top of it.

9.4 Priya raises the RoB standard target from 2 to 3

RoB v4 changes only standardTarget. The preview lists 140 Studies whose sufficiency drops below target, 60 with accepted results, and one override: S-103 is set to 2 (made against standard 2). Priya keeps accepted results current, labelled "below current target (accepted under target 2)". For S-103 the suggested default keeps the effective target at 2 and flags that it is now below the standard; she chooses "remove", so S-103 follows the standard of 3. No session version is generated. Readiness for S-102 now waits for a third reviewer. The Full text stage, completed manually, stays completed; the Extraction stage, which completes automatically, shows remaining work again.

9.5 Dev requests one more review for 40 Studies

Dev selects 40 Studies with a reconciliation disagreement and asks for one additional review each, assigned to the group "Senior extractors". The preview shows that Carmen, a group member, already reviewed 6 of them and cannot count twice there. Commit writes 40 override versions (basis: Dev's request, raise by 1) and 40 scoped assignments. Each group member gets one notice listing their Studies. When a third qualifying review lands, the task's readiness changes and Dev is told. The project dashboard still shows "Target: 2 reviewers per study" with "40 studies have a study-specific target" listed separately.

9.6 Elena and Priya draft at the same time

Elena opens RoB's draft "Wording fixes". Priya's avatar shows "viewing", then "editing Q3". Elena edits Q9's help text; Priya's view updates without touching Priya's unsaved Q3 edit. Both edit Q4's wording. Priya's change lands first; Elena's arrives on a stale base and is refused. Elena's text stays beside the new value and she chooses "keep mine" on the new base. Meanwhile Priya publishes a separate draft, "Guidance update", as RoB v5. Elena's draft is now based on v4; when she publishes, SyRF rebases it item by item and recomputes the impact against v5.

9.7 Priya publishes a new title and abstract profile version

The new version enables Unsure (RS) and narrows the species criterion. The preview finds decisions under versions 1 and 2, 300 collective outcomes and 4 adjudications. Priya keeps decisions on Studies already excluded pinned, requests new decisions where the narrowed criterion applies, and carries compatible decisions forward. Required new screening stays pending. An amendment record is required because eligibility changed (RI). Frozen PRISMA reports are unchanged.

9.8 Priya corrects a wrong mapping

A week later Priya realises "Unclear" and "Some concerns" differ in meaning. She starts a guided correction from the v3 publication. The preview lists 47 mapped revisions. The commit creates a new Q7 version declared incompatible, publishes the next RoB version with "require re-answer" for Q7, and generates versions marking Q7 as needing an answer. The original mapping stays in history marked "corrected by correction K-2 on 12 October".

9.9 Ben's place expires

Ben has S-102 open in two tabs. He leaves one idle and keeps typing in the other; his place stays. He then leaves both for longer than the form's timeout. The place is released and his draft is kept. When he returns, RoB is at capacity under an enabled cap; SyRF tells him so and keeps the draft.

9.10 Shared accepted answers (decided)

Forms RoB and "Reporting quality" both include Q2. Dev publishes accepted answers for S-101 through RoB. Once R2d lets the two forms overlap, the Reporting quality reconciler sees Dev's Q2 answer as a labelled accepted answer with "Use accepted answer"; the control stays empty until she clicks. She answers differently, and a field asks why she is changing the accepted answer; she writes a short reason, though she could leave it blank. Her Complete creates a new snapshot that records who superseded what, and why. She could also have raised a query on Dev's answer if she wanted it reviewed (D2-09, decided on 5 October 2026).

10. Rollout and adoption

Scope	Release or lane	Notes
Versioned questions and forms with standardTarget and ReconciliationPolicy inside the version from the first canonical form; sessions; diff-based drafts with the change log; Save and Complete; whole-form validation; one place within one stage	R2a	No settings-only target path ever exists for canonical forms. Design drafts with base checks and attributed changes ship here for a single editor at a time
One session and place across stages; form-owned timeout and in-progress limit; connection tracking	R2b	Capacity mechanics are SP's (D3-17, D3-18)
Publication with impact including generated versions, compatibility declaration at commit, Q-34 mapping, target-only publications, Study target overrides and the override treatment at publication; collaborative drafts with presence and live updates; one publication per form	R2c	Freeze F2 must include the generation table and the draft rebase rule
Overlapping forms, Fix, FV4 generations, guided correction	R2d	D2-09 is decided: the second form's revision of shared accepted answers, with the optional reason, ships with overlapping forms; its query action needs R4b
Profile publication with mismatch detection	R3b	Content of profile versions is RS's
Additional-review requests raising targets; result versions under target changes	R4a	RS owns result authority
References, source-document links, StudyVersion for new imports	P1	DM extends StudyVersion for merges in P2
StudyVersion for existing Studies	First need, or baseline conversion	Labelled CurrentSnapshotOnly (BC)

• Baseline and MVP. Everything above is baseline for canonical projects. There is no opt-in beta in this specification.
• Deferred. Grouping distinct reports into one investigation (D4-08, RI). Offline review and PWA caching (UX).
• Flags. Canonical behaviour follows per-project enrolment (R0). No new environment flag is proposed for generated versions because they are part of the publication contract; a project's publication scope can be withdrawn through enrolment as the kill switch (PROPOSAL).
• Pilots. The largest project (Francesca's) is an acceptance case at the max tier from R2a. Staging pilots use the seeds D3-14 adds; production pilots wait for their own approval.
• Dependencies. F1a (engine contracts, storage ADR), F2 (publication), FEAT-024 usage evidence or Q-31(b) counting, the notification capture contract (delivery is not authorised), SP for capacity and pools, RS for result authority.

11. Acceptance evidence

ID	Evidence	Verification	Amends
RD-AE01	200 autosaves on a 2,023-question form send only changed answers; the draft rebuilds byte for byte from its base and change log; no session version and no Study write occur	Integration	AC-R2a-01, AC-R2a-28
RD-AE02	Two devices edit different answers concurrently and both changes apply; the same answer edited from a stale base yields a conflict with both values recoverable	Integration, e2e	AC-R2a-06
RD-AE03	A Save after Complete removes qualification; autosave does not; a later Complete restores exactly one contribution	Conformance	AC-R2a-02, AC-R2a-18
RD-AE04	Complete refuses a missing required applicable answer that was never rendered, naming it	Conformance, e2e	AC-R2a-03
RD-AE05	One place across two stages and two tabs; one idle tab with another active keeps it; all connections idle past the form timeout release it and keep the draft	Integration	AC-R2a-37, AC-R2b-03, AC-R2b-10
RD-AE06	The pre-commit warning lists every affected task, accepted result and step without revealing blinded identities; the set is rechecked at commit; each affected author gets one notice; no dependent record changes	Integration, e2e	New
RD-AE07	An injected stale readiness projection never admits a reconciliation start	Integration	New
RD-AE08	A target-only change creates a new form version, shows sufficiency and authority changes, generates no session version, and readiness reflects the new target at query time	Integration, e2e	AC-R2a-33; FX-VM-42 (target part)
RD-AE09	Lowering 2 → 1 under AutoAccept creates SingleAnnotator results only where exactly one qualifying candidate exists; Studies with several agreeing candidates are never auto-accepted; raising the target deletes no result	Conformance	New
RD-AE10	Each override change is a new immutable version; results record form and override versions; an override change creates no form version	Integration	New
RD-AE11	Publishing a new standard target lists every override with its treatment; no effective target changes without a recorded choice	Integration, e2e	New
RD-AE12	A 500-Study additional-review request writes one override and one assignment per Study, idempotently on replay; an assignee who already qualifies is not counted twice	Integration, benchmark	New
RD-AE13	Project statistics show the standard target and list study-specific exceptions separately	e2e	New
RD-AE14	The publisher's declaration is stored with actor and time and cannot be edited; correction goes through guided rollback and republication	Conformance, integration	AC-R2c-21
RD-AE15	Mapped revisions carry provenance; originals are unchanged; a declared incompatible change cannot be mapped	Conformance	AC-R2c-23
RD-AE16	Generated versions follow §3.15 for every treatment combination, are attributed, never record an invalid Complete, replay idempotently after a forced phase 2 crash, and never overwrite a newer reviewer version under barrier-forced races	Conformance, integration	AC-R2c-02, AC-R2c-05, AC-R2c-10
RD-AE17	No draft edit is lost across a publication; non-overlapping edits rebase; overlapping edits show both values	Integration, e2e	New
RD-AE18	A late Save after a generated version is refused as stale and rebased; under doNothing a late Save is still accepted pinned to its declared version	Integration	AC-R2c-20
RD-AE19	One notice per recipient per publication; a reviewer's own edits give in-form warnings only	Integration, e2e	AC-R2c-07
RD-AE20	With two drafts, the second publication is refused while the first runs, then requires a rebase and a recomputed impact	Integration	AC-R2c-14
RD-AE21	Presence is visible only to users with design access; accepted changes appear in other views within a measured latency (target proposed, not approved); local unsaved edits survive; every change has actor, time and base revision	e2e, integration	New
RD-AE22	Profile publication finds every mismatched decision, outcome and adjudication version; required new decisions stay pending; frozen reports are unchanged	Integration, conformance	New
RD-AE23	Save, Complete, preview, phase 2 generation and phone annotation pass at the max tier (2,023 questions, the largest project) within measured budgets	Benchmark, e2e	Replaces AC-R2a-22's ceiling
RD-AE24	Citations are never edited or moved; a Study's references are read through its StudyVersion links; an abstract and an article can stay separate Studies	Integration	New
RD-AE25	FX-VM-45 tests D2-09's decided option: the second form's reconciler sees the existing accepted answer as a hint (never prefilled), a revision in their final submission writes a new snapshot with provenance, the optional reason is prompted for when the answer differs and is never required, and a query can be raised on the accepted answer (R4b)	Conformance, integration	FX-VM-45
RD-AE26	Publication protection holds under load and its pause and operation limits are measured and recorded	Benchmark	AC-R2c-06, AC-R2c-15
RD-AE27	Testers can tell a draft auto-saved from a version checkpoint and from a completed session	User test	UX criteria
RD-AE28	From every bound stage the live route presents the session's resolved version, and the effective target never comes from a stage	Integration	AC-R2b-15
RD-AE29	D2-03 and D2-06 fixtures pass	Conformance	AC-R2c-26, AC-R2a-23

12. Brief items, specialist inputs and unapproved proposals

Entries this specification owns (brief §2).

Entry	Kind	Required treatment
D2-10	One of the 22 session-register brief entries	Specify and test the publication active-work protection with generated versions: drain, per-form pause, per-Study items, draft rebase, stale-save refusal. Measure the pause and operation limits; the 90-second and 30-minute figures are proposed, not approved
D2-03	Engineering contract, no owner question	Keep the PROPOSAL (RD-R30) and freeze it at F1a
D2-04	Engineering contract, no owner question	Keep the PROPOSAL (RD-R31); state that targets never come from stages
D2-06	Engineering contract, no owner question	Keep the PROPOSAL (RD-R32)
D2-09	Decided-amended (Chris, 5 October 2026; T-OI-01)	No owner question remains. The brief specifies §4.14 and RD-R37: the revision's provenance and reason storage, the reason prompt (wording and placement with UX), and the query entry point with RS and R4b

Brief details of decided items.

Item	Proposal
D2-05 classification	The §3.5 table; confirm at F1a
Override treatment at publication	RD-R16 treatment set and default
Generation table	§3.15, including whether autoUpdate generates a version or stays derived (recommendation: generate, so a session's current version pins the form version it satisfies; measure the cost under D2-10)
Draft change-log retention	Keep with the session history; any compaction keeps explicit versions and is measured first
D2-08 presentation	Concurrent editing with base checks by default; the brief may choose a read-only-with-take-over presentation for small screens
D2-16 limits	E28 limits in pins and bytes set at or above the max tier with evidence
Presence latency	A measured target, proposed in the brief
Additional-review assignment	How a scoped assignment interacts with allocation and capacity (SP)

Ambiguities, each stated once.

1. "Fully reconstructable history" for autosave. Option A: keep every accepted draft change. Option B: keep only the current draft. Recommendation: A, because the owner's wording and the register's "increasing draft versions" both point to it; it replaces PH-33.
2. "General statistics use the standard target." Option A: headline figures state the standard target, per-Study completion uses the effective target, and exceptions are listed separately. Option B: progress is computed against the standard target alone. Recommendation: A, because B would show a Study with a raised target as done before it is.
3. Override and new standard target. The owner asked for an explicit definition. Recommendation: RD-R16.

Proposals not approved. Every numeric threshold on this page (debounce, drain, operation limit, presence latency, batch sizes). Automatic acceptance of several agreeing candidates (T-POL-03).

Harmonisation notes (5 October 2026).

• §3.5: target-one handling now mentions the conversion-only NoAcceptance value (RS-R04a, PROPOSAL) in the form-version content and the classification table, matching RS and BC.
• §3.5 classification table: assignment expiry names the profile as owner for adjudication tasks and is off by default, matching RS §3.12. The table is otherwise unchanged and is the reference the other specifications now repeat: blinding, hint availability, completeness and outdated-answer mode inside the form version; timeout, in-progress limit, capacity cap, assignment expiry and bulk acceptance as audited operational settings.
• §4.9 and §9.4: result labels and treatments follow RS (label "below current target"; SingleAnnotator results created now or at the next qualifying completion).
• §8 and §9.1: offline wording follows UX §3.2, and on-device holding of unacknowledged edits points to UX ambiguity A1 instead of asserting a local copy.
• §4.6: a timeout release no longer writes a history event, matching SP §4.9 and SP §3.14 (claims and refused queries are not retained as history).
• §3.3: RD's sourceDocumentLinks[] (files) and RI's sourceDocumentKey on referenceLinks[] (report identity) are now tied together; RI owns D4-08 and the key.
• §2: statuses aligned with the owning specifications (Q-29 target part and D3-03 are Decided-amended, as RS and UX record; the D3-13 entry itself is a brief item owned by SP).
• §7 operational-settings row: Apply anyway now matches SP §7 and ACD §7 (available for a lower cap or in-progress limit; a shorter timeout counts from the change and needs none).

13. Amendments to existing package documents

• integrated-plan.md → §4 release table row R2c: replace "publication records a policy and writes no evidence" with "publication records a policy and may write attributable generated session versions". §5.4 R2a: move the form target inside the requirement version; replace "an explicit ceiling in pins and bytes (D2-16)" with "limits engineered for the largest project, an acceptance case"; add the draft change log. §5.4 R2c: add generated versions, target-only publications, overrides and the override treatment, collaborative drafts and presence. §5.4 R2d: add guided correction. §5.6 R4a: additional-review requests raise targets.
• domain-model.md → §4.1 ReviewerStudyEvidence: replace "Publication writes no evidence except Q-34 option mapping" with the generated-version rule; SessionDraft: replace the lease and D2-07 middle ground with the diff change log and the decided form-owned timeout. §4.3 AdditionalReviewRequest: replace "never sets gold or changes the target" with "raises the effective target through override versions; never sets an accepted result". §4.4 placement table: target → FormVersion.standardTarget; idle timeout and in-progress limit → form (SP for mechanics). §4.5 AnnotationForm: requirement part gains standardTarget and ReconciliationPolicy; operational settings per §3.5; delete the D2-16 size-ceiling invariant; FormVersionIssue: replace "Writes no evidence (D2-01)". §5 Study row: add state, currentVersionId, StudyVersion. Add rows for StudyVersion, StudyTargetOverride, DesignDraft, DesignDraftChange, SessionDraftChange. §6.3: add commands ApplyStudyTargetOverride, RequestAdditionalReviews (batch), EditDesignDraft, CorrectPublication; ApplyIssuePolicy writes generated versions. §8: replace "Changes kept, not yet saved" with "Draft auto-saved". §13 F1a row: replace "D2-01 to D2-16 answered" with the statuses in §2.
• versioning-model.md → the rows of the §3.15 table above; §15.1 statuses for D2-01, D2-02, D2-05, D2-07, D2-08, D2-09, D2-10, D2-11, D2-16; §14 fixtures: rewrite FX-VM-42 (a target change creates a form version), keep FX-VM-45 parameterised, add fixtures for the generation table and draft rebase. Update (5 October 2026, evening): D2-09 is decided, so FX-VM-45 now tests the decided option, the optional reason and the query route (RD-AE25).
• consistency-model.md → the rows of the §3.15 table above; §4.2 add rows for the override, the additional-review batch item and the design draft change; §4.5 replace the D2-07 recommendation with the decided form-owned timeout; §14 matrix rows for drafts and Needs updating.
• contracts.md → C4 publication command: "Effects are derived, never written (D2-01)" becomes the generated-version rule; compatibility immutable from commit and declared by the publisher; the operational-settings column loses the minimum target. C5: add PublicationGenerated; delete "There is no publication-written transition"; drafts contract per §3.10 and §3.11; D2-07 and D2-08 decided. C9: the additional-review row raises the effective target; shared question gold stays OPEN (D2-09). Update (5 October 2026, evening): shared question gold follows D2-09's decided option (§4.14, RD-R37).
• acceptance-criteria.md → rewrite AC-R2a-06, AC-R2a-22, AC-R2a-33, AC-R2a-37, AC-R2c-02, AC-R2c-20, AC-R2c-21, AC-R2c-23 per §11; extend AC-R2a-01, AC-R2a-28, AC-R2c-05, AC-R2c-07, AC-R2c-10, AC-R2c-13 (FX-PUB-10K includes generated versions); add RD-AE06 to RD-AE13, RD-AE17, RD-AE21, RD-AE22, RD-AE24 as new rows.
• open-questions-and-assumptions.md → D2 table: statuses per §2; D2-09 remains the one open owner decision (update, 5 October 2026: D2-09 is decided; no owner decision remains open); E28 limits per RD-R33.
• decision-register.md → statuses per §2; superseded rows per §14.
• Owner ledger → overlay notes: RA5's "does not change the normal form target" is superseded by consolidation §1; SF6 now applies literally to generated versions.
• programme-integration.md → notification kinds for generated versions and target changes (capture only; delivery not authorised).

14. Superseded wording

Old wording	New wording	Where it appears today
Publication writes no evidence; no session versions are created by publication (D2-01 round-2 proposal)	Publication may create attributable generated session versions	versioning-model §1.1, §2 rule 4, §7.3, §7.5, §8.1, §8.4, §8.5; consistency-model §7.4, §19.3; contracts C4, C5; domain-model §4.1, §4.5; integrated-plan R2c; AC-R2c-02; open questions D2-01
The form target is an operational setting; changing it is an audited setting change, not a publication (D2-05 round-2)	The standard target is part of the immutable form version; a change is a publication with impact	versioning-model §2 rule 6, §4.4; contracts C4; domain-model §4.5; AC-R2a-33; FX-VM-42
An additional review never changes the normal form target (RA5 boundary)	An additional-review request raises the effective Study × form target explicitly and counts reviewers once	owner ledger RA5; contracts C9; domain-model §4.3
A compatibility declaration may change until a revision pins the version	The publisher's declaration is immutable from commit; corrections use guided rollback and republication	versioning-model §3.5; contracts C4
No autosave trail beyond the current draft (PH-33)	Autosave keeps a reconstructable draft change log	versioning-model §7.6; contracts C5
The second tab is read-only with "Take over editing" (D2-08 recommendation)	One shared session across tabs and devices with base-version checks; the presentation is a brief detail	versioning-model §7.6; consistency-model §4.4; contracts C5; AC-R2a-06
A draft holds the place under today's idle and disconnect timers (D2-07 middle ground)	Form-owned inactivity timeout and per-reviewer in-progress limit; one place across connections; expiry keeps the draft	versioning-model §7.6; consistency-model §4.5; contracts C5; AC-R2a-37
Most restrictive bound stage sets the idle timeout; the stage in use sets the in-progress limit	Form-owned timeout and limits (SP)	domain-model §4.4; AC-R2b-10
Form size ceiling; the 2,023-question project stays legacy (D2-16)	No size-based exclusion; the largest project is an acceptance case	domain-model §4.5; open questions D2-16, E28; AC-R2a-22
Q-34 option mapping OPEN	Decided: the publisher declares compatibility and mapping	versioning-model §1.2, §8.9; AC-R2c-23
Q-26 OPEN: a profile version publishes only before any decision exists	Decided: profile publication with mismatch detection and treatment	versioning-model §5.1, §15.1
"Changes kept, not yet saved"	"Draft auto-saved" and "Version checkpoint saved" (illustrative; meaning fixed)	domain-model §8
D2-09 OPEN: shared-question gold "prefilled as accepted" for the second task, with both options carried until Chris answers (FX-VM-45 parameterised)	Decided-amended (5 October 2026): the existing accepted answer is a labelled hint with click-to-fill, never prefilled (OS-A04); the second reconciler may revise it in their final submission as a new snapshot with provenance; an optional reason is prompted for; a query may also be raised (§4.14, RD-R37)	contracts C9; domain-model §4.3; versioning-model §9.5, §14; AC-R4a-43, C9-T15
StudyEnteredPool for first release of work	WorkFirstReleased (SP; renamed to avoid clashing with stage-pool entry)	domain-model §4.2, §6.2

15. Existing work reused

The dormant QM v2 stack feeds this specification most: PR-A's domain types (#2572), PR-B's publication services (#2573), PR-C's API and save path (#2574) and PR-D's designer (#2575). The validation and response-mode PRs (#2986, #2987, #2629, #2812), the template-import PRs (#3934,

2781) and #2387's child-question checks feed it too. Almost none of it ports as is. The

harvest map is authoritative for every verdict, target and adaptation; this section only summarises it. Nothing is ported while the hold lasts.

Entries	Verdict	Target section
H-DOM-02, H-DOM-06, H-DOM-23	Adapt	§3.4, §3.9; C1, C2 (F1a, T-RD-01)
H-DOM-07	Adapt	§3.4; RD-R32 (T-RD-01)
H-DOM-05, H-DOM-16, H-VAL-08	Reference only	§3.4, §3.9 (T-RD-01)
H-VAL-03, H-VAL-04, H-VAL-07, H-VAL-12	Adapt	§4.4 ValidationFailed; C4, E23, E37 (T-RD-01)
H-DOM-10, H-DOM-11, H-VAL-10, H-VAL-13	Reference only	§3.4, §3.10 (F1a ADR provenance)
H-DOM-08, H-DOM-13, H-API-05	Adapt	§3.5, §4.2 to §4.4 (R2a, T-RD-02)
H-API-01, H-WEB-03, H-WEB-04	Reference only	§3.4 to §3.8, §4.7 (T-RD-02)
H-DOM-01, H-SVC-02, H-SVC-04, H-SVC-05, H-API-02	Adapt	§3.8, §3.15, §4.8 (F2, T-RD-04)
H-DOM-04, H-DOM-17, H-SVC-09, H-SVC-12	Reference only	§3.15, §4.8 (T-RD-04)
H-SVC-01, H-WEB-08, H-WEB-11	Adapt	§4.8 steps 1, 3 and 5 (R2c, T-RD-05)
H-SVC-03, H-SVC-10, H-API-04, H-WEB-06, H-WEB-07, H-WEB-10, H-WEB-12, H-WEB-18	Reference only	§4.8 (T-RD-05)
H-IMP-01, H-IMP-04, H-IMP-06	Reuse	R1a import through the import-target port (T-RD-11)
H-IMP-02, H-IMP-03, H-IMP-05, H-IMP-07, H-IMP-08, H-TREE-01, H-TREE-07	Adapt	R1a (T-RD-11, T-RD-12); the canonical import adapter and the server-side composition refusal in R2a (§10)
H-IMP-09, H-IMP-12, H-TREE-02, H-WEB-17, H-WEB-19	Reference only	R1a; the M0 harvest record (T-RD-10)
H-DOM-03, H-DOM-09, H-DOM-15, H-DOM-18, H-DOM-21, H-SVC-06, H-SVC-07, H-SVC-08, H-SVC-11, H-SVC-13, H-VAL-05, H-VAL-09, H-API-03, H-API-10, H-API-13, H-WEB-01, H-WEB-02, H-WEB-05	Avoid	They contradict §3.7, §3.9, §3.15 and RD-R04, RD-R20, RD-R21, RD-R23, RD-R26, RD-R31

What this specification requires that the earlier work lacks.

• Option identity. Options, mappings, conditions and validation key on option IDs; the earlier work keys on option values throughout.
• An immutable declaration. Compatibility is the publisher's declaration on the question version, fixed at commit (RD-R20); the earlier work kept a mutable draft decision or a boolean.
• The target in the form version. standardTarget and ReconciliationPolicy sit in every form version (RD-R12); the earlier work kept the target on the stage and had no form entity.
• Collaborative drafts. Many drafts per form, append-only changes with base revisions, and presence that is never an audit record (§3.7, RD-R26); the earlier drafts are single mutable records with last-write-wins saves.
• Separate heads and revisions. Sessions are Study × form with deterministic IDs, and versions are stored apart from heads (§3.9); the earlier aggregates embed unbounded version arrays and pin stage versions.
• Generated versions written safely. Per category and prior version, affected sessions only, head compare-and-set, deterministic IDs per (sessionId, operationId, generation), publisher attribution with the reviewer as effective author, and never an invalid Complete (§3.15, RD-R23); the earlier planner has none of these.
• Re-answer and mapping that keep history. requireReanswer keeps pins and shows Needs updating; mapping writes new revisions with provenance and keeps the originals (RD-R21); the earlier code clears answers and rewrites values.
• One publication per form while reviewers keep saving (RD-R25, RD-R35); the earlier code locked review and export per stage.
• System questions as global versioned data, pinned by form versions, with main's exact text at seq 1 (RD-R32); the earlier factory writes per-project copies with edited text.
• repeatable fixed at creation, and no stage owning a target or session (versioning model §3.1 and D2-03; RD-R31).