# SyRF condensed review — remaining decisions

Prepared 4 October 2026. The **60 unresolved original entries** are mapped below: **20 owner review packages covering 38 entries**, **4 carry-forward alignments**, and **18 brief/specialist-validation items**. These are proposed classifications, not newly approved decisions. This consolidation originally mapped 60 pending entries. R2 has since been approved (Q-36, Q-11, Q-32), leaving 57 pending original entries at that point; Q-35 has since been removed as inapplicable, leaving 56; R3/Q-04 has subsequently been approved, leaving 55; R4 then resolved Q-05, Q-21 and D4-16, leaving 52; S1/D4-01 is approved, leaving 51; S2/D4-02 is approved, leaving 50; S3/Q-22/D4-13 is approved, leaving 48; S4/D4-04 is approved, leaving 47; S5/Q-18/Q-19 is approved, leaving 45; E1/Q-06b/D4-11 is approved, leaving 43; E2/D4-05/D4-07 is approved, leaving 41; E3/D4-09/D4-10/D4-14 is approved, leaving 38; E4/D4-15 is deferred beyond MVP, leaving 37; U1/D3-03/D3-04 is approved, leaving 35; U2 device scope/D3-05 is resolved, leaving 34; U3/D3-07/D3-08 is approved, leaving 32; the mapping retains all 60 for traceability.

**Implementation remains on hold.** No repository documents or code were changed. Each workstream still needs an approved detailed brief before implementation. A batch approval approves its stated planning recommendations, not activation, deployment or implementation.

## How to review

Read a batch and reply, for example, **“Approve the Reconciliation and adoption batch except R3: …”** or **“Approve all recommendations except …”**. Unmentioned recommendations are accepted only within an explicit batch/all-recommendations approval. Silence and discussion alone do not approve anything. If a changed answer affects another package, revise it before recording approval.

Carry-forward rows preserve existing owner decisions. Brief items are recommendations for engineers/methodologists to specify and validate; moving them here does not declare them solved. Surface any new product, scientific, privacy, irreversible-migration or operational-risk choice back to Chris. Specialist inputs must be obtained before their dependent implementation.

## Settled foundations

One project Study review unit; shared form sessions across stages; form target and versioned study-specific overrides; immutable submission/version history; admin-controlled publication impact; atomic reversible consolidation/unmerge; form/profile-owned reconciliation blinding without cross-study identity aliases; form-default reconciled hints with explicit autofill and restrictive step overrides; form-owned tracking/limits; automatic versus static stage completion; stage filter plus within-stage step rules; opt-in migration wizard; structured entry/exit and activity history with recorded justification. Preserve the latest owner decisions when older source wording conflicts.

## Batch — Reconciliation and adoption

### R1 — Single-reviewer evidence and verification

**Status:** Resolved by Chris: 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.

**Target-setting changes:** Chris confirmed that applying a new form-settings version that changes the target can lead to a corresponding new immutable reconciliation/result version, retaining the entire history. Record the settings and candidate versions behind each result and its actor/system provenance. Raising the target does not manufacture additional evidence: report unmet readiness explicitly and use the agreed impact/reconsideration process. Exact transition and adoption rules remain to specify in the brief.

**Planning-history check:** The earlier annotation-reconciliation design explicitly auto-creates a versioned accepted result when exactly one completed session satisfies a target of one, with `SingleAnnotator` authority and links to the original answer versions. No human reconciliation step is needed. Its `CandidateAgreement` path, in contrast, requires reconciler bulk approval. The newer integrated plan deliberately proposes no automatic gold for target-1 forms. R1 is therefore a genuine policy difference between plans, not a technical necessity; no owner choice has yet resolved that difference. Translate any adopted earlier behavior into the shared Study × form model rather than revive stage-owned targets.

**Owner direction following that check:** Chris wants the earlier no-human-step result concept made compatible with the newer model. Revise the R1 proposal accordingly: an automatic single-reviewer result can be a distinct immutable accepted-result version, with `SingleAnnotator` authority, system action/rule provenance and exact candidate-version lineage. It is not labelled as human reconciliation or independent verification. Use current shared-form applicability and effective-target rules rather than old stage targets. If inputs change, preserve the accepted version and apply the agreed dependency-impact/explicit-reconsideration process. The optional second-reviewer verification proposal remains a separate choice; this direction does not approve automatic agreement-based acceptance for multiple reviewers.

**Options:** Automatically treat it as accepted; require explicit acceptance; or offer a second-reviewer verification path.

**Revised recommendation:** **For the eligible single-reviewer case, retain automatic accepted-result creation without a human reconciliation step, explicitly labelled Single annotator and preserving exact immutable input lineage and system provenance. Offer a distinct optional verification workflow with attributable Verified authority. Never label automatic acceptance as human reconciliation.**

**Why:** This keeps the distinction between one observation, verification and reconciliation visible.

**Original entries:** Q-29, D4-03. Source: [original recommendation](C:/Users/chris/Documents/Codex/2026-10-04/realtime-voice-chat-2/outputs/syrf-remaining-planning-decisions.md:171).

### R2 — Reconciliation powers and shortcuts

**Status:** Approved by Chris on 4 October 2026, with the configurable screening tie-adjudication addition below.

**Options:** Ordinary self-reconciliation/automatic acceptance; or permissioned explicit acceptance with optional shortcuts.

**Recommendation:** **No ordinary self-reconciliation by default. Require explicit override grants. Offer bulk acceptance of agreeing candidates later, off by default, with a reconciler confirming exact inputs. Screening adjudication may require a rationale through a profile setting, off by default.**

**Why:** Agreement is evidence for an authorized decision, not permission to manufacture accepted results.

**Original entries:** Q-36, Q-11, Q-32. Source: [original recommendation](C:/Users/chris/Documents/Codex/2026-10-04/realtime-voice-chat-2/outputs/syrf-remaining-planning-decisions.md:187).

### R3 — Accepted-answer completeness

**Status:** Approved by Chris on 4 October 2026 after removing the inapplicable legacy reconciliation branch.

**Owner correction:** Q-35 is inapplicable: Chris confirms no legacy reconciliation data exists because that feature has not been fully implemented. Remove its proposed legacy-authority handling from required scope. Verify the premise during migration; surface any unexpected data rather than invent authority. Q-04 remains the completeness/missing-comparison choice. A missing comparison does not itself prevent reconciliation.

**Options:** Require every answer; follow question requiredness; or accept any partial result. Relabel legacy authority or preserve its uncertainty.

**Recommendation:** **Follow question requiredness with a form-level override. Missing comparisons are Not assessed; explicit Unknown is an answer. Do not require legacy reconciled-result migration on the owner-confirmed absence of such data.**

**Why:** Avoid silently strengthening incomplete or historically uncertain evidence.

**Original entries:** Q-04, Q-35. Source: [original recommendation](C:/Users/chris/Documents/Codex/2026-10-04/realtime-voice-chat-2/outputs/syrf-remaining-planning-decisions.md:195).

### R4 — Baseline conversion for all projects, then optional workflow redesign

**Status:** Resolved by Chris on 4 October 2026 with the universal-baseline direction. Original Q-05, Q-21 and D4-16 are covered by this answer; detailed mapping and validation requirements stay in the brief.

**Latest owner direction:** Pilot a faithful baseline mapping into the new domain/data structures, explicitly represent missing legacy information, then convert every remaining project after validation. Preserve existing workflow behavior. Later admin-led redesign happens entirely within the new engine through a wizard. Earlier permanent-legacy/archive-adapter recommendations below are superseded by the universal-baseline direction at the end of this document.

**Options:** Automatic migration; reviewed wizard migration; or defer all adoption until the full rollout.

**Recommendation:** **Use a dry-run and reviewed manifest with legacy-stage mapping in the opt-in wizard. Admins confirm what legacy screening represented. Allow limited screening-only adoption when ready; clearly show the rollback boundary before the first new-engine write. Preserve uncertain historical default values as uncertain.**

**Why:** This extends the migration wizard already agreed; it does not weaken fully reversible merge/unmerge.

**Original entries:** Q-05, Q-21, D4-16. Source: [original recommendation](C:/Users/chris/Documents/Codex/2026-10-04/realtime-voice-chat-2/outputs/syrf-remaining-planning-decisions.md:219).

## Batch — Screening and research workflow

### S1 — An Unsure screening answer

**Status:** Approved by Chris on 4 October 2026.

**Options:** No Unsure; optional Unsure default off; or default on in the title/abstract template.

**Recommendation:** **Offer per-profile Unsure, on in the title/abstract template. Treat it as not excluded for availability; explicitly configure collective handling and report it transparently.**

**Why:** Avoid forcing an uncertain reviewer to claim Include or Exclude; collective rules must still be specified.

**Original entries:** D4-01. Source: [original recommendation](C:/Users/chris/Documents/Codex/2026-10-04/realtime-voice-chat-2/outputs/syrf-remaining-planning-decisions.md:481).

### S2 — Candidate discussion after screening conflict

**Status:** Approved by Chris on 4 October 2026. When the profile enables it, invite discussion after submitted decisions reveal conflict; preserve initial observations, record exposure, and version corrections. Configure fallback if discussion fails.

**Options:** Only independent reconciliation; or an optional discussion path after conflict.

**Recommendation:** **Offer profile-controlled discussion, off by default. Record exposure and any versioned corrections; independent agreement uses the initial observations.**

**Why:** Discussion can resolve conflicts but is no longer independent evidence.

**Original entries:** D4-02. Source: [original recommendation](C:/Users/chris/Documents/Codex/2026-10-04/realtime-voice-chat-2/outputs/syrf-remaining-planning-decisions.md:489).

### S3 — Default exclusion-reason template and guidance

**Status:** Approved by Chris on 4 October 2026 with the template/guidance interpretation, not a one-question or one-reason limitation.

**Clarification:** This is a configurable template/reporting recommendation, not a limit on screening annotation questions or recorded reasons. Distinct excluded Studies and potentially overlapping reason-category counts must remain separate. See the S3 clarification below.

**Options:** One primary reason; or several counted reasons. Choose by criterion order or by reviewer.

**Recommendation:** **Use one primary reason for MVP reporting, defaulting to the first failing criterion in configured order. Allow a profile setting for reviewer choice and disclose missing reason coverage.**

**Why:** Keeps counts interpretable without concealing incomplete reasons.

**Original entries:** Q-22, D4-13. Source: [original recommendation](C:/Users/chris/Documents/Codex/2026-10-04/realtime-voice-chat-2/outputs/syrf-remaining-planning-decisions.md:267).

### S4 — Training and calibration

**Status:** Approved by Chris on 4 October 2026 with expanded admin reference answers, scoring/manual evaluation and optional reviewer-group admission. Training is requested for delivery; defer-to-hook-only needs separate scope agreement. See the S4 expansion below.

**Options:** Separate training now; defer with a prepared hook; or mix it with live review.

**Recommendation:** **Design a separate training/calibration step, excluded from live targets, votes and reporting. Deliver with lifecycle work if feasible; otherwise prepare its admission hook and defer the interface. Promotion to live evidence requires explicit admin action.**

**Why:** Practice should not silently change the scientific evidence.

**Original entries:** D4-04. Source: [original recommendation](C:/Users/chris/Documents/Codex/2026-10-04/realtime-voice-chat-2/outputs/syrf-remaining-planning-decisions.md:505).

### S5 — First rule/classification capabilities

**Status:** Approved by Chris on 4 October 2026 with scoped inference and version/provenance rules. Start in beta, off by default, with explicit project-designer opt-in.

**Options:** Broad inference now; or a narrow initial reasoner with permissioned publication.

**Recommendation:** **Start with conjunction, containment, disjointness and exhaustiveness. Project Design users publish rules; reviewers record applicability and normal reconciliation resolves disagreement.**

**Why:** Keeps the first capability testable without giving ordinary review actions publication powers.

**Original entries:** Q-18, Q-19. Source: [original recommendation](C:/Users/chris/Documents/Codex/2026-10-04/realtime-voice-chat-2/outputs/syrf-remaining-planning-decisions.md:243).

## Batch — Reporting and data exchange

### E1 — Reporting units and updated-review diagrams

**Status:** Approved by Chris on 4 October 2026.

**Options:** Treat every import as a study/report; or label supported units and preserve reported versus computed counts.

**Recommendation:** **Keep import/reference, source-document and project Study counts distinct. Disclose missing exclusion reasons, retain frozen reports and protocol changes, and use explicitly reported previous-review counts for the updated-review template. Defer a full updated-review workflow.**

**Why:** Use actual stage review history separately from pool history, as already agreed.

**Original entries:** Q-06b, D4-11. Source: [original recommendation](C:/Users/chris/Documents/Codex/2026-10-04/realtime-voice-chat-2/outputs/syrf-remaining-planning-decisions.md:227).

### E2 — Methods documentation and full-text retrieval

**Status:** Approved by Chris on 4 October 2026.

**Options:** Infer retrieval from attachments; or record explicit retrieval and protocol/search history.

**Recommendation:** **Record search strategy/date/platform/limits/round and append-only protocol amendments. Require an amendment when published screening changes eligibility. Use explicit Sought, Retrieved and Not retrieved actions with actor/time/reasons; attaching a PDF suggests rather than silently confirms retrieval.**

**Why:** The project needs explainable methods and status, not guesses from files.

**Original entries:** D4-05, D4-07. Source: [original recommendation](C:/Users/chris/Documents/Codex/2026-10-04/realtime-voice-chat-2/outputs/syrf-remaining-planning-decisions.md:513).

### E3 — Exports, estimated values and external answer imports

**Owner expansion:** Include correctly attributed external screening/AI-model decisions, configurable as a contributing source or the sole screener, with Unsure routed to human adjudication. See the detailed E3 expansion below; do not force a machine to masquerade as a human reviewer.

**Status:** Approved by Chris on 4 October 2026.

**Options:** Core exports only; exports plus provenance now; or add all imports and graph digitisation immediately.

**Recommendation:** **Provide analysis-ready comparison exports, a codebook and selected RIS export; no internal effect-size calculation in this lane. Add estimated-from-graph provenance now. Defer digitisation pending pilots and external answer imports until after the initial engine. Later imports need source provenance, reviewer mapping before target credit, and no automatic gold or independent-agreement credit.**

**Why:** Keep useful exchange capabilities while protecting evidence attribution.

**Original entries:** D4-09, D4-10, D4-14. Source: [original recommendation](C:/Users/chris/Documents/Codex/2026-10-04/realtime-voice-chat-2/outputs/syrf-remaining-planning-decisions.md:545).

### E4 — Accepted answers controlling later steps

**Status:** Resolved by Chris on 4 October 2026: optional extra, outside MVP. Stage study filters retain approved reconciled-answer clauses; do not confuse this deferral with removing that filtering support.

**Options:** Build all conditional routing immediately; or keep the approved pool-filter support and defer additional step branching.

**Recommendation:** **Keep reconciled-answer clauses in stage filters as already agreed. Deliver optional accepted-value conditions between steps after core reconciliation; do not introduce another incoming-stage gate.**

**Why:** The source blurred pool filters and step routing; this recommendation separates them.

**Original entries:** D4-15. Source: [original recommendation](C:/Users/chris/Documents/Codex/2026-10-04/realtime-voice-chat-2/outputs/syrf-remaining-planning-decisions.md:593).

## Batch — User experience

### U1 — Labels and draft status

**Status:** Approved by Chris on 4 October 2026, with Draft auto-saved and Version checkpoint saved status wording.

**Options:** Keep legacy terminology; or consistent sentence-case labels with draft/submission distinction.

**Recommendation:** **Use Save progress, Complete, Needs updating, Outdated answers, Fix, Accepted answers and Screening result. Say Draft auto-saved for autosaved draft changes and Version checkpoint saved after explicit Save progress, keeping Complete distinct; optional gold-standard terminology belongs in explanatory text. Use consistent sentence case.**

**Why:** An autosave should not look like an explicit immutable submission.

**Original entries:** D3-03, D3-04. Source: [original recommendation](C:/Users/chris/Documents/Codex/2026-10-04/realtime-voice-chat-2/outputs/syrf-remaining-planning-decisions.md:310).

### U2 — Device support and legacy appearance

**Owner amendment:** Full annotation functionality must support phones, tablets and desktops at launch (D3-05 resolved). The legacy-appearance recommendation D3-06 is now approved, including compatible new features without workflow behavior changes.

**Options:** Phone annotation at launch; or phone screening with tablet/desktop annotation first.

**Recommendation:** **Support screening and full annotation functionality on phones, tablets and desktops at launch, with responsive layouts and meaningful touch/accessibility/large-form performance validation. Refresh shared legacy navigation/pages consistently without changing their review behavior.**

**Why:** Focus first-release testing while keeping the application coherent.

**Original entries:** D3-05, D3-06. Source: [original recommendation](C:/Users/chris/Documents/Codex/2026-10-04/realtime-voice-chat-2/outputs/syrf-remaining-planning-decisions.md:326).

### U3 — Work discovery and pilot measurement

**Status:** Approved by Chris on 4 October 2026 with the recommendation below.

**Options:** Rely on notifications; or My work with role-aware counts. Collect no timing data or opt-in timing data.

**Recommendation:** **Provide project My work, cross-project access and a global badge even when notifications are muted; show pending admin changes. Keep the agreed tester panel. Use consent-based timing telemetry without answer content; defer a full global landing page.**

**Why:** Users should find work without email, and pilot measurement must be distinct from scientific audit records.

**Original entries:** D3-07, D3-08. Source: [original recommendation](C:/Users/chris/Documents/Codex/2026-10-04/realtime-voice-chat-2/outputs/syrf-remaining-planning-decisions.md:342).

## Batch — Access, communications and warnings

### O1 — Withdrawal, access removal and evidence validity

**Owner decision:** Approved with an amendment to 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.

**Options:** Delete evidence with access/source changes; or preserve it with explicit current-state treatment.

**Recommendation:** **Carry forward approved search-withdrawal and account-deactivation rules. Removing membership/sign-in does not itself invalidate contributions. Offer a separately permissioned audited exclusion of contributions from a form. Whole-project deletion follows its separate reversible-deletion policy; do not silently remove a Study still supported by another search.**

**Why:** Availability and authorship/history are separate concerns.

**Original entries:** D3-12, D4-20. Source: [original recommendation](C:/Users/chris/Documents/Codex/2026-10-04/realtime-voice-chat-2/outputs/syrf-remaining-planning-decisions.md:382).

### O2 — Email privacy and conversation retention

**Status:** Approved by Chris with the email-content amendment on 4 October 2026.

**Options:** Put detailed review content in email; or keep it behind authenticated access.

**Recommendation:** **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. Allow per-project email mute while retaining in-app notices. Retain reconciliation conversations as project audit records with permissioned export; exclude their text from answer exports and agreement statistics.**

**Why:** Preserves context and auditability without uncontrolled disclosure.

**Original entries:** D3-22, D3-24, D3-25. Source: [original recommendation](C:/Users/chris/Documents/Codex/2026-10-04/realtime-voice-chat-2/outputs/syrf-remaining-planning-decisions.md:446).

### O3 — Warnings about outdated answers

**Owner decision:** 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.

**Options:** Always block; configurable blocking modes; or non-blocking warning.

**Recommendation:** **Warn and allow Complete anyway, while ordinary validation, applicability, permissions and mandatory publication treatment remain enforced. Record exposure/provenance.**

**Why:** This warning is not permission to bypass an incompatible question or required re-review.

**Original entries:** D4-17. Source: [original recommendation](C:/Users/chris/Documents/Codex/2026-10-04/realtime-voice-chat-2/outputs/syrf-remaining-planning-decisions.md:609).

### O4 — Default serving and candidate identity protection

**Status:** Resolved with Chris's optional stage-specific reviewer-pool browsing, dynamic availability and blinding amendments on 4 October 2026.

**Options:** Random serving; fixed order; or assignment-only.

**Recommendation:** **Serve randomly by default, with audited assignment/group exceptions already agreed. Preserve candidate identity protection and explicit disclosure exceptions. Use context-local aliases without cross-study identity continuity. Do not undo the approved visible reconciled-response hints by calling all candidate work fully independent.**

**Why:** Existing hint exposure and explicit assignments must remain truthful exceptions

**Original entries:** D4-19. Source: [original recommendation](C:/Users/chris/Documents/Codex/2026-10-04/realtime-voice-chat-2/outputs/syrf-remaining-planning-decisions.md:617).

## Carry forward — no new owner decision proposed

| Original entry | Treatment |
|---|---|
| Q-23 | Apply the agreed reporting-unit distinction and deferred full report/investigation grouping; do not reopen it. |
| D4-08 | Apply prepared multi-source links with deferred distinct-report grouping and Study-owned review sessions; already agreed. |
| D3-17 | Carry forward separate target and capacity concepts, form baseline and audited reservation impact. Exact cap defaults belong in the brief; no silent eviction. |
| D3-18 | Replace old stage-derived timeouts/in-progress rules with Q-28: form-owned timeout and per-reviewer limit, one shared place across connections/routes. |

## Workstream briefs and specialist validation

These are not individually presented as owner questions. Keep them visible as pending brief requirements and evidence gates.

| Original entry | Required treatment |
|---|---|
| D4-06 | Have authorized CAMARADES methodologists curate and verify the proposed SYRCLE, CAMARADES and ARRIVE templates, including outcome-specific applicability, in the agreed catalog. Confirm exact coverage in the brief before publishing templates. |
| D2-10 | Implement the agreed narrow active-work protection in a tested publication protocol; engineer and measure pause/operation limits rather than ask Chris to guess them. |
| D2-13 | Document and rehearse isolated point-in-time recovery with manifests and evidence checks; production recovery execution requires its own authorization. |
| Q-17 | Obtain the field-level event-count scientific specification from Chris/CAMARADES methodologists. This is a specialist input, not a guessed batch default. |
| Q-16 | Specify denominators and percent agreement; obtain statistical review before selecting multi-rater formulas. |
| D4-12 | Combine with Q-16 in one methods specification using initial independent observations and profile-specific reporting. |
| D4-21 | Validate pinned ASySD parity and benchmark methodology. Existing F1 ≥0.99 / 80,000-under-one-hour numbers remain proposed acceptance targets, not owner-approved or achieved results. |
| D3-01 | Coordinate visual roles/theme, staging/dark-mode checks and visual baselines with the established UI programme. |
| D3-02 | Use integrated release design reviews plus focused risky-screen previews and routine checks; scheduling belongs in each brief. |
| D3-09 | Reconcile the paused eligibility programme with the owner-approved step/filter model; disabled routes, preserved work and explicit early-reconciliation authority remain distinct. |
| D3-10 | Prove authoritative source-pinned stats reads, profile granularity and protected pilots; preserve provisional production readiness. |
| D3-11 | Choose a rebuildable agreement-statistics projection with source watermark and measured budget, separate from progress stats. |
| D3-13 | Specify allocation/batch contracts, denominators and performance gates. Distinguish first offer/release, pool entry, actual review start and completion in structured history; do not call them the same event. |
| D3-16 | Pilot shared-form capacity before broader opt-in rollout; validate load and statistics integration. |
| D3-19 | Specify annotation reservation at personal Include, not while screening is underway, and preserve that screening evidence when annotation capacity is unavailable. |
| D3-20 | Ordinary reviewers see active counts/their own place; Monitor permission controls names without defeating blinding. |
| D3-21 | Specify pilot/environment/family gates, test email sink and delivery pause. Approval of this review is not production-email activation. |
| D3-23 | Resolve related notices when work resolves, retain history and update unread counts consistently. |

## Complete mapping — all 60 original entries

| Original entry | Topic | Review destination |
|---|---|---|
| D2-10 | May publishing a form briefly pause affected work? | Brief / specialist validation |
| D2-13 | How should canonical review data be recovered after data loss? | Brief / specialist validation |
| Q-29 | How do one-reviewer forms reach accepted answers? | R1 |
| Q-35 | How should old reconciled answers with unknown authority be handled? | R3 |
| Q-36 | What authority and self-reconciliation rules should apply? | R2 |
| Q-04 | How complete must accepted answers be, and how are missing comparisons counted? | R3 |
| Q-11 | May authorized users bulk-accept studies whose candidates all agree? | R2 |
| Q-32 | May a screening profile require a rationale for adjudication? | R2 |
| Q-05 | How should existing outcome data migrate? | R4 |
| Q-06b | Which remaining PRISMA reporting amendments should be adopted? | E1 |
| Q-17 | What fields should the event-count outcome schema contain, and what does variation mean? | Brief / specialist validation |
| Q-18 | What should the first experimental-classification reasoner support? | S5 |
| Q-19 | Who can publish project rules and shared-concept mappings? | S5 |
| Q-16 | How should agreement be calculated for several reviewers and structured entities? | Brief / specialist validation |
| Q-22 | Should PRISMA count one exclusion reason or several per excluded study? | S3 |
| Q-23 | How should reports be counted when several imports or documents are involved? | Carry forward |
| Q-21 | What did each legacy project's screening represent when adopting it? | R4 |
| D3-01 | How should new screens align with the Material 3 visual rollout? | Brief / specialist validation |
| D3-02 | How often should design acceptance happen? | Brief / specialist validation |
| D3-03 | What labels should users see for saving, completion and answer state? | U1 |
| D3-04 | How should buttons and typography be written? | U1 |
| D3-05 | Which work should be supported on phones? | U2 |
| D3-06 | Should legacy screens receive the visual refresh? | U2 |
| D3-07 | How should users find everything they need to do? | U3 |
| D3-08 | Who should take part in user testing, and what pilot telemetry is appropriate? | U3 |
| D3-09 | How should the rollout handle the paused eligibility programme? | Brief / specialist validation |
| D3-10 | How should live statistics support publication and pilots? | Brief / specialist validation |
| D3-11 | Where should reviewer-agreement statistics be stored? | Brief / specialist validation |
| D3-12 | How should search withdrawal differ from deleting a project? | O1 |
| D3-13 | How should allocation and progressive batches integrate? | Brief / specialist validation |
| D3-16 | How should reviewer capacity protection be enabled in production? | Brief / specialist validation |
| D3-17 | Should the maximum simultaneous reviewers be separate from the minimum reviewer target? | Carry forward |
| D3-18 | How should differing tracking and timeout settings work across shared-form routes? | Carry forward |
| D3-19 | When should screening reserve a place on a dependent annotation form? | Brief / specialist validation |
| D3-20 | Who may see the identities of currently active reviewers? | Brief / specialist validation |
| D3-21 | How should notifications be enabled? | Brief / specialist validation |
| D3-22 | What may notification emails and digests contain? | O2 |
| D3-23 | Should related notices resolve automatically when the underlying work is resolved? | Brief / specialist validation |
| D3-24 | May users mute email for one project? | O2 |
| D3-25 | How should reconciliation conversations be retained and exported? | O2 |
| D4-01 | Should title/abstract screening offer Unsure? | S1 |
| D4-02 | May candidates resolve a screening conflict through discussion? | S2 |
| D4-03 | Should single-reviewer extraction support a second reviewer verifying it? | R1 |
| D4-04 | Should calibration or training rounds be supported now? | S4 |
| D4-05 | What protocol, registration and search documentation should be recorded? | E2 |
| D4-06 | Which risk-of-bias and reporting-quality templates should be curated? | Brief / specialist validation |
| D4-07 | How should full-text retrieval be tracked? | E2 |
| D4-08 | Should different reports of one investigation be linked in this rollout? | Carry forward |
| D4-09 | Which new exports should be provided? | E3 |
| D4-10 | What should be done about values estimated from graphs? | E3 |
| D4-11 | How should an updated review's previous-version PRISMA box be supported? | E1 |
| D4-12 | Which observations and formulas should agreement reports use? | Brief / specialist validation |
| D4-13 | How should the primary exclusion reason be selected? | S3 |
| D4-14 | Should answers from other tools be importable? | E3 |
| D4-15 | Should accepted answer values route items to later work? | E4 |
| D4-16 | May existing projects adopt screening profiles before full adoption is ready? | R4 |
| D4-17 | Should outdated answers block completion or require formal acknowledgement? | O3 |
| D4-19 | How should blinding and random allocation behave? | O4 |
| D4-20 | Do contributions remain valid after a member loses access? | O1 |
| D4-21 | What evidence should establish duplicate-algorithm parity? | Brief / specialist validation |

## Limits and sequencing

This is a synthesis of the existing planning register and the owner decisions in this conversation. It is not a fresh implementation audit or evidence that any recommended capability already exists. Scientific formulas, schema semantics, specific performance numbers, catalog content and recovery protocols need primary-source/methodologist review or empirical validation in their briefs.

Begin detailed planning with the shared foundations, publication/eligibility history, reconciliation authority and migration contracts. Optional discussion, calibration, imports, advanced reasoners and later step branching can be scheduled after their dependencies; approving their direction does not force them into the first engine release. Preserve all prior rollout scope unless Chris explicitly changes it. Avoid numeric timelines inferred from this consolidation.

[Full original discussion register](C:/Users/chris/Documents/Codex/2026-10-04/realtime-voice-chat-2/outputs/syrf-remaining-planning-decisions.md)

## 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

Chris places PWA exploration beyond the MVP. Include caching of allocated studies as a possible enhancement to assess. This does not yet authorize offline submissions or commit to an offline review workflow; synchronisation, permissions, protected-data storage and version conflicts require a detailed design. Full phone, tablet and desktop annotation remains a launch requirement. 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.

Implementation remains on hold.

## O2 owner amendment — Informative, permission-aware emails

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. Per-project email mute and retained in-app notices remain approved, as does permissioned retention/export of reconciliation conversations outside answer exports and agreement statistics. 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.

## Current remaining review summary

The original register has 26 unresolved entries, including carry-forward alignment and engineering/validation work rather than 26 separate owner decisions. Residual owner choices include optional second-reviewer verification (R1), the legacy-screen visual refresh (U2), and the separate whole-project physical-deletion policy (O1). Single-reviewer automatic acceptance is already directed by Chris; automatic acceptance of agreement between multiple reviewers is not yet approved. Detailed briefs still need mappings, performance/consistency/recovery evidence, specialist statistical/reporting choices and an overall consistency check. Implementation remains on hold.

## R1 final owner clarification — One candidate plus reconciliation

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.

Implementation remains on hold.

## U2 final owner clarification — Compatible legacy-screen improvements

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.

## 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.