# SyRF remaining planning decisions

Prepared 4 October 2026. **74 register entries: 52 resolved or removed in this document (50 approved/amended recommendations including scope deferrals, Q-15 replaced by owner clarification, and Q-35 removed as inapplicable); 22 remain for review. Original grouping: 3 + 13 + 15 + 23 + 20.**

## How to use this document

**Faster review:** Use the [condensed remaining decisions](C:/Users/chris/Documents/Codex/2026-10-04/realtime-voice-chat-2/outputs/syrf-condensed-remaining-decisions.md). It maps the 60 pending original entries to 20 owner review packages, 4 carried-forward alignments and 18 workstream-brief/specialist-validation items. This full register retains the original IDs and prior decisions; consolidation alone does not approve any pending item.

Read one batch and identify exceptions by its question ID. For example: “Batch B: approve the recommendations except Q-15; use … instead.” A batch becomes approved only when you explicitly approve it; silence does not approve a recommendation. Multi-part items can be answered in parts.

This is a local discussion document, not an implementation authorization or an edited repository plan. **Implementation remains on hold.** Recommendations are written in plain English and amended where our conversation superseded the source. Entries marked *Alignment check* confirm remaining implications without reopening an agreed direction. The count is of original register entries, not 74 wholly new issues.

## Decisions already fixed for this review

- Forms/sessions remain attached to the project's reviewable Study; one shared session across stages. Form-wide targets and immutable study-specific target overrides remain distinct.
- Explicit Save/Complete creates immutable versions; autosave uses increasing draft versions and base-version checks. Changes travel as diffs. Large forms require virtual scrolling and full-form validation independent of what is visible. The largest project is an acceptance case, not automatically excluded.
- Publication assesses existing work and active reviewers and offers admin-controlled treatment; attributable generated session versions are allowed. Compatibility belongs to immutable question versions. Guided correction records rollback and republication.
- Merge consolidates into one current Study, keeps original immutable history and a manifest, and supports easy audited reversal. A mutable parent holds tombstone/current-version pointers; prior versions remain immutable. The final merge activation is atomic; current evidence queries use the consolidated view.
- Resolve conflicting duplicate candidate/accepted answers in a reconciliation-style view, prefilling agreeing compatible values. Same-reviewer conflicts may be resolved by the authorized merger or delegated to that reviewer; record actor and source versions, count once, and resolve completion status too.
- Unmerge records a new action. Restore original work; later work may be assigned to either restored Study or left only on the historical merged record. Do not erase or automatically copy it to both.
- Candidate changes must surface affected accepted results at the point of change. Reconsideration generates new versions only by explicit choice. Static completed stages stay complete; automatic stages follow configured remaining-work rules.
- Bibliographic values come transparently from one reference unless overridden. Study-version overrides may be selected from references or entered manually; each field records source, actor and time. Source references remain unchanged.
- Ordinary account deletion disables sign-in and retains named attribution to submissions. Terms wording still needs verification; a separate identity-erasure policy is not decided.
- MVP catalogue: one application-wide CAMARADES catalogue, system-permission-controlled administration. Authorized users create directly or share versioned project copies; others can request catalogue publication. Preserve source and actor provenance, without live coupling to project copies.
- Keep the current tester panel. Add missing staging seeds, prefer preserving staging data, allow genuinely justified staging changes, and do not extend that permission to production. Firefox/WebKit and touch coverage are agreed. Statistics staging continues; production date remains provisional.

## Batch navigation

- Batch 0: Finish the current batch — publication and recovery (3 entries)
- Batch 1: Batch B — workflow, publication and stage behaviour (13 entries)
- Batch 2: Batch C — reconciliation, scientific data and reporting (15 entries)
- Batch 3: Batch D3 — user experience and operational integration (23 entries)
- Batch 4: Batch D4 — research methods and additional capabilities (20 entries)

## Batch 0: Finish the current batch — publication and recovery

### D2-10 — May publishing a form briefly pause affected work?

**Recommended answer:** Yes: pause only the affected form, preserve drafts, and let in-flight saves finish safely before the transition. Show active reviewer/reconciler impact to the admin before confirmation and recheck inputs at commit. Show progress for any subsequent work; prevent stale saves or generation of session versions from overwriting newer submissions. Define and test bounded pause and operation limits.

**Context/status:** Updated recommendation. The old document suggests a drain under 90 seconds and a longer-operation limit such as 30 minutes; these are proposals, not verified limits. Its protocol assumed publication generated no session versions, which we rejected. Our chosen publication behaviour requires a revised concurrency protocol.

**Your exception or amendment:** _Not recorded yet._

### D2-11 — May two updates publish to the same form simultaneously?

**Recommended answer:** No. Allow multiple draft updates, but only one active publication operation per form. Before publishing the next, reassess its impact against the state produced by the previous operation.

**Context/status:** Approved by Chris on 4 October 2026: recommendation accepted.

**Your exception or amendment:** None. Multiple drafts are allowed; only one publication operation per form may be active, and the next publication rechecks the resulting state.

### D2-13 — How should canonical review data be recovered after data loss?

**Recommended answer:** Do not directly replace one live project's data with an old backup. Restore a whole-database point-in-time backup into an isolated environment, then perform controlled, manifest-driven recovery. Check evidence links, current pointers, drafts and derived data before reopening writes. Record any genuine history discontinuity and disclose it in exports.

**Context/status:** This is disaster recovery, separate from the guided, immutable merge/unmerge reversal we have already agreed.

**Your exception or amendment:** _Not recorded yet._


## Batch B — workflow, publication and stage behaviour

### Q-20 — What publication warnings and outdated-answer notifications should users receive?

**Recommended answer:** Show the admin affected active work and consequences before publication. When an admin publishes a change affecting an ongoing reviewer session, alert that reviewer, explain the impact, preserve their draft and provide a safe resume/conflict flow. Editing an unpublished design draft alone does not change a reviewer's published form. If a reviewer's own answer change makes another answer need attention, show that warning inside the form; do not also send a separate notification merely reporting their own action. For changes by others, use a deduplicated in-app notice per recipient and cause. Determine notices for publication-generated versions from the agreed impact policy.

**Context/status:** Alignment check. The old recommendation dropped the active-reviewer warning and assumed publication never generated session versions. Both assumptions are superseded; do not approve that older wording. Approved by Chris on 4 October 2026 with the clarified wording; he agrees with the rest of the recommendation.

**Your exception or amendment:** _Not recorded yet._

### Q-27 — What should an incomplete Save or correction do to dependent work?

**Recommended answer:** Calculate reconciliation readiness from current authoritative evidence at query time, or use a cache only if it is guaranteed current for the relevant input versions; stale cached readiness must not authorize work. A new incomplete session does not unlock work requiring completed contributions. An explicit incomplete Save superseding a completed session removes that contribution from current completed qualification; autosaving a draft alone does not. Before committing a change, show the actor which dependent review work is affected and explain how: the relevant input changes, any loss of qualifying contributions or readiness, and which results may need reconsideration. Respect permissions and blinding when presenting those details, and recheck dependency inputs at commit. Notify the authors of affected dependent work after the change with the same concrete explanation appropriate to their access. Do not automatically rewrite, delete or regenerate their work or accepted results; reconsideration requires an explicit action creating new immutable versions. Automatic stage completion follows configured remaining-work rules; statically completed stages stay complete until explicitly reopened.

**Context/status:** Approved by Chris on 4 October 2026 with the clarified incomplete-Save example, current-readiness requirement, precommit actor warning and affected-author notification.

**Your exception or amendment:** Readiness is evaluated on current data; caching is permitted only with current-input guarantees. Warn the changing user before commit and inform affected authors; dependent work is never automatically rewritten.

### Q-34 — May publication map recorded answers to changed options?

**Recommended answer:** Automatically detect option compatibility where possible and use that detection to propose a default compatibility/mapping setting. Show the admin the basis and impact, and always let them explicitly confirm or change that setting. For compatible options whose meaning is unchanged, allow an explicit admin-approved option mapping and write new immutable revisions with mapping provenance, retaining originals. Record the compatibility declaration, exact source/target versions, mapping, actor and time. Compatibility on a committed question version stays immutable; correcting it uses the agreed guided rollback/republication process. Where meanings differ, declare incompatibility and require a new answer; compatibility never bypasses target-type or option validation.

**Context/status:** Approved by Chris on 4 October 2026 with explicit admin compatibility declaration.

**Your exception or amendment:** The admin can explicitly declare compatibility; preserve the declaration and mapping in attributable immutable history, consistent with the existing question-version correction process.

### Q-15 — How do stage filters and step rules determine available review work?

**Recorded answer:** The stage study filter defines its pool, combining clauses about screening outcomes against specified profiles and reconciled answers to annotation questions with AND/OR groups. There is no separate incoming-stage dependency gate or default/advanced cross-stage progression setting. Partitioning, allocation, permissions, availability and step eligibility determine which work is actually offered. Dependencies between steps concern completion of screening, annotation or both; a separate configured exclusion-stop rule determines termination. Evaluate current applicable project-wide evidence: already sufficient forms/profiles require no redundant reviews; a governing collective Exclude can terminate progression before this stage is used. Pool membership is distinct from actual review or release history. Annotation-filter delivery timing remains a separate decision.

**Context/status:** Resolved by Chris's model clarifications on 4 October 2026. The original proposed extra incoming-stage policy and personal/collective cross-stage defaults are superseded for the intended model; reconcile the older owner ledger, access-policy proposal and contracts explicitly. Do not silently reintroduce the removed setting or interpret this as approval of reviewer-dependent pool clauses. The existing within-stage settings remain separately configured. See syrf-stage-filters-and-steps.md.

**Your exception or amendment:** _Not recorded yet._

### Q-24 — How should existing eligibility rules carry into the new step model?

**Recorded answer:** Keep independent annotation steps independent of screening unless an explicit dependency is configured. Existing projects have stages, not steps: inspect actual stage-level configuration/behaviour and present its mapping to new steps in the opt-in migration wizard. Explain behaviour changes and require authorized confirmation; do not invent historical step settings. New combined screening-and-annotation steps default to Stop offering further screening at profile sufficiency, with an explicit Allow option; annotation follows its separate target/dependencies. On access/activity changes, refuse newly disallowed actions while preserving drafts and saved work, subject to configured completion-of-existing-work rules and current permissions. If an admin settings change conflicts with temporary reservations, show exact impact before commit and allow explicit Cancel or Apply anyway. Apply anyway permits releasing affected temporary reservations only, never bypasses authorization, allocation constraints or invalid configuration. Revalidate current impact at commit, apply settings and reservation changes atomically, notify affected reviewers and preserve completed work and recoverable drafts. Keep the form-level enforcement baseline and study-specific effective targets; do not equate the minimum target with an enforced capacity cap. Preserve/map actual excluded-work policy and stage mode explicitly.

**Context/status:** Resolved with Chris's clarifications on 4 October 2026. He confirmed the Stop default/Allow option, located legacy-stage mapping in the opt-in migration wizard, and accepted the explained capacity-conflict Apply anyway scenario. This is planning approval only; implementation and runtime activation remain on hold.

**Your exception or amendment:** _Not recorded yet._

### Q-26 — Should changed screening profiles use the same impact process as changed forms?

**Recorded answer:** Yes. Screening profiles have immutable published versions; changing a profile requires a new version. Before publishing it, compare the proposed version against the exact profile versions associated with existing screening decisions and collective/adjudicated outcomes, including earlier versions still in use. Detect and preview resulting version mismatches and their consequences; the authorized admin explicitly resolves treatment before activation: keep pinned, request new decisions, or compatible carry-forward with attributable immutable versions/history as applicable. Preserve original decisions, outcome history and frozen reports. Apply current collective-outcome evaluation under the chosen policy; do not silently reinterpret older decisions as authored under the new profile. Existing accepted/adjudicated results whose inputs change follow the agreed dependency-impact and explicit reconsideration rules. Show active-work impact and revalidate the publication inputs at commit. Record policy at profile scope, not separately per stage. Requiring new reviews may leave explicitly pending work after publication; agreeing its treatment before publication does not invent completed decisions.

**Context/status:** Approved by Chris on 4 October 2026 with immutable profile versions and pre-publication detection/resolution of version mismatch affecting screening decisions and outcomes. Implementation remains on hold.

**Your exception or amendment:** _Not recorded yet._

### Q-28 — Which visibility, blinding and tracking rules apply when several stages use a shared form?

**Recommended answer:** Reconciliation identity blinding belongs to the annotation form, as Chris decided, alongside its reviewer target and other form-level reconciliation settings. The same blinding choice applies to its shared reconciliation session through every stage; do not derive conflicting identity rules from stage settings. Accepted/reconciled-answer visibility also belongs to the form and defaults to showing reconciled responses; the designer can configure it. A stage step may restrict availability in its step settings by hiding responses the form allows, but cannot reveal responses the form hides. Record exposure without conflating answer visibility with reconciliation identity blinding. Allow completion of already-started saved work after screening exclusion by default, with a step setting that can prevent completion. Preserve drafts either way; permissions and capacity rules still apply. This does not authorize starting new work after exclusion. Enforce the agreed form-level capacity baseline across every route; capacity rules at stages may be stricter. Keep one shared capacity count. The form owns the inactivity timeout and per-reviewer in-progress study limit for that form across all stages. Multiple connections to the same shared session count as one place, extending the existing same-stage multi-tab behavior across stages. Track connections separately; one disconnected or idle tab must not release a place while another connection remains active. When the shared session times out, release its reservation and preserve its draft.

**Context/status:** Fully resolved by Chris on 4 October 2026: reconciliation identity blinding belongs to the annotation form or, for manual screening reconciliation/adjudication, its screening profile; it is consistent across access stages. Blinded candidate response/session presentation order must be unpredictable and must not reveal authorship through name, assignment or submission order. The former most-restrictive-stage reconciliation blinding proposal is superseded. Accepted/reconciled-answer visibility is form-level and defaults to showing reconciled responses, with stage-step overrides permitted only to hide them. Do not reinstate stage-only capacity enforcement. Completion of already-started saved work after screening exclusion is approved by default, with a restrictive step setting and draft preservation. The form owns inactivity timeout and per-reviewer in-progress limits across stages; multiple tabs/routes share one session and place, preserving drafts on timeout. Align related D3-17 and D3-18 with these decisions rather than reopening them.

**Your exception or amendment:** Approved with form-owned settings, restrictive visibility overrides at stage-step level, reconciled-response hints and reviewer-triggered autofill, default saved-work completion after exclusion, and shared-session tracking across tabs and stages.

**Additional owner amendment — reconciled-answer hints and explicit autofill:** Supersedes the earlier automatic-prefilling instruction. Availability of reconciled responses has a form-level baseline, defaulting to showing them. A stage step may override that baseline in its step settings only to make responses unavailable, never to make form-hidden responses available. Both the hint and autofill action follow the effective visibility of the step in use. Where enabled, a question with an applicable reconciled response shows that response as a hint; do not automatically populate the answer control. Explain that it is an existing reconciled response and provide its provenance, including the exact source version through authorized history access, respecting reconciliation identity blinding. Offer a reviewer-triggered action to use/autofill available applicable responses into their own session; do not offer an actionable autofill when no such response is available. Use the agreed question-version compatibility/mapping rules to determine applicability. Preserve reviewer answers and draft edits when displaying hints; any replacement via autofill must be an explicit reviewer choice. Record the reconciled source version and reviewer adoption, so copied values are not represented as independently derived evidence. Showing a hint or choosing autofill does not itself submit or complete the session; explicit Save or Complete follows the agreed immutable session-version rules. Record exposure as appropriate. This supersedes the earlier statement that no visibility override was agreed and the subsequent stage-level wording: the restrictive override is specifically at the stage-step level. Hiding responses through one step does not erase answers already entered or adopted in the shared reviewer session, and cannot undo prior exposure through another step or stage.

### Q-12 — How should the reviewer page present several steps?

**Recommended answer:** Use a step selector/strip with one form area in the existing annotation workspace, rather than several competing cards. Validate it with users before committing to the layout.

**Context/status:** Resolved by Chris on 4 October 2026. Recommended answer approved as already decided and shown in the prototype. Prototype alignment is owner-confirmed; no new prototype inspection or implementation was performed in this conversation.

**Your exception or amendment:** Go with the recommended answer and the existing prototype presentation.

### Q-01 — Should strict collective gating within a stage be available?

**Recorded answer:** Default to allowing progression after the reviewer's own Include decision while the collective result is still pending. Make waiting for a collective Include configurable at the stage level; strict collective gating is off by default. The original proposed tighten-only step override and pilot validation remain in the recommendation; the owner's clarification specifically confirms the default and stage-level configuration. Early progression does not override configured exclusion-stop rules after a collective Exclude. This concerns progression between steps, not a separate incoming stage gate or a change to the stage study filter.

**Context/status:** Resolved by Chris on 4 October 2026. This progression rule uses screening sufficiency and its existing target, but does not change the target. Chris explicitly clarified that proceeding without the collective result means while it is pending, not overriding collective Exclude.

**Your exception or amendment:** Proceed after own Include by default while the collective decision is pending; stage-level configuration can require waiting. Preserve the existing exclusion-stop rules.

### Q-02 — What is the full change flow for completed stages?

**Recommended answer:** Preview effects and approve the specific protected change, then revalidate at commit. Let automatically derived completion respond according to its configured rules; manually completed stages remain completed unless explicitly reopened. Apply this handling when newly imported studies or changed evidence cause additional studies to match the stage study filter and have remaining review work: surface the impact; automatic completion is recalculated, while static/manual completion remains until explicit authorized reopening. Pool membership alone does not imply remaining work.

**Context/status:** Approved by Chris on 4 October 2026 after clarification. Alignment with earlier owner decisions confirmed. Merges change review information and remaining work, not stage status directly. Do not require blanket reopening of static completed stages.

**Your exception or amendment:** Approved: show additional work before confirming an admin change, recheck at commit, recalculate automatic stages, and retain manual completion until explicit reopening.

### Q-30 — What should visibility, blinding and assignment-expiry defaults be?

**Recommended answer:** Reconciled-answer availability defaults to on, as already approved in Q-28, using provenance-labelled hints and explicit reviewer-triggered autofill, with restrictive stage-step overrides. Default reconciliation identity blinding to on, owned by the form or screening profile; use anonymous labels and unpredictable candidate ordering that is stable while working without revealing authorship or chronology. Chris approved blinding by default. Candidate aliases must be scoped to the reconciliation context and assigned independently across Studies; never expose a persistent reviewer pseudonym or predictable identity mapping across Studies. Expiry of explicitly assigned but unstarted reconciliation work is optional, enabled/configured by an authorized admin rather than automatically imposed. Do not enforce the proposed seven-day expiry by default. When enabled, apply the configured duration with audited settings/assignment changes; the exact default placement and duration for an enabled expiry remain implementation/design details, not a mandated seven-day policy. This expiry does not apply to started work or delete submitted evidence.

**Context/status:** Resolved by Chris on 4 October 2026. Reconciled-answer availability defaults to on under Q-28. Reconciliation identity blinding is approved by default, with no reviewer-identifying continuity of aliases across Studies. Unstarted-assignment expiry is optional, not automatically imposed.

**Your exception or amendment:** Show reconciled-response hints by default; default to blinded candidate identities without cross-Study pseudonym continuity; make unstarted-assignment expiry optional rather than enforced.

### Q-33 — What happens to search history and PRISMA when a search is withdrawn?

**Recommended answer:** Keep original citations and append a withdrawal event. Current reporting excludes withdrawn searches as appropriate and explains that choice. Previously frozen reports stay unchanged.

**Context/status:** Approved by Chris on 4 October 2026. Separate from deleting an entire project. Current reports exclude withdrawn searches as appropriate and explain the choice; exact count treatment must account for Studies also identified by other searches. Withdrawal does not silently erase submitted review evidence.

**Your exception or amendment:** Go with the recommended answer.

### Q-37 — Which external-count and deduplication amendments should be adopted?

**Recommended answer:** Adopt the external-step ledger and per-box combination rules: distinguish reported from computed counts, prevent double counting, state permissions and warnings, and handle withdrawn searches. For deduplication, preserve imports, exclude noncurrent records from ordinary admission, include privacy protections, QC sampling and reviewer duplicate flags, and validate algorithm parity.

**Context/status:** Approved by Chris on 4 October 2026 as the amended package presented here. Its old alias-only merge rule is replaced by the owner-approved one consolidated current Study, immutable originals/history, atomic commit, evidence index and guided unmerge. External-count combination, permissions/warnings, withdrawal treatment and deduplication QC/parity requirements are approved in scope. Exact parity metrics/tolerances covered by D4-21 remain that separate register decision; this approval does not select an unstated numeric threshold or reinstate superseded merge/reporting semantics.

**Your exception or amendment:** Approved, consistent with previously recorded owner amendments.


## Batch C — reconciliation, scientific data and reporting

### Q-29 — How do one-reviewer forms reach accepted answers?

**Recorded direction:** Retain the earlier qualifying single-reviewer automatic accepted-result path without requiring a human reconciliation step, compatible with the shared-form model. Create an immutable result version labelled SingleAnnotator with exact candidate-version lineage and system/rule provenance; do not imply human reconciliation or second-reviewer verification. When a new form-settings version changes the annotation-session target, a corresponding new reconciliation/result version can be applied, preserving earlier versions and recording settings/input versions and actor or system rule. Reevaluate sufficiency using the effective target. Raising the target does not fabricate missing contributions or declare the new requirement satisfied. Preserve accepted history and explain current readiness/standing and dependent-work impact.

**Context/status:** Resolved through R1: target-one automatic acceptance or configured human reconciliation, using the same reconciliation mechanism.

**Your exception or amendment:** Chris resolves R1: second-person verification uses the existing reconciliation mechanism with a target of one qualifying candidate annotation session and required human reconciliation, rather than a separate verification workflow/session type. Configure whether a qualifying target-one candidate creates an accepted result automatically (the earlier approved Single annotator behavior) or requires human reconciliation before acceptance. Human reconciliation retains exact candidate inputs, confirms/corrects answers with resolver attribution, and preserves immutable history. Labels may distinguish the authority, but do not invent a separate review engine. Publish the relevant versioned form policy with impact preview; the brief must specify policy precedence and readiness. This does not approve automatic acceptance of multiple candidates solely because they agree.

### Q-35 — How should old reconciled answers with unknown authority be handled?

**Recorded answer:** No legacy reconciled data migration is needed on the owner-confirmed premise that reconciliation has not been fully implemented or used and there are no reconciliation records. Remove this as an owner decision and initial-rollout requirement. Confirm that premise in the migration dry-run; if unexpected records appear, stop that migration case and surface their provenance treatment explicitly rather than fabricate authority.

**Context/status:** Removed as inapplicable following Chris's clarification on 4 October 2026. Earlier reconciliation documentation reports zero such records at its February verification; no fresh live-database verification was performed here.

**Your exception or amendment:** No legacy reconciliation data exists; do not design a required migration lane for hypothetical records.

### Q-36 — What authority and self-reconciliation rules should apply?

**Recommended answer:** No ordinary self-reconciliation by default. Require explicit grants for adjudication overrides. New admissions requiring accepted authority must use current applicable authority; retain saved work and show when revalidation is needed. Keep the separately audited query-review exception distinct.

**Context/status:** Approved by Chris on 4 October 2026 through R2, with configurable screening tie adjudication as a separate step. Preserve earlier owner permissions, provenance and blinding decisions.

**Your exception or amendment:** R2 recommendation approved; a screening profile can route tied decisions to explicit adjudication rather than automatically seek another screening review.

### Q-04 — How complete must accepted answers be, and how are missing comparisons counted?

**Recommended answer:** Default accepted-answer completeness to question requiredness, with a form override and no stage override. Treat an absent comparison as not assessed and report it separately. Explicit Unknown or Not reported values are recorded answers, not missing data.

**Context/status:** Approved by Chris on 4 October 2026 through amended R3. Missing candidate answers do not themselves prohibit reconciliation; ordinary readiness and requiredness still apply.

**Your exception or amendment:** Follow requiredness with a form override and no stage override; report missing comparisons separately. No legacy reconciliation migration is required on the confirmed no-data premise.

### Q-11 — May authorized users bulk-accept studies whose candidates all agree?

**Recommended answer:** Offer an optional per-form setting after the core reconciliation workflow, off by default. Show valid answers and study-level warnings; require an authorized reconciler's explicit final acceptance. Record exact candidate agreement and inputs. Agreement alone must not automatically create accepted answers.

**Context/status:** Approved by Chris on 4 October 2026 through R2, with configurable screening tie adjudication as a separate step. Preserve earlier owner permissions, provenance and blinding decisions.

**Your exception or amendment:** R2 recommendation approved; a screening profile can route tied decisions to explicit adjudication rather than automatically seek another screening review.

### Q-32 — May a screening profile require a rationale for adjudication?

**Recommended answer:** Yes as a profile setting, off by default, for adjudicated screening decisions only. Ordinary reconciled-answer explanations remain optional.

**Context/status:** Approved by Chris on 4 October 2026 through R2, with configurable screening tie adjudication as a separate step. Preserve earlier owner permissions, provenance and blinding decisions.

**Your exception or amendment:** R2 recommendation approved; a screening profile can route tied decisions to explicit adjudication rather than automatically seek another screening review.

### Q-05 — How should existing outcome data migrate?

**Recommended answer:** Use a read-only dry-run, reviewed migration manifest, staged copy, protected project transition and explicit rollback boundary. Do not interpret historic default values as proven answers: false direction, SD, mean or zero counts remain value-or-default unknown unless actual evidence establishes them.

**Context/status:** Resolved by Chris through R4 on 4 October 2026. The universal behavior-preserving baseline conversion direction below governs: opt-in staging/production pilots, then validated conversion of all remaining projects; explicit missing-legacy states and optional later wizard redesign. Detailed mappings/acceptance gates remain to verify before implementation.

**Your exception or amendment:** R4 approved with universal baseline conversion and later in-engine redesign. Preserve provenance, unknown legacy information and established behavior; pilot/limited adoption scopes require complete validated reader/writer coverage.

### Q-06b — Which remaining PRISMA reporting amendments should be adopted?

**Recommended answer:** Keep import-record and report counts distinct; disclose missing exclusion-reason coverage; separate accepted answers from reporting status; preserve time, protocol amendments and frozen reports. Use honest labels where report identity is not available.

**Context/status:** Approved by Chris through E1 on 4 October 2026. Preserve reporting-unit distinctions, supplied-versus-computed previous-review counts, historical coverage disclosures and frozen snapshots; defer the full updated-review workflow.

**Your exception or amendment:** E1 recommendation approved.

### Q-17 — What fields should the event-count outcome schema contain, and what does variation mean?

**Recommended answer:** Obtain a field-level scientific specification from Chris or a CAMARADES methodologist before building that schema. Build catalogue infrastructure and the legacy-compatible schema first if needed.

**Context/status:** A specification is needed; approving a placeholder definition is not enough.

**Your exception or amendment:** _Not recorded yet._

### Q-18 — What should the first experimental-classification reasoner support?

**Recommended answer:** Limit the first version to conjunction, containment, disjointness and exhaustiveness. Defer wider inference capabilities.

**Context/status:** Approved by Chris through S5 on 4 October 2026, including the explained inference scope, permission isolation, pinned accepted evidence, explainable recomputation and reported-answer preservation.

**Your exception or amendment:** S5 recommendation and clarified inference behavior approved.

### Q-19 — Who can publish project rules and shared-concept mappings?

**Recommended answer:** Users with the project Design capability publish rules. Reviewers confirm their applicability to a specific item through mapping answers; normal reconciliation resolves disagreements.

**Context/status:** Approved by Chris through S5 on 4 October 2026, including the explained inference scope, permission isolation, pinned accepted evidence, explainable recomputation and reported-answer preservation.

**Your exception or amendment:** S5 recommendation and clarified inference behavior approved.

### Q-16 — How should agreement be calculated for several reviewers and structured entities?

**Recommended answer:** Start with percent agreement and explicit denominators. Obtain statistical-method review before choosing and shipping multi-reviewer formulas. Retain the already-settled identical-set rule for multiple-choice answers.

**Context/status:** Related to D4-12; accepted answers do not count as an additional independent reviewer.

**Your exception or amendment:** _Not recorded yet._

### Q-22 — Should PRISMA count one exclusion reason or several per excluded study?

**Recommended answer:** Use one primary reason for the MVP. Report reason coverage explicitly when reasons are pending or disabled.

**Context/status:** Approved by Chris through amended S3 on 4 October 2026. Primary reason selection is a configurable default-template/reporting recommendation, not a platform restriction on questions or reasons. Multiple screening annotation questions and explicit profile agreement requirements remain supported. Distinct excluded-Study totals and overlapping reason counts are separate.

**Your exception or amendment:** Approve the template/guidance interpretation, with clear diagram-compatible distinct-Study counts, overlapping reason labels and reason-coverage disclosure.

### Q-23 — How should reports be counted when several imports or documents are involved?

**Recommended answer:** Preserve reference/report identity and distinguish it from citation imports and project review items. Report only supported units with clear labels. Prepare the source links now; defer the full investigation/report grouping workflow, as agreed.

**Context/status:** Updated recommendation. This confirms honest reporting under the reduced scope, not immediate delivery of the previously proposed full report-multiplicity feature.

**Your exception or amendment:** _Not recorded yet._

### Q-21 — What did each legacy project's screening represent when adopting it?

**Recommended answer:** Have an admin review and label a legacy screening compatibility profile during adoption. Do not infer the old scientific protocol from incomplete data.

**Context/status:** Resolved by Chris through R4 on 4 October 2026. The universal behavior-preserving baseline conversion direction below governs: opt-in staging/production pilots, then validated conversion of all remaining projects; explicit missing-legacy states and optional later wizard redesign. Detailed mappings/acceptance gates remain to verify before implementation.

**Your exception or amendment:** R4 approved with universal baseline conversion and later in-engine redesign. Preserve provenance, unknown legacy information and established behavior; pilot/limited adoption scopes require complete validated reader/writer coverage.


## Batch D3 — user experience and operational integration

### D3-01 — How should new screens align with the Material 3 visual rollout?

**Recommended answer:** Use Material 3 roles consistently over the current components, register new routes for visual baselines, and coordinate the shared theme cutover before the new reviewer UI where possible. Validate notification screens before exposure and dark-mode behaviour on staging.

**Context/status:** A design consistency requirement, not authorization to enable a feature.

**Your exception or amendment:** _Not recorded yet._

### D3-02 — How often should design acceptance happen?

**Recommended answer:** Review one integrated staging build per release. Use individual PR previews for new shared patterns and high-risk screens: publication, reconciliation, stage designer, Members and groups, and guided setup. Run routine design checks on each PR.

**Context/status:** Still open.

**Your exception or amendment:** _Not recorded yet._

### D3-03 — What labels should users see for saving, completion and answer state?

**Recommended answer:** Use Save progress, Complete, Needs updating, Outdated answers, Fix, Accepted answers (gold standard), and Screening result. Distinguish autosaved draft changes from explicit saved submissions with clear status text, proposed as Changes kept, not yet saved. Avoid Save draft as the explicit submission label.

**Context/status:** Approved by Chris through U1 on 4 October 2026 with the draft/checkpoint wording amendment. Draft auto-saved denotes recoverable draft changes; explicit Save progress creates an immutable session checkpoint, shown as Version checkpoint saved. Complete remains distinct. Sentence case and the other recommended labels are accepted.

**Your exception or amendment:** Use Draft auto-saved and Version checkpoint saved, rather than Autosaved—not yet submitted / Changes kept, not yet saved; otherwise accept U1.

### D3-04 — How should buttons and typography be written?

**Recommended answer:** Use consistent Material 3 sentence case across reviewer screens. Re-audit older all-caps button specifications before applying them to new work.

**Context/status:** Approved by Chris through U1 on 4 October 2026 with the draft/checkpoint wording amendment. Draft auto-saved denotes recoverable draft changes; explicit Save progress creates an immutable session checkpoint, shown as Version checkpoint saved. Complete remains distinct. Sentence case and the other recommended labels are accepted.

**Your exception or amendment:** Use Draft auto-saved and Version checkpoint saved, rather than Autosaved—not yet submitted / Changes kept, not yet saved; otherwise accept U1.

### D3-05 — Which work should be supported on phones?

**Recorded answer:** Support the full annotation experience at launch on phones, tablets and desktops, as well as screening. Do not limit annotation to tablets/desktops or remove controls/features solely on phones. Responsive presentation may differ while preserving functionality, draft/save/complete behavior, validation and access rules.

**Context/status:** Resolved by Chris through the U2 device-scope amendment on 4 October 2026. Phone annotation is a launch acceptance requirement, including large/structured forms, touch controls and accessibility. Performance and usability evidence must cover the supported device matrix.

**Your exception or amendment:** Full annotation support on phones, tablets and desktops at launch.

### D3-06 — Should legacy screens receive the visual refresh?

**Recommended answer:** Restyle shared navigation and pages consistently under the visual-refresh programme without changing their behaviour, so legacy and adopted projects do not appear to be unrelated applications.

**Context/status:** Approved through the U2 legacy-screen clarification.

**Your exception or amendment:** Approved by Chris: apply the refreshed visual design and as many compatible new features as possible to existing/legacy project screens, without changing review-workflow behavior. Shared navigation, usability and compatible supporting features can be improved; progression, screening, annotation, eligibility and other protocol/workflow semantics must remain faithful until an explicit migration or later configuration change is confirmed. Assess compatibility and behavior parity in the brief. This is planning approval only; implementation remains on hold.

### D3-07 — How should users find everything they need to do?

**Recommended answer:** Provide a project My work view listing actionable items by role, a cross-project tab and global badge. Counts work even when notifications are disabled. Show admins pending stage-change approvals. Defer a full global landing page until later.

**Context/status:** Approved by Chris through U3 on 4 October 2026 with the recommended answer.

**Your exception or amendment:** Approved without amendment.

### D3-08 — Who should take part in user testing, and what pilot telemetry is appropriate?

**Recommended answer:** Use the current agreed tester panel; no additional external recruitment is required now. Separately, recommend consent-based pilot timing events, such as opening to completion, without collecting answer content.

**Context/status:** Approved by Chris through U3 on 4 October 2026 with the recommended answer.

**Your exception or amendment:** Approved without amendment.

### D3-09 — How should the rollout handle the paused eligibility programme?

**Recommended answer:** Have the new workflow release take responsibility for the browser eligibility integration and required paused slices if the programme remains paused. A disabled stage blocks its own route only; keep excluded-work visibility separate; permit authorized early reconciliation with a warning; use versioned withdrawal and preserve claim release.

**Context/status:** Coordinate ownership rather than duplicate implementations.

**Your exception or amendment:** _Not recorded yet._

### D3-10 — How should live statistics support publication and pilots?

**Recommended answer:** Accept a pinned authoritative statistics read at the publication boundary as current evidence when its source identity is recorded. Protect the existing statistics pilot project from overlapping pilots until the integration check passes. Serve multi-profile pilot statistics at the right profile granularity. Exempt preview pilots from the strict production materialization dependency, while retaining truthful authoritative counts.

**Context/status:** Production readiness remains provisional under our earlier statistics decision.

**Your exception or amendment:** _Not recorded yet._

### D3-11 — Where should reviewer-agreement statistics be stored?

**Recommended answer:** Use a separate rebuildable derived store with a source watermark and explicit performance budget; do not put agreement formulas into the existing project-progress statistics family.

**Context/status:** Still open.

**Your exception or amendment:** _Not recorded yet._

### D3-12 — How should search withdrawal differ from deleting a project?

**Recommended answer:** Withdrawal hides the affected current items while preserving citations and review history. Decide whole-project deletion separately under the existing reversible-deletion policy, including its tombstone and eventual physical cleanup rules.

**Context/status:** Resolved: reversible project deletion approved; physical erasure remains a separate unapproved policy.

**Your exception or amendment:** Approved by Chris: ordinary whole-project deletion is reversible removal from normal use. Hide the project from ordinary lists; block review and editing; stop new allocations and project notifications; release active review reservations while preserving drafts and immutable evidence/history. Retain the data for restoration through a restricted deleted-projects view by an authorized admin. Record deletion and restoration actor, time and reason; alert affected active users consistently with the approved impact rules and prevent stale saves from bypassing deletion. Restoration re-evaluates availability and capacity rather than reviving stale reservations. Permanent physical erasure is a distinct policy and is not authorized by ordinary deletion.

### D3-13 — How should allocation and progressive batches integrate?

**Recommended answer:** Initially defer proportional allocation until its new shared-form contract is ready. Count sufficiently excluded items as finished while retaining them in a batch's denominator. Provide pool-level Who is offered what counts before the fuller authority resolver. Record first release to anyone as entry to screening, distinguishing shared openings from individual grants. Deliver completion/progression and durable openings before selection integration, with a performance gate.

**Context/status:** Update the original extra-review bypass clause: our request raises the effective target for the specific Study and form, can assign a group/person, and counts across all routes. Do not reinstate an invisible bypass that leaves the effective target unchanged.

**Your exception or amendment:** _Not recorded yet._

### D3-16 — How should reviewer capacity protection be enabled in production?

**Recommended answer:** Enable through admitted pilot-project scope first, with the shared-form claim contract and appropriate opt-in for legacy projects. Do not silently enable fleet-wide. Coordinate the statistics mode transition and load validation before production rollout.

**Context/status:** The documents' deployment observations are historical; verify actual state when executing.

**Your exception or amendment:** _Not recorded yet._

### D3-17 — Should the maximum simultaneous reviewers be separate from the minimum reviewer target?

**Recommended answer:** Yes, model a capacity cap separately from the evidence target. Make optional cap defaults explicit, never evict existing work, and respect authorized study-specific target changes. Enforce the form's baseline through every stage; stricter route policies may apply.

**Context/status:** Updated to our form-level baseline. Off-by-default and defaulting an enabled cap to the target remain recommendations to confirm.

**Your exception or amendment:** _Not recorded yet._

### D3-18 — How should differing tracking and timeout settings work across shared-form routes?

**Recommended answer:** Use one shared session/capacity count and the agreed form-level enforcement baseline. Bound stages must meet it or be stricter. Recommend the most restrictive applicable idle timeout; let route-specific in-progress limits govern that route without counting the same session twice.

**Context/status:** Remaining defaults and interaction rules need confirmation; the stage-only baseline is superseded.

**Your exception or amendment:** _Not recorded yet._

### D3-19 — When should screening reserve a place on a dependent annotation form?

**Recommended answer:** Do not hold an annotation slot while screening is still underway. Claim it on Include. If capacity is unavailable, explain that enough reviewers are already working and retain the screening decision.

**Context/status:** Still open.

**Your exception or amendment:** _Not recorded yet._

### D3-20 — Who may see the identities of currently active reviewers?

**Recommended answer:** Ordinary reviewers see counts and their own place. Reveal names only with the Monitor capability, and never defeat reconciliation identity blinding.

**Context/status:** Active-work warnings are already required; this confirms disclosure permissions.

**Your exception or amendment:** _Not recorded yet._

### D3-21 — How should notifications be enabled?

**Recommended answer:** Admit pilot projects first. Enable more broadly only after pilot exit review. Use separately approved environment/kind-family gates; keep test email in the test sink and provide an operator delivery pause before production email.

**Context/status:** Notification branch coordination is approved; enabling notifications is not.

**Your exception or amendment:** _Not recorded yet._

### D3-22 — What may notification emails and digests contain?

**Recommended answer:** Emails and digests may include useful project and study context, including study titles. Reviewer aliases and other content must respect recipient permissions and configured blinding; answers and free text are configurable rather than universally omitted. Check authorization and blinding when preparing delivery. Email copies cannot be recalled by later access removal.

**Context/status:** Approved through O2 on 4 October 2026.

**Your exception or amendment:** Emails and digests may include useful project and study context, including study titles. Reviewer aliases and other content must respect recipient permissions and configured blinding; answers and free text are configurable rather than universally omitted. Check authorization and blinding when preparing delivery. Email copies cannot be recalled by later access removal.

### D3-23 — Should related notices resolve automatically when the underlying work is resolved?

**Recommended answer:** Yes. Mark related notices resolved and remove them from unread counts while retaining their history.

**Context/status:** Still open.

**Your exception or amendment:** _Not recorded yet._

### D3-24 — May users mute email for one project?

**Recommended answer:** Yes. Provide per-project email mute before production email, while continuing to record in-app inbox items.

**Context/status:** Approved through O2 on 4 October 2026.

**Your exception or amendment:** Approved with the recommendation.

### D3-25 — How should reconciliation conversations be retained and exported?

**Recommended answer:** Retain them as project audit records while the project exists. Export only with the appropriate audit/export permission and identity-disclosure policy. Exclude conversation text from candidate-answer exports and agreement statistics; retain relevant exposure markers.

**Context/status:** Approved through O2 on 4 October 2026.

**Your exception or amendment:** Approved with the recommendation.


## Batch D4 — research methods and additional capabilities

### D4-01 — Should title/abstract screening offer Unsure?

**Recommended answer:** Provide a per-profile option, on by default in the title/abstract template. Treat Unsure like Include for availability; configure its collective treatment. Count it as not excluded in PRISMA, and show agreement both with Unsure separate and appropriately collapsed.

**Context/status:** Approved by Chris on 4 October 2026 through S1. Unsure is configurable per profile, on in the title/abstract template, treated as not excluded for availability, with explicit collective handling and transparent reporting.

**Your exception or amendment:** Go with the S1 recommendation.

### D4-02 — May candidates resolve a screening conflict through discussion?

**Recommended answer:** Offer a per-profile discussion route, off by default. Let the relevant candidates see each other's decisions/reasons after conflict, record that exposure, and allow versioned corrections. Calculate independent agreement from their initial observations.

**Context/status:** Approved by Chris on 4 October 2026 through S2. Discussion invitations follow submitted candidate decisions revealing a conflict when enabled in the profile; preserve originals, record exposure and version corrections. Independent agreement uses pre-exposure initial observations. The configured bounded extra-review/adjudication path handles disabled or unresolved discussion.

**Your exception or amendment:** S2 approved with the clarified discussion-start timing and immutable decision/exposure history.

### D4-03 — Should single-reviewer extraction support a second reviewer verifying it?

**Recommended answer:** Yes: a verification step where the second reviewer confirms or changes the extraction, with exposure recorded. Its accepted result has Verified authority and is labelled distinctly in exports and the methods summary.

**Context/status:** Resolved through R1: target-one automatic acceptance or configured human reconciliation, using the same reconciliation mechanism.

**Your exception or amendment:** Chris resolves R1: second-person verification uses the existing reconciliation mechanism with a target of one qualifying candidate annotation session and required human reconciliation, rather than a separate verification workflow/session type. Configure whether a qualifying target-one candidate creates an accepted result automatically (the earlier approved Single annotator behavior) or requires human reconciliation before acceptance. Human reconciliation retains exact candidate inputs, confirms/corrects answers with resolver attribution, and preserves immutable history. Labels may distinguish the authority, but do not invent a separate review engine. Publish the relevant versioned form policy with impact preview; the brief must specify policy precedence and readiness. This does not approve automatic acceptance of multiple candidates solely because they agree.

### D4-04 — Should calibration or training rounds be supported now?

**Recommended answer:** Model a separate training/calibration step with live agreement feedback, excluded from live votes, reviewer targets and PRISMA. Recommend delivering it with stage lifecycle work; if deferred, retain the admission hook now. Promotion to live evidence requires an explicit admin action.

**Context/status:** Approved by Chris through expanded S4 on 4 October 2026. Training is an important requested capability, including admin-set reference answers, scoring, manual evaluation and optional rule-based admission to a project group. The earlier defer-to-hook-only fallback is not sufficient without separate owner scope agreement.

**Your exception or amendment:** Include the expanded training/evaluation/group-admission workflow below.

### D4-05 — What protocol, registration and search documentation should be recorded?

**Recommended answer:** Capture search date, platform, strategy, limits and round. Add protocol/registration information with an append-only amendment log. Changing eligibility through a screening-profile publication should require an amendment entry.

**Context/status:** Approved by Chris through E2 on 4 October 2026. Search/protocol metadata, append-only amendments and explicit full-text retrieval actions with actor/time/reasons are approved. PDF attachment alone does not silently confirm retrieval.

**Your exception or amendment:** E2 recommendation approved.

### D4-06 — Which risk-of-bias and reporting-quality templates should be curated?

**Recommended answer:** Include SYRCLE, with outcome-specific items bound to the relevant assessment; the CAMARADES checklist; and ARRIVE Essential 10. Have CAMARADES methodologists curate them in the agreed permission-controlled catalogue.

**Context/status:** Catalogue governance is settled; scientific template content remains to approve.

**Your exception or amendment:** _Not recorded yet._

### D4-07 — How should full-text retrieval be tracked?

**Recommended answer:** Use explicit Sought, Retrieved and Not retrieved actions with actor, time and reasons. Authorized admins and stage-granted reviewers can record them. Attaching a PDF suggests Retrieved but does not silently confirm it. Retrieval status is separate from study lifecycle.

**Context/status:** Approved by Chris through E2 on 4 October 2026. Search/protocol metadata, append-only amendments and explicit full-text retrieval actions with actor/time/reasons are approved. PDF attachment alone does not silently confirm retrieval.

**Your exception or amendment:** E2 recommendation approved.

### D4-08 — Should different reports of one investigation be linked in this rollout?

**Recommended answer:** Prepare source-document links capable of supporting multiple references per project Study, but defer the full interface and scientific workflow for grouping distinct papers into one investigation. Keep forms, sessions and targets on the project Study model. Label reporting units honestly.

**Context/status:** Alignment check: this replaces the original recommendation to ship full report-linking now. Duplicate imports of the same document remain in scope.

**Your exception or amendment:** _Not recorded yet._

### D4-09 — Which new exports should be provided?

**Recommended answer:** Add a comparison-level analysis-ready export for external meta-analysis tools, a machine-readable codebook, and RIS export for a selected set. Do not compute effect sizes inside SyRF as part of this lane.

**Context/status:** Approved by Chris through E3 on 4 October 2026. Analysis-ready exports/codebook/selected RIS, estimated-from-graph provenance, deferred digitisation and later external answer imports follow the presented recommendation with source/authority/independence safeguards.

**Your exception or amendment:** E3 recommendation approved.

### D4-10 — What should be done about values estimated from graphs?

**Recommended answer:** Provide an estimated-from-graph provenance flag in the first outcome-data release. Decide whether to build graph digitisation after pilots establish its frequency and importance.

**Context/status:** Approved by Chris through E3 on 4 October 2026. Analysis-ready exports/codebook/selected RIS, estimated-from-graph provenance, deferred digitisation and later external answer imports follow the presented recommendation with source/authority/independence safeguards.

**Your exception or amendment:** E3 recommendation approved.

### D4-11 — How should an updated review's previous-version PRISMA box be supported?

**Recommended answer:** Populate it from explicitly reported previous-review counts in the external-step ledger and select the updated-review diagram template. Defer a full updated-review workflow.

**Context/status:** Approved by Chris through E1 on 4 October 2026. Preserve reporting-unit distinctions, supplied-versus-computed previous-review counts, historical coverage disclosures and frozen snapshots; defer the full updated-review workflow.

**Your exception or amendment:** E1 recommendation approved.

### D4-12 — Which observations and formulas should agreement reports use?

**Recommended answer:** Use initial independent observations by default and report screening agreement per profile. For rotating/multiple raters, obtain statistical review of pooled pairwise kappa or Krippendorff's alpha before shipping. Always show percent agreement and prevalence.

**Context/status:** Related to Q-16. Do not count a reconciled result as an extra independent observation.

**Your exception or amendment:** _Not recorded yet._

### D4-13 — How should the primary exclusion reason be selected?

**Recommended answer:** Default to the first failing criterion in the profile's configured order, with a per-profile override allowing reviewer choice.

**Context/status:** Approved by Chris through amended S3 on 4 October 2026. Primary reason selection is a configurable default-template/reporting recommendation, not a platform restriction on questions or reasons. Multiple screening annotation questions and explicit profile agreement requirements remain supported. Distinct excluded-Study totals and overlapping reason counts are separate.

**Your exception or amendment:** Approve the template/guidance interpretation, with clear diagram-compatible distinct-Study counts, overlapping reason labels and reason-coverage disclosure.

### D4-14 — Should answers from other tools be importable?

**Recommended answer:** Add a separate lane after the first review-engine release. Keep import provenance, exclude imported observations from independence statistics, count them toward reviewer targets only when mapped to a SyRF reviewer, and never automatically make them accepted answers.

**Context/status:** Approved by Chris through E3 on 4 October 2026. Analysis-ready exports/codebook/selected RIS, estimated-from-graph provenance, deferred digitisation and later external answer imports follow the presented recommendation with source/authority/independence safeguards.

**Your exception or amendment:** E3 recommendation approved.

### D4-15 — Should accepted answer values route items to later work?

**Recommended answer:** Add a later lane after core reconciliation, expressed as explicit step-dependency rules on accepted values. Do not make it a requirement for general availability.

**Context/status:** Resolved by Chris through E4 on 4 October 2026: optional accepted-answer-based branching between individual steps is outside MVP scope. Existing approved reconciled-answer clauses in stage study filters remain in scope. Do not introduce another stage-entry gate.

**Your exception or amendment:** Defer optional within-stage accepted-answer conditional branching beyond the MVP; no delivery commitment until a future brief is approved.

### D4-16 — May existing projects adopt screening profiles before full adoption is ready?

**Recommended answer:** Allow admin-initiated adoption for screening-only, unreconciled stages after the richer screening-profile release. Keep it reversible until the first new-engine write.

**Context/status:** Resolved by Chris through R4 on 4 October 2026. The universal behavior-preserving baseline conversion direction below governs: opt-in staging/production pilots, then validated conversion of all remaining projects; explicit missing-legacy states and optional later wizard redesign. Detailed mappings/acceptance gates remain to verify before implementation.

**Your exception or amendment:** R4 approved with universal baseline conversion and later in-engine redesign. Preserve provenance, unknown legacy information and established behavior; pilot/limited adoption scopes require complete validated reader/writer coverage.

### D4-17 — Should outdated answers block completion or require formal acknowledgement?

**Recommended answer:** Use a non-blocking warning with Complete anyway rather than multiple project enforcement levels. Preserve exposure and provenance; ordinary form validation still applies.

**Context/status:** Approved with configurable handling through O3 on 4 October 2026.

**Your exception or amendment:** Approved with amendment: an authorized project designer/admin can configure whether an outdated-answer warning allows Complete anyway or blocks completion until the flagged answers are addressed. Retain the recommended warning-only behavior as the default. Neither mode bypasses current validation, applicability, permissions or mandatory publication/re-review requirements. Preserve drafts and record the policy and evidence versions used. The detailed brief must specify configuration ownership consistently with shared sessions; no stage-entry gate is introduced.

### D4-19 — How should blinding and random allocation behave?

**Recommended answer:** Default candidates to independent/blinded work, with stable alias presentation and audited disclosure exceptions. Serve randomly by default; explicit assignment is an audited exception.

**Context/status:** Resolved through O4 with optional stage-specific reviewer study-pool browsing, dynamic availability and blinding amendments.

**Your exception or amendment:** Use the owner pool, browsing and blinding clarifications recorded below.

### D4-20 — Do contributions remain valid after a member loses access?

**Recommended answer:** Yes: disabling sign-in or membership does not remove completed work from counts or reconciliation. Allow a separate audited authorized action to exclude contributions from a specific form.

**Context/status:** Approved with the O1 admin-controlled contribution-exclusion amendment on 4 October 2026.

**Your exception or amendment:** Authorized project admins may explicitly exclude a member's contributions from current use for a selected annotation form, screening profile, stage or the whole project, including from the membership-disable workflow. Disabling membership alone preserves contributions; exclusion is an explicit choice with impact preview, reason, actor and time. Submitted versions and named attribution remain immutable and accessible in history. Reviewers cannot unilaterally withdraw their submitted contributions by leaving or disabling their account; communicate this in project joining terms. Stage-scoped exclusion must identify contributions by recorded provenance, not assume shared sessions belong to a stage; preview effects across all routes and dependent results. Existing dependent results remain intact, with affected authors informed and new result versions created only through an explicit decision. Whole-project deletion remains a distinct policy.

### D4-21 — What evidence should establish duplicate-algorithm parity?

**Recommended answer:** Compare with pinned ASySD package outputs: identical automatically confirmed groups and probable-pair-set F1 at least 0.99, plus published sensitivity/specificity checks on labelled datasets. Benchmark eighty thousand citations in under an hour on the agreed host.

**Context/status:** Specific metric and performance target remain recommendations, not completed validation.

**Your exception or amendment:** _Not recorded yet._

## Additional agreed requirement — collaborative question-management drafts

Recorded 4 October 2026; supplements D2-11 without increasing the original-register question count.

- Presence on question-management/design pages shows which authorized project users are viewing and which are editing, using names/avatars or equivalent clear indicators.
- Server-accepted draft changes are reflected automatically across other authorized views and sessions of the affected project design pages, subject to their permissions.
- Incoming updates preserve local unsaved edits. Base-version checks prevent silent overwrite; conflicting edits remain recoverable and are clearly surfaced.
- Each accepted change records its actor, timestamp and relevant source/base revision. Versioned publications and their history retain the same attribution. Presence is not a substitute for an audit record.
- Collaborative editing of drafts does not permit simultaneous publication operations for one form or automatically alter published reviewer-facing requirements.
## Additional agreed requirement — reconciliation blinding and candidate ordering

Recorded 4 October 2026; supplements Q-28 and Q-30 without changing the original-register count.

- Annotation-form reconciliation identity blinding is configured on the form. Manual reconciliation of screening decisions or screening annotations uses the corresponding screening profile's blinding setting, rather than conflicting stage-owned settings.
- When blinding is enabled, candidate response/session ordering must be unpredictable and must not follow reviewer names, membership order, allocation order or submission time. Use a randomized presentation mapping without a recognizable persistent reviewer position across studies. Blinded aliases and ordinary visible metadata must not defeat the intended concealment through an obvious mapping.
- Keep exact source identities/versions in protected provenance for audit and authorized disclosure; random presentation does not alter attribution or independence accounting.
- UX recommendation to validate: keep the chosen presentation mapping stable during an active reconciliation so answers do not move while being compared. Stability within a session must not become a predictable author mapping across sessions.

## Sources and limits

Adapted from the [integrated plan's open questions and assumptions](https://github.com/camaradesuk/syrf/blob/main/docs/planning/integrated-review-plan-2026-10/open-questions-and-assumptions.md), the [PRISMA amendments](https://github.com/camaradesuk/syrf/blob/main/docs/planning/integrated-review-plan-2026-10/prisma-amendments.md), and decisions in this conversation. Original register IDs are retained for reconciliation into the repository planning documents later. Repository documents have not been amended by creating this file.

The earlier source contains superseded recommendations, particularly alias-only merges, publication without generated evidence versions, anonymized attribution on ordinary account deletion, stage-only capacity settings, and immediate full report-linking. This document identifies those differences instead of asking you to approve the outdated wording. Performance limits, scientific formulas and operational protocols remain proposals until validated. No external actions, PR changes or implementation are authorized by this document.











## Additional owner decision — finishing existing work after leaving a stage study pool

Chris approved on 4 October 2026: allow already-started review work to finish by default after any filter-driven departure from a stage study pool, not only screening exclusion. An authorized admin can configure a restriction that prevents this continuation/completion. Preserve drafts and immutable submitted evidence, keep permissions and capacity checks, warn the actor about effects on active reviewers before changing the setting, and alert affected reviewers. Finishing existing work does not restore pool membership or authorize new work. Record the setting changes and their actors in audit history. Exact placement of the general pool-exit setting remains to be specified. See the stage-filters-and-steps clarification for the proposed commit/evidence/membership consistency model; this additional decision is outside the original register count.

## Agreed addition — targeted pool-membership history

Chris approved on 4 October 2026: retain query-time calculation of current stage study pools, and add targeted historical transition tracking. This supersedes the interim recommendation to omit continuous membership history. Implementation remains on hold.

- When a current resolved screening outcome or reconciled annotation answer changes, identify stage study filters that depend on the changed profile or question. Reevaluate the affected Study against those filters; do not reevaluate unrelated filters or trigger this solely for ordinary draft saves. Evaluate the complete filter, including its AND/OR groups, rather than only the changed clause.
- A filter configuration change must evaluate the potentially affected project studies against its old and new versions; dependency changes must not omit studies entering the pool. Changes to any other inputs supported by filter clauses must likewise trigger their dependent filters.
- Append immutable entry/departure events for actual changes of membership, with stage, Study, exact filter and evidence versions, cause and actor attribution where applicable. Retain sufficient versioned evidence to reproduce the before/after evaluation. Evidence remains valid when a Study leaves a pool.
- Attribute effective transitions to the causal change becoming current, separately from when asynchronous processing records the event. Preserve event order and process retries without duplicates. The precise atomicity/batching protocol, initial-history baseline and performance acceptance criteria still require specification and validation; do not claim that implementation exists.
- Current access queries use authoritative current inputs or a verified-current cache, rather than trusting delayed history tracking. Historical events explain past membership; they are not a second conflicting source of current truth.
- Record eligibility at review start separately, including filter/evidence versions and reviewer-specific allocation/access rules. Pool membership alone does not show why a particular reviewer was offered work.
- Allow already-started work to finish after departure by default, subject to the agreed configurable admin restriction, permissions and capacity checks. Preserve drafts and explain effects to active reviewers.

These additions are outside the original question-register count.

## Owner goal — explain review activity and inactivity over time

Chris clarified that the purpose of eligibility history is an admin-facing explanation of why a Study was reviewed, why it was not reviewed, and why review was legitimate at the time even if the Study is currently ineligible. The UI must prevent apparent inconsistencies from being mistaken for platform errors. This is an agreed product goal, not approval to start implementation.

Combine the following in a permission-aware Study audit timeline and eligibility explanation:

- Historical pool entries/departures and their causal filter/evidence versions, with effective times.
- Actual review-start and submission events, the route used, and the eligibility justification recorded at the time.
- Relevant recorded changes in allocation, partitioning, availability, capacity, step dependencies, sufficiency, exclusion-stop rules and admin configuration, when they explain a change in work eligibility.
- Current reason categories such as outside pool, already sufficiently reviewed, progression terminated by exclusion, awaiting prior-step work, or unavailable to this reviewer under allocation/permissions/capacity. Pool membership alone does not establish that work was available.
- An explicit explanation when already-started work was completed after pool departure under the configured continuation exception.

Historical explanations must use historical versions, not substitute current settings. Distinguish a recorded reason that work was blocked from an absence of review activity: when a Study was eligible but nobody reviewed it, say that no review is recorded and do not invent a causal reason. Historical availability reasons can be reconstructed only where the necessary inputs were retained; show coverage gaps honestly. Avoid logging every page query as a state transition. Exact retention, timeline coverage, reason representation and consistency/performance mechanisms remain design details to specify and validate.

## Owner requirement — historical pool coverage for flow diagrams

Chris requires flow/PRISMA reporting to identify all Studies that have ever matched each stage study pool during the reporting period, not only its current query result, and to explain why Studies subsequently left that pool. This is a product requirement; the mapping to specific PRISMA boxes and counting conventions still needs explicit design.

- Retain an initial membership baseline and all subsequent entries/departures, including changes before anyone starts reviewing. A review-start log alone cannot establish all Studies that were ever in the pool. Baseline capture and filter-change scans must be complete and tied to exact input revisions.
- Departure records retain the filter clauses and causal evidence/configuration changes. Distinguish a screening Exclude outcome from failing another filter clause, filter reconfiguration, withdrawal, merge/unmerge or other changes to the current reviewable Study identity. Do not label every departure a screening exclusion.
- Record repeated entry/departure episodes, but do not count re-entry as another unique Study. Keep pool membership separate from actual screening/annotation/reconciliation activity and reviewer-specific access.
- Support reporting-period and as-of views with immutable frozen report snapshots. Later changes do not rewrite a previously frozen diagram. If tracking was introduced after the project began, disclose historical coverage limitations rather than claiming an exhaustive pre-baseline history.
- Preserve merge/unmerge lineage so reporting can explain consolidation without silently counting historical tombstoned originals as additional current studies. Exact distinct-identity counting and PRISMA box mappings need reconciliation with the agreed merge model and existing reporting plan before design freeze.

Implementation remains on hold.

### Owner clarification — reporting priority is actual review through the pool

Chris clarified the preceding requirement: for flow/PRISMA reporting, the principal concern is identifying Studies that entered the stage pool and were actually reviewed through that stage, together with the historical justification for their availability and review. Exact departure timing is less important for that reporting purpose, but entry/departure history should still be retained for audit. This supersedes any implication above that all-ever-in-pool membership or departure timing should automatically be used as the diagram's reviewed count.

Keep distinct datasets/measures for ever matching the pool and actual review activity through the stage, connected by exact eligibility provenance. Applicable evidence collected elsewhere may satisfy a stage without any review through that stage: do not invent a stage-specific review event or count it as newly reviewed there. Diagram mappings remain to be specified, with historical attribution, distinct Study counting and frozen snapshots preserved.

### Explicit entry justification

Chris additionally confirmed that each recorded entry into a stage study pool must explain why the Study became eligible for that pool: the effective time, exact filter version, satisfied clause/group evaluation, supporting input versions and the causal change (for example, import, a current screening outcome, reconciled answer or filter edit), with actor attribution where applicable. Record this independently of subsequent review activity. Initial baseline members should carry their matching-filter justification; do not invent an earlier entry time or causal event where historical coverage is unavailable. This records filter-based pool eligibility, separately from permission/allocation/capacity eligibility to review.

### Structured, queryable event records

Chris requires the audit/eligibility/activity events to be well structured and easily queryable for multiple purposes, not stored only as free-text messages. Define versioned event schemas with consistent project, Study, stage/step where relevant, event type, actor, effective time and recorded time, causal operation, source/evidence/filter versions, before/after state, machine-readable reason codes and structured clause evaluation details. Optional explanatory text supplements these fields rather than replacing them. Distinguish pool transitions, reviewer eligibility, review activity and configuration changes.

Preserve immutable events and their original schema versions; use query projections/indexes for study timelines, stage histories, reporting periods and reason-based analysis without changing source history. Maintain traceable causal links, deduplicated retry handling and deterministic order where timestamps alone cannot order changes. Select concrete storage/indexing/retention mechanisms against expected volume and validated query needs; this requirement does not mandate a full event-sourced application. Access control and blinding apply to event queries and displayed provenance. Implementation remains on hold.

### Required event-query examples

Chris explicitly requires stage identity and event type as structured, queryable fields. Acceptance queries must return all distinct Studies that entered a specified stage study pool and all distinct Studies that exited it, with optional reporting-period filters and access to each underlying transition episode and its reason. Repeated entry/exit events remain accessible without duplicating Studies in a distinct-Study result. These queries concern pool membership, not studies physically belonging to or moving between stages; actual review activity remains separately queryable.

### Owner decision — no cross-study identity continuity in blinded reconciliation

Chris approved reconciliation identity blinding by default. Anonymous candidate labels must not consistently identify the same reviewer from one Study to another. Scope alias mappings to the reconciliation context and assign them independently across Studies, alongside unpredictable candidate ordering and concealment of identifying chronology. Merely renaming a persistent reviewer identifier does not meet this requirement. Local anonymous labels may remain stable while the reconciler works to avoid confusion, but their mapping must not carry reviewer identity across Studies. Retain real attribution in protected audit history. Apply the same requirement to annotation-form and screening-profile reconciliation. This settles Q-30's blinding default; the subsequent owner decision makes assignment expiry optional and resolves the remaining part.

## Owner amendment — the standard reviewer target versions the form

Chris clarified that the standard target number of annotation sessions is a fundamental aspect of the form. Changing that target therefore creates a new immutable form version, even when the questions are unchanged. This supersedes the earlier settings-only treatment of standard form target changes. Draft edits remain draft edits until the new version is published.

Apply the agreed publication impact process: identify affected existing sessions/results and active reviewers, explain changes to sufficiency and authority, confirm treatment, and recheck at activation. Sessions and reconciliation/result versions retain exact form/target versions and source lineage. Applying a new target may generate a corresponding new result version under the agreed authority rules; it never rewrites old results, invents missing reviews or automatically invalidates recorded answers. Applicable candidate evidence can be carried forward under the explicitly approved treatment.

Study-specific target overrides remain separately immutable, audited Study × form requirement decisions across stages. Changing one Study override does not change the standard target for every Study or create a global form version. Results record both the form version and any applicable override version. Define the interaction of an existing override with a newly published standard target explicitly in the detailed brief rather than silently guessing the new effective total.

Align Q-29/R1, the earlier routine-settings answer and publication/versioning contracts with this amendment. Other settings need their own classification; this amendment does not say that every workflow setting versions the form. Implementation remains on hold.

## Owner amendment — configurable screening tie adjudication

Chris approved R2 (Q-36, Q-11, Q-32) with this addition: a screening profile can configure ties to proceed to a separate explicit adjudication step instead of automatically requesting an additional screening decision. Preserve the alternative extra-review pathway; do not impose adjudication on every profile or infer an unchosen default. The chosen policy belongs to an immutable profile version and changes follow the agreed publication/impact process.

The adjudicator requires the appropriate explicit authority, sees the exact tied candidate decision versions under the profile blinding policy, and submits a new attributable immutable adjudicated outcome. Keep the original decisions and their history; a tie awaiting adjudication is pending, not a completed Include/Exclude outcome. Optional required adjudication rationale follows the approved profile setting. This step is part of the configured workflow, not a separate hidden stage-entry dependency. Tied screening decisions and optional discussion/self-resolution policies must be mapped explicitly into the step model in the brief. Implementation remains on hold.

### Screening decisions, annotations and adjudicator assignment

Chris clarified that configurable screening-decision tie adjudication sits alongside the screening profile configuration for screening-annotation reconciliation; it does not replace or collapse the two policies. A decision tie and disagreement between annotation/rationale answers are distinct triggers and can use separately configured handling within the profile. Preserve the profile-owned identity blinding, exact source-version lineage and any required rationale rules.

Chris also specified that the adjudicator assignment can name a project member or an eligible project group. A group assignment makes the work available to authorized members under the assignment/claim rules; the actual member who resolves it remains individually attributable. Assignment to a member/group never itself grants adjudication permission. Version and audit policy/assignment changes and show active/dependent-work impact where applicable.

## R4 amendment — explicit legacy activity mapping and adoption guidance

Chris requires the opt-in migration wizard to expose mapping of each legacy stage's annotation activities/definitions and recorded work into configured annotation steps, with generation of the underlying versioned annotation forms needed to support them. Preserve exact answer/session identities, available author/time/stage provenance, incomplete/completed status and uncertain historical default values. Show what is created, what is reused and how old work maps; do not merely rename a stage or fabricate historical steps. Where several old routes converge on a shared form, preview duplicate same-reviewer contributions and resolve them under the agreed provenance/conflict rules rather than silently count twice.

Legacy screening activities and existing decisions likewise map explicitly to screening steps and an appropriate versioned screening profile. Offer a reviewed default/legacy-compatible profile based on verified old behavior, with admin confirmation of the scientific meaning; do not infer a protocol or invent missing decisions/reasons. A choice not to map some work must explain retained legacy/history access and any blocked/incomplete adoption scope; it must not silently drop evidence. Specify permitted partial adoption boundaries in the brief.

The wizard must explain when migration is advisable and when to keep the project legacy. Recommend adoption when the selected scope has a complete faithful mapping, validated data preservation and eligibility behavior, passed performance/large-form checks, resolved publication/target impacts and a clear rollback boundary. Advise staying legacy when required capabilities are not delivered or validated, mappings/legacy semantics remain unresolved, preservation or performance checks fail, or disruption to active reviewing cannot yet be managed safely. Provide concrete project-specific findings and remedies rather than a generic warning. Staying legacy is a supported choice, not a forced migration failure.

These additions refine R4; they do not by themselves approve every remaining R4 recommendation or authorize implementation/migration execution.

## R4 research finding — eventual migration versus permanent dual operation

The repository adoption plan currently allows existing projects to remain legacy indefinitely until adopted or retirement is separately approved. It specifies staged, complete-scope adoption with inventories/manifests, preserved originals, verified pools/exports/permissions/statistics, and guarded cutover. After canonical writes, a return to old writers is generally not supported: use canonical-aware containment/forward recovery. Research here read planning documents, not a live-project inventory, so it cannot establish that every project already has a faithful migration path.

**Recommendation for owner review:** Target one maintained writable review engine. Progressively migrate active projects once faithful behavior/data mapping and performance are demonstrated. Keep blocked projects temporarily legacy with recorded blockers and a remedy/review milestone, rather than promise immediate universal migration or make permanent dual writing the default. Completed/archived projects need durable faithful access, exports and provenance; they may remain preserved legacy snapshots behind a read-only compatibility reader rather than being forced through a new active workflow. If reopened, require the appropriate adoption checks before new-engine review.

Permanent dual writable modes carry duplicated review behavior, security/authorization checks, testing, statistics/exports adapters and migration guard maintenance. A bounded read-only archive adapter is a smaller ongoing responsibility, though not zero cost. Eventual legacy-writer retirement must have explicit coverage/access/export/restore criteria and owner approval; no arbitrary retirement date is recommended. Immutable historical records and originals must not be deleted to accomplish retirement.

This refines the R4 alternatives and remains a recommendation, not owner approval or migration authorization. Scope/version changes recently agreed (including form-target versioning and automatic SingleAnnotator authority) must be reconciled into the older adoption mapping before design freeze.

Sources: [SyRF migration/adoption/rollback plan](https://github.com/camaradesuk/syrf/blob/main/docs/planning/integrated-review-plan-2026-10/migration-adoption-rollback.md), especially adoption modes, per-project protocol and R7 retirement. [Microsoft gradual replacement pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig) supports staged replacement while legacy functionality remains available; the active-versus-archive recommendation above is an inference tailored to SyRF.

## R4 owner direction — universal baseline conversion, then optional redesign

Chris proposes the long-term target of moving every project, including completed/inactive projects, into the new data/domain structures through a baseline mapping that preserves existing functionality and workflow behavior. This supersedes the earlier recommendation to leave completed projects permanently behind a separate legacy read-only adapter. Preserve read-only/completed state within the new model where applicable; do not reopen archived work merely to convert storage.

Separate two operations explicitly:

1. **Baseline conversion:** faithful mapping of legacy stages, annotation activities/questions, existing sessions/answers, screening configuration/decisions, effective targets, allocation, access, exports and statistics to supported new-model forms/profiles/steps. Generate the minimum versioned structures needed to reproduce existing behavior, retain original identities/provenance and preserve historical current state. Do not force new scientific protocol choices or add workflow constraints merely because the new engine supports them. Verify legacy completion semantics, conditional questions, combined activities and special project configurations; an assumed one-stage-to-one-step rule is not proof of parity.
2. **Optional subsequent redesign:** within the new engine, an admin wizard can map baseline configurations to multiple steps in one stage or steps across several stages, change form/profile arrangements and add capabilities. This is a versioned design/publication transition using impact previews, active-work warnings, compatibility and target treatment, retained history and dependency safeguards. It does not repeat a legacy storage migration.

Represent unavailable legacy information explicitly as domain states such as NotRecordedInLegacy/history coverage CurrentSnapshotOnly, distinct from a reviewer answering Unknown, NotApplicable or an unanswered new question. Preserve nullable historical times rather than inventing them. Keep an uncertain authored-under definition, value-or-default uncertainty and legacy completion validation status explicit. The baseline schema must support these states intentionally; do not fake old revisions, timestamps, steps, adjudications or reconciliation outcomes. Migration mappings carry actor/rule, source and target versions, baseline conversion time and manifest provenance.

Sequence: synthetic/staging opt-in trials, validated production pilots, then a controlled scheduled conversion of every remaining legacy project once coverage and behavior parity are proven. The universal target includes projects not opting into early pilots. Readiness requires representative project inventories, all relevant reader/writer paths accounted for, preserved UI behavior/permissions/outcomes/pools/exports/statistics, acceptable large-project performance, recovery rehearsal, trustworthy audit and complete manifests. Preserve project-specific configurations rather than force a uniform new protocol.

Automated waves should be idempotent/resumable, avoid half-converted authoritative scopes, coordinate active work and notify admins/reviewers. Stop/quarantine a failed or unmappable project without losing evidence, record the blocker, and remediate toward the universal target; do not declare parity or force a lossy conversion. Exact automatic migration timing, notification/override rules and acceptance gates remain to specify in the approved brief. Before first canonical writes, rollback can restore routing; after new-model writes, canonical-aware recovery must preserve those writes rather than flatten them back into legacy data.

Retire legacy writers once all projects are safely converted and access/export/restore checks pass, with explicit retirement approval. Retained originals/manifests do not require a second active engine. Baseline conversion and later redesign each retain traceable immutable history.

This is the planning direction expressed by Chris, not permission to execute migration or implement it. Update earlier R4 guidance from permanent stay-legacy alternatives to temporary blockers before faithful baseline conversion. Other R4 choices must align with this separation; exact specialist mappings and acceptance evidence remain required.

## S1 amendment — bounded Unsure handling and adjudication fallback

Chris proposes configurable screening-profile rules for unresolved combinations involving Unsure, using the separate screening adjudication/reconciliation pool already agreed. With an initial two-reviewer agreement rule, request a third reviewer where the first two do not establish a sufficient definite outcome. If the third does not establish sufficient agreement with the definite response, route the unresolved outcome to adjudication rather than repeatedly requesting more reviewers.

For the proposed two-agree/three-then-adjudicate configuration: Include + Unsure + Include yields Include; Exclude + Unsure + Exclude yields Exclude; Include + Unsure + Exclude remains unresolved and requires adjudication; Include + Unsure + Unsure also requires adjudication. Two agreeing definite decisions already satisfy that configured rule without a third. The full transition table, including two/all Unsure responses, order-independent evaluation, in-flight additional responses and other thresholds, must be specified and tested in the brief. Profile settings can choose the additional-review versus earlier-adjudication policy and its bound; do not silently impose the same numeric threshold on every profile.

Unsure remains not excluded for availability/reporting under the agreed policy, but this does not make it a definite Include vote for satisfying collective agreement. Keep the distinction between an unresolved screening outcome and permission to proceed early under the agreed within-stage rules. Pending adjudication is not a completed definite collective outcome. Version the profile policy and preserve exact candidate decision versions, original authors, adjudicator/system actions, source lineage and chronology in protected history.

This is the owner's proposed refinement of approved S1, not authorization to implement. Resolve its complete transition table with the configured collective rule before freezing the screening brief.

## S3 clarification — template guidance, not a question-count restriction

Chris clarified that configuring the number/content of screening annotation questions and their applicable agreement requirements should not be restricted by the proposed primary exclusion reason. Treat the default exclusion-reason template and configuration guidance as separate from the supported screening-profile capabilities. Multiple screening annotation questions and recorded reasons remain supported.

A recommended template may nominate a primary reason for a simple mutually exclusive reporting breakdown, but do not impose one question/one recorded reason as a platform-wide constraint or discard additional answers. Always count distinct excluded Studies separately from per-reason counts. Multi-reason categories may overlap and must be labelled accordingly rather than summed as a distinct-Study total. S3 template/guidance direction is approved; exact template content and advice are specified in its brief; agreement requirements follow explicit profile configuration, not an inferred count of reasons.

## S4 owner expansion — training, scoring and reviewer-group admission

Chris approved a dedicated training step for annotation forms and screening activities. Authorized admins can define the expected/reference (training gold-standard) responses. These are training reference versions, distinct from live accepted study evidence. Preserve exact form/profile/question versions, reference values, provenance and administrator changes.

Provide a scoring system and manual evaluation of a reviewer's training responses. Support configurable scoring rubrics and pass criteria for the supported question/decision types; do not assume exact-text equality grades semantic/free-text answers correctly. Responses requiring judgment can be manually evaluated. Attempts, scores, assessor feedback, automatic/manual decisions and their rubric/reference versions must retain immutable history. Specify feedback disclosure, retries and rubric changes in the brief.

An authorized admin may configure successful training to admit the reviewer automatically to a specified project group whose configured permissions allow live reviewing. Manual evaluation/approval must also be available. Record the exact training attempt, result, policy version and system/assessor actor that caused the membership action. The rule grants only the configured group membership under existing permissions; group assignment itself does not implicitly grant broader authority. Handle retries without duplicate grants and concurrent membership/configuration changes through the existing group contracts.

Training activity remains outside live screening votes, annotation targets, accepted results and PRISMA review counts. Live evidence promotion remains a separate explicit audited action, not a side effect of scoring or admission. Preserve identity/blinding and protected audit rules. These are planning requirements; exact grading thresholds and implementation/test evidence belong in the detailed approved brief. No implementation or automatic membership execution is authorized now.

### S4 manual assessment and retry policy

Chris also specified that authorized manual assessors can pass or fail a training attempt, and the project training policy can determine whether a failed reviewer is allowed to try again. Preserve each attempt and assessment rather than overwrite a failed attempt; configure any retry limits/conditions explicitly and record the policy version.

## S5 approved interpretation behavior

Chris approved the limited initial relationship reasoner and rule-publication permissions. This builds on ordinary annotation/reconciliation, not a separate mandatory review workflow. Candidate inferences use only the reviewer's own authorized evidence snapshot; collective inferences use a pinned accepted/reconciled snapshot or explicitly permitted authority, never an unapproved mixture of reviewers' facts. Published rules and their exact versions remain attributable.

Show inferred groups, outcome associations and contradictions with supporting evidence/rule provenance. Recompute when relevant inputs/rules change and withdraw outdated current conclusions without rewriting reported answers or inventing unsupported counts. Preserve protected identity/blinding boundaries and historical snapshots. Exact refresh/invalidation timing and performance guarantees must be specified and validated in the brief.

### S5 activation amendment — project-designer opt-in beta

Chris requires the S5 advanced classification/rule/inference capability to start in beta and be explicitly enabled by an authorized project designer. It is off by default; do not silently activate it for existing projects or baseline migration. Keep ordinary annotation/reconciliation usable without opting in. Show the beta status and explain capabilities and implications in the opt-in configuration. Record enablement/disablement and policy versions with actor/time; disabling stops new inference use while preserving underlying reported answers and historical inference/provenance. GA promotion is a separate readiness/approval decision. Implementation remains on hold.

## E3 expansion — external screening and AI-model-generated decisions

Chris requires importing externally produced screening decisions, including AI classification-model results, with correct source attribution and context. This expands the later import capability beyond external annotation answers; it does not authorize an import now or mandate moving that lane into the first engine release.

Model the decision origin explicitly as an external human or machine/system producer, separate from the user who imports/confirms it. Do not invent a SyRF human reviewer to represent a model. Preserve source system/model identity and version, run identity, original decision/label, profile/version mapping, imported-at time and importer, source timestamps where available, and source dataset/training-round provenance. Preserve original confidence/scores and the configured label/threshold mapping where supplied and relevant. Unsupported or missing source details are explicit, not fabricated. Resolve source-record-to-Study identity with provenance; imports are previewed, validated and idempotent, with new versions for corrected or rerun outputs.

The screening profile explicitly configures how that source participates: an eligible contributing vote alongside other sources, or the sole screening decision source for the configured scope. The source counts only under that declared policy. Repeated outputs from one model/source are revisions, not extra independent screeners. Version policy changes under the profile publication/impact rules, preserving prior decisions and outcome history. Keep machine-assisted outcomes distinguishable from exclusively human outcomes in reporting/exports. The earlier import recommendation requiring every target-counted contribution to map to a SyRF reviewer is superseded for these configured external screening sources; annotation-import qualification remains separately specified.

Support an initial human-screened training set followed by imported model decisions. Record training/evaluation membership and its source versions, and do not treat model outputs on their training inputs as independent validation evidence or double-count the underlying human decisions as new observations. This specifies provenance/interpretation, not building a model-training service inside SyRF.

Include, Exclude and Unsure label mapping is explicit. In a sole-machine screening policy, an Unsure output is unresolved and can enter the configured human screening adjudication/reconciliation step; not-excluded availability does not make it a confirmed collective Include. A human resolution creates a new attributable outcome with the exact model output and any other candidate versions as inputs. Preserve the model decision unchanged. When machine decisions are only one vote, use the versioned profile sufficiency/conflict/Unsure rules and bounded escalation, not a hard-coded extra vote.

Retain independent/informed/machine-source distinctions for agreement statistics; do not mix them into a human-independent agreement metric without an approved statistical definition. Imported screening decisions may affect current outcomes and pool filters only after validated acceptance under the declared profile policy, triggering the agreed structured membership/impact history. Admission, access and history remain consistent with the rest of the plan. Detailed external-import contracts, allowed source policies and scientific validation belong in the brief. Implementation remains on hold.

### E3 AI-model metadata ownership and links

Chris requires machine-assisted screening AI-model details to be recorded within the project and associated with the screening profile and its decisions. Use a versioned project-level external-screening/model configuration record, referenced by the exact profile version that declares the source policy and by the import/run/decision provenance. Record model name/provider/version or artifact reference, intended use, available training-set and run context, decision-label/threshold configuration and relevant documentation. The importer/administrator remains separately attributed. Changing model metadata/policy creates new attributable versions; earlier decisions keep their original model/profile/run references. Profile-specific configuration remains distinct from the reusable project model description. Provide a permission-aware UI for inspecting these details and expose the relevant method/provenance in exports/reporting. Do not substitute current model settings for the historical settings of an imported decision.

### E3 expansion approval and AI-model source identity

Chris explicitly approved the external-screening/AI-model metadata expansion on 4 October 2026. An AI-model decision source does not require a human login account or invented project member. Keep its source identity, versioned configuration and run provenance separate from authenticated importer/operator identity. Any actual import/integration execution still follows the application authorization contract; model-source attribution itself grants no login capability or permissions. This approval adds no new original register item and does not activate imports or implementation.

### Explicit AI-model terminology

Chris requires the document and user-facing attribution to explicitly say AI-model-generated screening decision / AI screening model, rather than ambiguous model decision. This distinguishes the external artificial-intelligence producer from SyRF domain/data models and human reviewers. Non-AI external sources retain their actual source type; do not relabel every external import as AI.

## U1 owner amendment — draft versus saved checkpoint status

Chris accepts the U1 recommendation with revised status wording: Draft auto-saved for autosaved draft edits not yet captured by an explicit Save/Complete; Version checkpoint saved (or equivalent clear wording) after explicit Save progress creates an immutable session version. Complete remains visibly distinct from an incomplete saved checkpoint. Avoid calling an autosaved draft a submitted version or implying that a checkpoint automatically completes the session. If a saved version already exists and further draft edits are autosaved, preserve/show the prior checkpoint separately rather than implying no version has ever been saved. These are user-visible status messages; the versioning semantics do not change.

### U1 wording flexibility

Chris permits iteration on the exact wording. Draft auto-saved and Version checkpoint saved are illustrative labels, not mandatory verbatim strings. Preserve the distinction between recoverable autosaved edits, an explicit immutable saved checkpoint and completed submission. Final wording can be refined through design/usability review without reopening those semantics.

## U2 exploration — Progressive Web App

Chris requests exploration of making SyRF a PWA alongside full phone/tablet/desktop annotation support. This is a feasibility/design item, not an approved PWA implementation, offline-review requirement or additional fixed launch commitment.

Read-only repository inspection found src/services/web/src/site.webmanifest with standalone display/icons but empty name fields, plus mobile-app/theme metadata in index.html. The checked package/build configuration did not reveal Angular service-worker/PWA setup; no installed/runtime behavior was tested. Existing manifest/metadata alone is not evidence of full PWA readiness.

Investigate installability and standalone UX, browser/device support, update/caching behavior, authentication/logout, draft persistence and connectivity handling. Distinguish installable online-first support from true offline review and later synchronization; any offline writes must preserve version checks, active-work/publication rules, authorization revalidation and conflicts, and need their own explicit design/approval. Avoid caching protected study data as an accidental default. Validate feasibility and propose a concrete scope before committing delivery.

Source: [Angular service workers/PWA overview](https://angular.dev/ecosystem/service-workers) and [getting started](https://angular.dev/ecosystem/service-workers/getting-started). Repository inspection was read-only; implementation remains on hold.

## U2 clarification — PWA scope and caching

PWA exploration is beyond the MVP and includes possible caching of allocated studies. Offline review, synchronisation and safe local storage require separate detailed design; they are not yet committed launch capabilities. Full annotation on phones, tablets and desktops remains required at launch. Implementation remains on hold.

## O1 amendment — Admin-controlled contribution exclusion

Authorized project admins may explicitly exclude a member's contributions from current use for a selected annotation form, screening profile, stage or the whole project, including from the membership-disable workflow. Disabling membership alone preserves contributions; exclusion is an explicit choice with impact preview, reason, actor and time. Submitted versions and named attribution remain immutable and accessible in history. Reviewers cannot unilaterally withdraw their submitted contributions by leaving or disabling their account; communicate this in project joining terms. Stage-scoped exclusion must identify contributions by recorded provenance, not assume shared sessions belong to a stage; preview effects across all routes and dependent results. Existing dependent results remain intact, with affected authors informed and new result versions created only through an explicit decision. Whole-project deletion remains a distinct policy.

The separate whole-project physical-deletion policy in D3-12 remains to be confirmed; no destruction of immutable contribution history is approved here. Implementation remains on hold.

## Owner addition — Optional browsing of allocated studies

Chris requests an optional, explicitly enabled browsing mode for reviewers to navigate the studies allocated or assigned to them. This is a study-serving/navigation addition associated with O4, separate from O3 outdated-answer handling. Browsing must stay within the reviewer's authorized allocation/assignment scope; pool membership alone does not grant access or permission to start or submit review work. Current eligibility, remaining-work, availability, capacity, permissions and step progression rules still apply. Ordinary random serving remains available. Configuration ownership and the browsing interface belong in the detailed brief. This addition does not by itself settle every bundled O4 recommendation.

Implementation remains on hold.

## Owner clarification — Dynamic available allocated-study pool

The optional reviewer browsing list is a dynamic pool of currently available allocated/assigned studies. Re-evaluate relevant availability and eligibility changes so studies no longer available are removed from that list. This is distinct from the stage study-filter pool and does not erase assignment records, review history or drafts. Existing started work follows the approved configurable continuation rules; removal from the browse list must not silently revoke permitted continuation. Preserve structured reasons for changes and show why an item became unavailable. Recheck current eligibility when starting work rather than relying on the displayed list.

Implementation remains on hold.

## Owner definition — Reviewer study pool within a stage

The reviewer study pool is stage-specific and is a subset of that stage's current study pool, further restricted to studies allocated/assigned to that reviewer and currently available under applicable review rules. Optional browsing operates on this reviewer study pool, not on an unrestricted project-wide assignment list. A study leaving the stage pool also leaves this current reviewer pool. Any permitted continuation of already-started work is surfaced separately as saved work, without treating that study as still in either current pool. Preserve assignment, availability and review-start history with stage and reviewer context.

## Owner clarification — Blinding in reviewer-pool browsing

Optional reviewer-study-pool browsing must enforce blinding: do not expose other reviewers' candidate screening decisions, candidate annotation responses or identity-revealing contribution metadata. Applicable reconciled screening decisions and reconciled annotation data may be shown under their configured visibility rules. For annotation forms, retain the approved form-level availability setting with step-level hide-only restrictions, labeled reconciled hints and provenance, and explicit click-to-fill rather than automatic prefilling. Browsing does not create a new disclosure exception; provenance shown to reviewers must itself respect identity blinding. Protected audit attribution remains available only through authorized access.

## O1 final owner clarification — Reversible project deletion

Approved by Chris: ordinary whole-project deletion is reversible removal from normal use. Hide the project from ordinary lists; block review and editing; stop new allocations and project notifications; release active review reservations while preserving drafts and immutable evidence/history. Retain the data for restoration through a restricted deleted-projects view by an authorized admin. Record deletion and restoration actor, time and reason; alert affected active users consistently with the approved impact rules and prevent stale saves from bypassing deletion. Restoration re-evaluates availability and capacity rather than reviving stale reservations. Permanent physical erasure is a distinct policy and is not authorized by ordinary deletion.

Implementation remains on hold.