SyRF review steps: design and prototype handoff¶

Current DP6 correction: personal Include governs within-stage steps; cross-stage routing is configurable. DP7 confirms Collective Include required as cross-stage default; advanced own-Include option allowed. Strict within-stage details remain proposed. Older blanket cross-stage DP1 wording below is historical/superseded.

Latest 3 October planning update: LC1 readiness/admin-confirmed reopening, UA1 optional blanks, PM2 owner-granted group delegation, ODIR1 single measure direction and MIG1/IP1 authorized planning supersede earlier open/deferred wording below. Review the implementation plan and its linked matrix/migration/settings proposals. No runtime execution is authorized.

Purpose, scope and evidence¶

This is a self-contained brief for designing a light-mode prototype of configurable review steps in SyRF. It consolidates Chris's discussion and subsequent decisions through 2 October 2026. It is research and design, not permission to implement SyRF runtime changes, migrate data, merge or deploy. Use synthetic studies and local demo state. SyRF records and exports evidence; this is not an analysis or pooling workflow. The separate materialised-statistics programme is outside scope.

Design direction confirmed in discussion is identified below. Concrete storage shapes, UI arrangements and unresolved policies remain proposals. Earlier documents being In-Review does not mean their described features have shipped. Later explicit decisions here supersede the conflicting conversational alternatives, but do not approve the whole implementation.

Owner decisions, 2 October 2026: the shared-form decision record supersedes earlier per-step submission/target assumptions. Forms own shared study evidence, reviewer sessions, targets and sufficiency across stages. Stage/step context is workflow and revision provenance. Autosave, Save and Complete have distinct semantics. Accepted-answer visibility is configurable by step with a stage default. Publishing a new form version checks sessions from any earlier version and prompts the admin to choose their treatment; earlier completed contributions' counting follows that choice. Form-version/question usage uses materialized statistics made current at the publish boundary (PS1–PS3). Application/confirmation of recovered transition choices remains to design; do not ask Chris to reconfirm shared sessions, form targets or a universal count default.

The smallest useful prototype demonstrates project profiles/question sets, two review steps, one shared form used across two stages, and a reviewer session showing personal Include plus collective-Exclude veto. Include the confirmed Save/Complete lifecycle and publish gate; follow-up scenes cover additional forms, handoff and reconciliation. Do not make cohort classification or configurable outcome schemas prerequisites for this prototype.

Terminology and ownership¶

Concept	Scope and responsibility
Annotation question	Project library definition; versioned text, options, dependencies and validation.
Question set	Versioned selection of question versions, preserving ancestor requirements. Reused by configured review steps.
Annotation form	Project-level evidence/requirement owner, selecting versioned questions and owning a shared target for each study. Overlapping forms share compatible same-question/context answers while retaining distinct completion requirements.
Screening profile	Project-owned assessment identity, eligibility criteria, screening question trees, decision rules, agreement and reconciliation configuration. Multiple stages/steps can reference it.
Review step	Stage-owned configuration containing screening, an annotation question set, or both. Has identity, display order, dependencies and completion requirements.
Form session	One reviewer-owned session for a study/form, accessible through any stage using that form. Form-version compatibility boundaries remain to specify. Stage navigation does not create duplicate sessions or contributions.
Workflow context	Stage/step, versioned stage settings and bound profile/form versions governing access, order and work presented. Recorded on session/submission versions; does not own duplicate annotation evidence. Exact legacy mapping remains engineering work.
Screening decision	One effective submitted decision per project/study/reviewer/profile, with immutable revision history. Source stage is provenance, not another vote identity.
Form session version	Immutable incomplete version on Save, or validated completed version on Complete, pinning requirements and annotation revisions submitted together plus workflow context. A qualifying reviewer counts once toward the shared study/form target.
Annotation revision provenance	Source stage/step, exact stage-settings/question versions, and accepted answer version actually shown where applicable. Reuse preserves authorship context rather than transferring ownership to another stage.
Accepted gold snapshot	Versioned snapshot per study referencing exact reconciled annotation revisions; approved changes create a new snapshot retaining unchanged revision references.
Submission receipt	Records an action submitting screening, annotation, or both. Not the unit counted toward either review target.
Collective outcome	Derived from effective decisions under the profile's rules, with versioned inputs. Distinct from any person's decision.
Adjudication	Attributed authoritative resolution for specified input versions; not an additional candidate vote.

“Review step” is the agreed term, rather than renaming these parts of a session “activities”. Display order does not itself create a dependency. Profiles have no inherent predecessor profile or stage ordering. Workflow dependencies belong to the stage's review steps.

Configuration surfaces¶

Project question library and screening profiles¶

The administrator defines ordinary study-fact questions in the project question library. Screening eligibility questions and their configuration belong to and are defined alongside the screening profile (DP4). Reuse the question-tree editor and ordinary answer types, not ordinary study-fact ownership. Importing a template creates profile-local configuration; template edits do not silently update existing profiles. Same-profile stages share screening answers; different profiles do not share them just because they imported the same template. Screening trees must not require traversing unrelated extraction questions first. Physical storage/category/capability representation remains engineering work, not an ownership choice.

Profiles can present questions before a decision, or request Include/Exclude first and then collect the appropriate reasons/evidence. Those are presentation orders, not different vote identities. Draft answers may exist before a decision is chosen. A question hierarchy controls branching; explicit rules are needed to combine answers using all/any conditions. Automatic decision versus recommendation-and-confirmation remains configurable design work, with confirmation recommended initially. Missing/unclear answers are not silently false.

Study facts are independent answers about the paper. Decision-owned answers explain or support a particular profile assessment. A decision may reference an existing study fact without moving it under the decision or requiring duplicate entry. Submitted decisions pin the evidence versions actually used. “Eligibility criterion” is a rule, not a separate answer class: answers, reasons and supporting detail can all use ordinary annotation machinery.

Stage designer¶

Show an editable list of review steps. Each step can reference a screening profile, an annotation question-set version, or both. Configuration needs to expose:

Display order separately from prerequisite relationships; reject cycles.
Whether Exclude terminates the dependent route, the whole session route, or does not stop other independent work. Do not infer that every visually later step is dependent.
Which steps are compulsory for this reviewer's session and where handoff is allowed.
Whether collective completion can satisfy a compulsory prerequisite without this reviewer repeating it. Record this as collectively satisfied, not personally submitted.
The referenced form's shared review target/sufficiency, without a duplicate per-step or per-stage target. Screening agreement/targets remain on the profile.
Versioned stage settings binding exact profile/form requirements, plus step-level show-reconciled-answers policy with a stage default. Own answers remain accessible; other candidates' individual answers remain hidden.
Completion of previously saved work after collective exclusion, defaulting to Allow completion, distinct from accepting new screening votes. Stage default with advanced per-step override is confirmed (EW1 below).
Allocation and access requirements, without requiring identical screening/extraction rosters.

The stage does not define paper-specific outcomes or cohorts. Reviewers create those while extracting a study; the project defines the questions and allowed data structures.

Within-stage and cross-stage dependency policy confirmed by Chris¶

For configured dependent steps within or across stages: personal Include with collective-Exclude veto. This must apply to study selection, reservations/admission and submission checks, not merely hiding controls after a study has been selected.

Personal decision	Collective decision state	Dependent new work
Include	Pending or Conflict	Eligible under this dependency; no wait for group Include.
Include	Included	Eligible under this dependency.
Any or absent	Resolved Excluded	Blocked.
Exclude	Included, Pending or Conflict	Blocked for this reviewer.
None	Included	Eligible only if collective satisfaction is enabled for this prerequisite. No vote is invented.
None	Pending or Conflict	Screening prerequisite remains to do, if screening admission/allocation permits.

Permissions, allocations and outstanding demand still apply to every eligible row. A personal Exclude is reused across stages sharing the profile; it is not automatically presented as a new voting task. Collective satisfaction does not override a personal Exclude. DP1 confirms the same personal-Include/collective-Exclude rule for configured cross-stage dependencies.

An agreed collective Exclude stops new dependent work even if required reason reconciliation is pending. Candidate decision agreement and authoritative reporting remain separate states. Only affected dependent routes stop; independent work remains eligible. If no eligible work remains for a reviewer, the study is not selected for that reviewer. Existing work stays accessible. Filtering/skipping a downstream profile never manufactures an Exclude under that profile.

Screening and annotation in the same review step¶

In a combined mode there is no separate Include button: starting extraction expresses draft intent only; completing the form submits Include alongside the form when both are admissible. Explicit Exclude can collect reasons and bypass remaining extraction without deleting answers. Opening a form or saving a draft never casts a vote.

To submit Include before extraction is finished, use separate screening and extraction steps with an explicit dependency. Screening-only, annotation-only and combined contributions must be supported where configured and admitted. If one component is already sufficient, the other may remain outstanding; a combined-step receipt must identify exactly what was submitted.

Do not make prior personal Include a prerequisite for opening the same combined form that will create that Include: that would be circular. Entry gates and completion effects differ. After profile sufficiency, extra-vote admission follows explicit policy; an annotation-only completion must not silently add a vote. An existing vote can be referenced without counting twice.

Sessions, submissions and counts¶

Confirmed by Chris, 2 October 2026 (SF1–SF3): a form is a project-level evidence and requirement owner, not just a reusable questionnaire or default-settings container. There is one reviewer-owned form session for the study across stages using that form. The form's target and sufficiency are shared across those stages; steps connect workflow/access/order without creating duplicate evidence or independent copies of the target.

Screening counts distinct effective voters per study/profile. Annotation counts distinct reviewers with qualifying completed versions toward the shared study/form requirement. Opening or submitting the same form through two stages, corrections, retries and receipts do not add another reviewer contribution. Qualification across form versions follows the publish-time admin choice (FV1–FV3); that does not permit incompatible-answer reuse.

Compatible same-question/context answers are shared across overlapping forms. Form F can be complete while Form G remains incomplete because G requires additional questions. Shared answer revisions do not imply identical form completion or remove context/version checks. SF5 requires prior own ancestor answers to be shown and older-answer flags on other pinned sessions; sharing is not automatic rewriting of their immutable references.

Example: Alice submits both screening and extraction, Bob screening only, Carol extraction only. There are two screening contributors and two annotation contributors, not three of each. Screening sufficiency additionally uses the profile's agreement rule.

Form F may require two reviewers and Form G one. Alice completes F and G, Bob completes F; both shared targets are satisfied wherever those forms are used. Reusing F in another step does not add another target or reviewer contribution. Completed forms are not automatically reconciled forms; personal completion, shared form sufficiency and workflow prerequisite satisfaction remain distinct.

A screening-only assignment can finish while extraction remains for another reviewer. Compulsory steps and handoff configuration determine individual session completion. Collective step satisfaction, personal completion, exclusion-driven skipping and outstanding work must remain distinguishable. No empty/incomplete annotation session is fabricated just because another reviewer still needs to extract something.

Corrections, historical access and surplus work¶

Reviewers opening a study can see their relevant previous answers and profile decisions, even where those steps no longer accept new work. Deliberate correction creates new versions, not a duplicate vote or silent rewrite. Broader access/permission rules still apply.

A correction begins as unconfirmed autosaved edits over the current explicit form version. Autosave alone leaves its completion status unchanged. Explicit Save makes an incomplete version current, replacing any completed current version and removing its completed qualification. Complete validates and makes a completed version current again. Each prior version and its exact revisions remain immutable history, never extra contributions. Screening decision transitions remain separate: a form Save does not invent or silently retract a screening vote.

Confirmed Save lifecycle, 2 October (SL1–SL3): autosave preserves draft changes/history without minting an explicit saved/submitted session version per edit. Save creates an immutable incomplete session version. Complete validates and creates an immutable completed version that can qualify toward the shared form target. Further edits draft from a version. Chris corrected SL3: the latest explicit Save OR Complete is current. Autosaved edits do not supersede it; an incomplete correction Save does, so the session no longer counts as completed. Keep draft presence/changes separately visible and warn about them at publication. Distinguish current completed, saved incomplete and draft-only sessions, never counting history/drafts as additional sessions or reviewers. The earlier completed-until-Complete rule is superseded. Storage/event mechanics remain proposals.

Confirmed provenance, 2 October (PV1/PV2/GS1): annotation revisions record their source stage/step and exact stage-settings/question versions, plus accepted answer versions actually shown where applicable. Reuse never overwrites that provenance. Session/submission versions record their workflow context and revisions submitted together. Stage settings are versioned and bind profile/form versions; historical work pins its requirements. Accepted gold is an immutable per-study snapshot referencing exact reconciled revisions; approved updates retain unchanged references in a new snapshot. Session context records the snapshot available; per-answer provenance records what was actually shown, not merely permitted to be shown.

If changing a shared answer exposes unanswered required questions in an earlier step, invite an explicit update to that form. Preserve its original submission and earlier dependent branches. Mark the update pending without subtracting the last completed review solely because a replacement draft exists. Historical correctness and current compatibility differ.

Proposed downstream handling of incomplete Save (not a decided counting policy for other SF5-flagged sessions): re-evaluate shared form sufficiency and dependent-step applicability using the new current incomplete version. Show affected steps as needing reassessment, preserve their work and pinned history, and apply the configured admission/completion policy rather than deleting work. Define atomic count/projection and concurrency behavior. Accepted gold remains unchanged unless its own approved snapshot transition occurs. Use the recovered admin-controlled choices; exact effects on unfinished work need design.

EW1 — Saved-work completion after collective exclusion¶

Resolved default — Chris, 2 October 2026: allow reviewers to finish previously saved work after collective exclusion by default. Preserve-only remains the alternative; preserve drafts under either policy. This governs the exclusion-specific existing-work exception, not a new per-step target or vote-admission setting.

Placement confirmed — Chris, 2 October 2026: stage-owned default Allow, with an advanced per-step override. This supersedes the earlier open stage/form placement discussion; form-owned evidence, sessions and targets are unchanged.

New dependent work remains blocked after collective exclusion. Completion of saved work still respects personal Exclude and other permission/admission requirements, and never invents an Include vote. Where completion is allowed, warn and record a surplus assessment when appropriate without changing the separate contribution-counting policy. A new screening vote can be refused independently. Do not assume the old Allow/Stop new-vote setting also controls annotation completion.

The default above applies specifically to previously saved work after collective exclusion. It does not set a default for target/screening sufficiency changes or other conditions. Those conditions retain their separate policy requirements. This decision approves the stage default and per-step override. It does not approve application changes, migration or activation.

Surplus is a versioned assessment, not a permanent boolean on the form. Record the exact submission version, eligibility/outcome versions, requirement versions, reason and time. Distinguish “submitted after exclusion” from “target already exceeded”. Reassess on relevant changes. A complete compatible review can count normally after the study becomes Included again, while retaining the historical surplus assessment. How to select contributions when there are more qualifying reviews than the target remains an engineering/policy detail.

Agreement and adjudication¶

Confirmed visibility and statistics, 2 October (VS1/VS2): each step can select whether candidate reviewers see reconciled answers, with a stage default. Own previous answers remain accessible; other candidates' individual answers remain hidden. The same form supports independent or informed work. Record the exact accepted answer version shown; permission to view alone is not exposure. Agreement statistics distinguish independent contributions from those made after viewing accepted answers. Ordinary progress still includes qualifying informed work. This refines earlier blanket restrictions on candidates seeing accepted gold; it does not expose other candidates' individual answers or weaken access permissions.

Profiles support additional independent votes or adjudication as configured resolution routes. Adjudication records a decision and applicable reasons against exact candidate input revisions; it neither edits the candidates nor becomes another vote. Submitting a replacement input makes the old adjudication inapplicable to current inputs but preserves it historically. Re-evaluate current agreement and reason rules; a new adjudication is needed only if those rules still require it. Draft corrections do not change current adjudication applicability.

Earlier FEAT-009 planning used “bypass”; the clearer UI term is reconciliation not required. The profile defines which screening answers must agree for automatic resolution, and whether manual review is mandatory. Chris's later direction here changes the earlier blanket defaults: use multiple-choice agreement by default, with free text as supporting evidence unless explicitly selected for matching. Do not infer semantic equivalence of different free text. Unchecked text remains individually attributed, not automatically an agreed authoritative answer.

Preserve the earlier approach of deriving only agreeing branches when an authoritative tree is formed from candidates; original candidate branches are never deleted. AG2 settles exact multi-select selection-set agreement. Precise comparison semantics for other non-choice structured types and required-answer completeness need specification. Final reconciliation submission accepts displayed valid answers, including matching prefill (RE2); no separate per-field confirm gate is required.

Question versioning: reuse earlier planning¶

Reuse the Question Management / Annotation Versioning design, adapting its session-version transitions to individual form submissions. Publishing a question version does not silently upgrade every question set. The administrator chooses which sets adopt it and which review steps bind to the new set versions, then decides what happens to existing submissions.

Existing submissions can stay pinned, compatible answers can be carried forward with provenance, or an updated draft can require re-answering. The administrator may accept an optional addition as compatible; a missing required answer cannot be declared answered. Per-submission validation detects contextual breaks even if the designer labelled a change non-breaking. Historical completed submissions remain intact. Publication presents affected submissions and records the transition choices. This is existing planning, not new runtime behaviour.

Recovered existing transition choices, not a new owner decision: Annotation Versioning §3.1–3.3 already defines per-question requireReanswer, autoUpdate, doNothing, with admin confirmation before commit. The pinned/carry-forward/re-answer paths above are that baseline. Adapt its stage-set impact scope to shared form sessions and all their stage uses. Do not reopen a universal reviewer-manual-versus-automatic decision. Its older “Questions added: No impact on existing sessions” does not override the newer admin-controlled treatment of added required questions. Remaining design covers how these choices apply to completed, saved incomplete and draft-only work, and the confirmation UI.

Confirmed form-version transition, Chris, 2 October (FV1–FV3): adding a question creates a new annotation form version. Publishing automatically checks for existing form sessions associated with any previous version of that form. If any exist, prompt the publishing admin to choose what happens to them. Whether previous completed sessions count toward the updated form requirements depends on that publish-time admin choice, not a universal hard-coded answer. Show effects for drafts, completed contributions and shared cross-stage uses.

Original immutable versions and provenance remain intact. Admin transition policy and question-level answer compatibility are related but distinct; neither a chosen counting policy nor publication creates a missing required answer or permits incompatible-answer reuse. Category-specific application/confirmation of recovered choices, adoption/binding effects, compatibility and concurrency details remain to design. This design decision does not authorize silent migration or runtime changes.

Confirmed publish-impact evidence, Chris, 2 October (PS1–PS3): use materialized statistics for reviewer/form-session usage per form version and question usage, version-aware as appropriate. Before publishing a form/question version, verify those relevant statistics are current at the publish point. Wait for catch-up or update the specific statistics there and then; a brief review pause may be needed in the design. Publish only with current required evidence and the required admin choice recorded. A current confirmed zero is distinct from missing/stale evidence. Count shared sessions/contributions once across stages. Classify by latest explicit Save or Complete, with draft-only when none exists and a separate unconfirmed-changes indicator. Publication treatment distinguishes completed, explicitly saved incomplete and autosaved work; admins may treat completed and unfinished work differently; application/confirmation of the established choices still needs category-specific design. Admin-controlled autoUpdate already exists in planning; exact unfinished-work effects need design. This authorizes no live pause or stats work.

Engineering must propose a protected publish boundary/high-water mark or equivalent protocol aligned with existing materialized-statistics ownership. A timestamp check followed by a racing publish is insufficient. Determine dependency-relevant writes to fence, including relevant autosave/session creation, Save/Complete, imports/corrections/binding changes; prefer scoped pauses and safe release on failure. Aggregate counts identify impact size, not record identity; authoritative session/annotation records must supply the affected identities in a consistent scope. These protocol/storage details remain recommendations to substantiate.

Confirmed version-update presentation (VU1–VU3)¶

Chris, 2 October 2026: under requireReanswer, an invalidated draft answer remains visible beside its question, marked Needs updating. Preserve history and require a valid replacement before Complete. Display any admin-provided change reason and reviewer guidance alongside. Do not erase the old answer or present it as satisfying the updated requirement.

Creating a question version supports two distinct version-specific fields: Why it changed and What reviewers need to do differently. Retain both in version history. Both are optional. If a require-reanswer publication has no reason, show a non-blocking warning that reasons help reviewers understand the change and avoid confusion; the admin can still publish. Missing reviewer guidance also does not block publication. The stats/impact-choice gate and compatibility checks still apply. This refines the recovered admin-controlled transition baseline; it does not replace it or decide other saved-incomplete/draft adoption mechanics.

Confirmed accepted-answer query lifecycle (QY1–QY7)¶

Chris, 2 October 2026: the following replaces the earlier proposal-only classification.

Effective answer: accepted reconciled answer stays effective while challenged, with a visible pending-query flag until an authorised decision. Previous accepted snapshots remain intact and effective until a valid replacement is published.
One review work item per accepted answer version: group multiple queries against that same version, retaining each person's concern, reason, proposed correction and individual resolution. The authorised reviewer may accept some concerns and reject others; grouping never collapses them into one undifferentiated decision.
Parent and children: if an approved parent correction invalidates child answers, resolve affected children before publishing the new immutable gold snapshot. Retain unchanged revision references and history. Do not fabricate replacement child values or publish unresolved invalid children; the prior snapshot stays effective while the replacement is prepared.
Review authority: prefer a different authorised person, but permit self-review when the query author has query-review permission. Record raiser and resolver, exposing self-review in audit history. This exception applies to approved query review, not ordinary initial candidate-versus-reconciler eligibility.
Rejection explanation: optional. Do not block rejection for an empty explanation.
Resolution notifications: everyone who raised a concern receives their outcome and any explanation supplied. Preserve candidate isolation; do not expose others' individual answers, reasons or concerns beyond their existing permissions. This specifies future behavior only; no notifications are sent by this planning work.
Who may raise: anyone already permitted to view the accepted answer may raise a query, not only candidates or reconcilers. This grants neither broader answer visibility nor approval authority. Approval requires query-review permission; configurable accepted visibility remains.

QY8 qualification: demonstrably addressed individual concerns close against the resolving version with author notification; other concerns keep the grouped work open. Uncertain cases need manual review. QY9 preserves unsatisfied concerns open against their original target and flags current applicability for reviewer checking; concurrent resolution remains engineering, without silent retargeting or cross-version merging. Exact queue/assignment controls, permission enforcement and notification delivery mechanics need design within these boundaries.

Publication-pause UX recommendations — not approved¶

The conversational recommendation is an admin impact summary warning of active reviewers, and a visible queued Save/Complete that preserves the exact intended version, waits, then retries idempotently if old-version completion is accepted. If updated requirements are mandatory, retain the draft and request reviewer action rather than silently rebasing or retrying forever. Routine pauses should not invalidate sessions; avoid disruptive notifications unless action is needed. Chris explored minimizing disruption but did not approve these UI/retry details. This does not authorize live pauses or actual notifications.

Confirmed reconciliation access, assignment and additional review (RA1–RA5)¶

Chris, 2 October 2026: the shared reconciliation pool remains the default. Optional explicit assignment of a specific study to an eligible reconciler is a small admin feature; it does not replace the pool or override ordinary initial reconciler eligibility.

Assignment expiry has a stage default; an authorised assigner may override expiry for an individual assignment, with audit. Changed stage defaults affect new assignments only. Expiry applies only to explicitly assigned, unstarted work. Started assignments never auto-expire. An authorised admin can release a started assignment to the pool while retaining saved work; its original reconciler must reacquire before further submission. Do not attach these expiry rules to normal pool work. Normal pool work uses existing active-work tracking to prevent two reconcilers simultaneously editing the same study. Exact start detection, release/reacquire concurrency and fine-grained grants remain implementation design.

Requesting one additional independent eligible reviewer is permitted even after the ordinary target is met, but requires the specific Request an additional review permission. Reconciler status alone does not confer it. The additional reviewer sees no other candidates' answers; the completed extra assessment returns to the reconciler, does not automatically set gold, and does not change the normal form target. Keep the extra-review request and assessment attributed and distinguish it from a target increase or an automatic authoritative answer. Exact request allocation/idempotency and returned-work presentation remain to design.

Confirmed final reconciliation form acceptance (RE2)¶

Chris, 2 October 2026: reconciliation is submission of a reconciliation annotation form. Completing/submitting final reconciliation explicitly accepts the valid answers displayed in that form, including auto-populated matching candidate answers. Do not require a separate confirmation click on every auto-populated field, and do not promote agreement to gold before final reconciliation submission. Clearly and obviously indicate auto-populated answers, distinguishing populated fields from explicitly entered ones, retaining candidate/source provenance. Absence of manual editing does not mean absence of final acceptance.

Before permitting reconciliation submission as Complete, show a warning if included relevant annotation questions or answers have not been brought into view. Track tab visits separately from exposure of the actual annotation controls: opening a tab, rendering an offscreen control, or populating its answer does not establish that the control was brought into view. Identify unseen content and provide a route to it. This records exposure, not proof of reading or understanding. Confirmed: allow Complete anyway. The reconciler may deliberately choose Complete anyway without visiting every relevant control, or follow the warning links to review unseen content. This is not a mandatory reading or per-field confirmation gate. Normal answer validity and affected-child requirements remain enforced.

Save/autosave is unfinished reconciliation work, not accepted-gold publication. Valid-answer and affected-child checks remain: query-approved parent correction cannot publish invalid unresolved children. Screening collective rules remain profile-governed; this form-submission acceptance rule does not change screening's automatic collective resolution. This supersedes RD5's original per-field confirmation recommendation, not immutable snapshot/provenance rules.

Confirmed current and historical downloads (EX1)¶

Chris, 2 October 2026: current answers are the default download, including accepted/gold and candidate answers as applicable. Previous versions must be downloadable for reproducibility, including review-data state as of a particular date. The earlier undecided export note is superseded. Reuse and compare the recovered temporal/version work first; see the read-only investigation. Open #2461/#2574 reserve historical modes but currently support only CurrentState; merged #2398 is a plan. Do not claim that arbitrary-date retrieval already ships or invent a second export architecture. Existing export authority and answer visibility apply; cutoff/consistency details need comparison.

Confirmed agreement-statistics access (AG1)¶

Chris, 2 October 2026: viewing agreement statistics requires a separate capability so administrators can grant access without granting admin control. Reconcile does not implicitly grant it. It does not expose individual candidate answers or bypass stage identity blinding. Reuse an existing suitable statistics-view permission if its scope matches; exact technical mapping remains to verify, not a decision to invent a duplicate permission or new role.

Confirmed reconciled-answer explanations (RE1)¶

Chris, 2 October 2026: explanations for reconciled annotation answers are optional, including when an authorised reconciler chooses an answer different from every candidate. A non-blocking reminder may encourage an explanation; absence never becomes a completion or publication gate. Reconcile authority and Request an additional review remain separate capabilities. This does not waive answer validity or affected-child validation. Current/historical download direction is now confirmed under EX1.

Confirmed placement (EW1 and BL1)¶

EW1 placement now confirmed: allow finishing saved work after exclusion defaults to Allow at stage level, with an advanced per-step override. The earlier stage-versus-form question is resolved; shared form evidence/targets remain unchanged. This setting does not reopen new work after exclusion, override personal Exclude/permissions, invent Include or redefine targets.

BL1: reconciliation identity blinding is stage-owned and consistent across the reconciliation workspace, rather than competing form/profile controls. Identity blinding is distinct from the confirmed step-level accepted-answer visibility policy and independent additional-reviewer isolation; stage ownership does not grant answer visibility.

See the permission inventory: use existing capabilities where appropriate, label proposed mappings and keep finer grant gaps distinct from settled workflow behavior.

Prototype screens and worked scenes¶

Outcome schema clarification for the prototype (27 September)¶

Superseded 27 September restriction; OC1, 3 October: the first schema release includes legacy-compatible and event-count supplied schemas plus project outcome-schema creation/ customization. Projects own enabled-schema configuration, versioned project schema definitions and question bindings; supplied catalogue definitions retain their own ownership. Stages select validated versions rather than inventing structural overrides. Schema references target schema configuration/version records, not reviewer-created annotation instances. Requested field examples are optional design inputs, not an all-fields fixed schema. Exact types/roles/validation and event-count structure need specification; migration policy remains P9.

The integrated design, section 4.5 specifies a dedicated outcome-schema selection question using common infrastructure; options come from enabled supplied and project-owned schema versions under OC1. It targets project configuration records, not reviewer-created annotation branches. Reuse common annotation infrastructure, not the existing annotation-target lookup model unchanged.

Schema/form authoring belongs in the project designer. Stages select validated subsets. Show the real question tree to administrators. A single schema renders as a fixed label with applicable metadata children; multiple schemas render a selector. Configuration-supplied answers have explicit provenance. New-project selectors can exist from the outset; enabling another schema publishes new question/set versions rather than silently restructuring submissions.

Legacy compatibility preserves existing forms through an explicit fixed-schema binding; do not automatically add selector answers to old submissions. Enabling alternatives requires a separate versioned upgrade. Metadata answers describe result fields; the actual numeric values are entered in Experiments. A schema change with existing results requires explicit resolution and preserves historical values. Repeatable schema selection is deferred.

Use SyRF's light theme, project/stage configuration navigation and study-review shell. Mark proposed controls “New”; use readable question trees and interactive configuration, not blank sections or readonly cards pretending to be designers. No production calls.

Project configuration: question library, question-set versions, screening profile editor with screening questions, agreement settings and decision/reason presentation.
Stage configuration: add/edit review steps, select existing profiles/question sets, configure dependencies separately from display order, compulsory steps, collective satisfaction, terminal behaviour and allowed existing-work completion. Targets/sufficiency are shown from the referenced project forms, not copied onto each step.
Study selection preview: choose a synthetic reviewer and study; show eligible work and why other work is absent. Designer/debug view may expose all outcomes; ordinary reviewer views must respect blinding and must not automatically reveal other votes or pool membership.
Reviewer session: one reusable form area driven by the selected step, step statuses, autosave versus explicit Save (immutable incomplete) versus Complete (immutable completed), Exclude where applicable, safe switching without losing edits or duplicating form sessions. Auto-advance is optional; independent steps can be visited in either order.
History/correction: prior submissions, correction drafts, exact evidence revisions, pending updates and surplus-status history. No destructive replacement animation.

Worked scenes for the prototype:

TA screening followed by combined FT screening/extraction; TA Exclude ends the dependent route.
An independent diabetes decision that does not stop a separate study-information form.
Study facts form, then screening, then outcomes form: later exclusion does not undo earlier facts.
Two independent annotation forms with targets two and one; show separate progress counts.
One form opened through two stages: one reviewer session and one shared-target contribution; annotation authoring provenance survives reuse and each submission records its workflow context.
Overlapping forms share compatible answers, but the form with extra required questions remains incomplete. Autosave preserves current status; incomplete correction Save becomes current and removes completed qualification. Complete restores one completed contribution, retaining history.
A step shows accepted gold under its visibility policy: exact shown revision is recorded, progress includes the completed informed work, and agreement distinguishes it from independent work.
Collectively Included TA lets an unvoted reviewer enter FT when configured, but not a reviewer with an existing personal TA Exclude. No duplicate screening question/vote is created.
Two prior profiles resolved Included; a third extraction-only step offers annotation or Skip, not Exclude. Alternatively link a distinct final-assessment profile to that third step.
Collective Exclude arrives during extraction: policy-controlled completion, preserved draft, annotation-only surplus submission, later eligibility restores its qualifying status.
Autosaved corrections leave the explicit current version intact; incomplete Save removes completed qualification and Complete restores it. Show separate draft changes and publication treatment.

Follow-up acceptance scenes for version updates and query review¶

Publish requireReanswer with reason/guidance supplied: old invalid answer remains visible as Needs updating, guidance is shown, Complete requires a valid replacement and history survives.
Leave reason/guidance blank: missing reason warns but publishing can proceed once the existing stats/admin-impact gate passes. Missing guidance is not a separate publication block.
Two viewers challenge the same accepted version: one work item, two retained concerns; accept one and reject the other without a mandatory rejection explanation. Each receives only their permitted resolution content; authorisation and candidate isolation remain enforced.
Approve a parent correction that invalidates a child: keep the old gold effective and pending flagged while resolving the child; publish a new snapshot only when all affected values are valid.
Permitted self-review is recorded in query audit; initial reconciliation eligibility stays intact.
A replacement accepted answer demonstrably satisfying one concern closes that concern as addressed by update, records the resolving version and notifies its author. Other concerns keep the grouped work open; uncertain satisfaction is routed to manual review. Unsatisfied concern handling and concurrent races remain unresolved, without silent retargeting.

These scenes follow the minimal shared-form journey; query review is a later slice whose confirmed behavior is specified now. Publish-pause queued retry UX is only a recommendation.

Prototype acceptance and open decisions¶

The first usable slice must make project/stage/session ownership visible, permit configuring two steps and using one shared form across two stages, and demonstrate the personal-plus-veto selection rule. Show one reviewer contribution toward the shared form target, revision provenance, autosave, incomplete Save, completed versions and correction effectiveness. Form publication must show current version-aware usage and the required admin transition choice before proceeding. All demo buttons should have clear local effects; simulate the publication gate without claiming that production statistics infrastructure has been implemented.

Follow-up scenes must demonstrate no lost work, no duplicate voters, separate contribution targets for different forms, explicit collectively-satisfied status and versioned corrections. A diagram or JSON inspector may show logical records, but collection names and class inheritance are not final.

Shared form sessions/targets are confirmed, not open items. Open items must be visibly labelled, not silently decided by the prototype:

Category-specific application and confirmation UX of recovered requireReanswer/autoUpdate/ doNothing choices: compatibility, adoption, missing required questions and concurrency. FV1–FV3 already confirm the prompt and admin-controlled counting; do not reopen a universal count/does-not-count choice.
EW1 stage default Allow with advanced per-step override is settled; do not reopen placement.
Accepted-answer stale-version/concurrent resolution and queue/permission/notification mechanics; QY1–QY7 lifecycle boundaries are confirmed. Safe shared-draft concurrency/storage mechanics.
Publication-pause warning/queued-retry/action-needed UX remains a recommendation, not approval.
Publish-point statistics freshness protocol, relevant version-aware usage families and write fences, consistent affected identities and safe scoped-pause recovery; PS1–PS3's gate is confirmed.
Cross-stage propagation/concurrency and scientific profile-version evolution; personal-Include dependency policy is confirmed (DP1).
Exact allocation/reservation handling when one half of a combined step is sufficient.
DP2 approves own-history correction of personal Exclude if review remains possible, with access/admission enforced and no automatic re-invitation; exact controls remain design work.
Compatibility reassessment and concurrent submission rules; SF4/RE3 settles use of all qualifying assessments beyond the minimum target.
How blinding-compatible warnings communicate route changes without revealing other reviewers.
Finer action grant/delegation mapping and confirmation mechanics from the permission inventory. Existing query rights, additional-review capability and assignment behavior are settled. Compatible same-question/ context answer sharing is confirmed; precise compatibility/concurrency contracts still need design.

Sources and current implementation boundary¶

Owner decisions, 2 October 2026: latest confirmed shared form/session/target, provenance, lifecycle and visibility direction; remaining topics stay explicit. This supersedes conflicting per-step assumptions in older research snapshots.
Detailed screening research: code-grounded legacy analysis, profile identities, versioned annotations, allocations, reservations and rollout.
Integrated model: wider model; do not pull cohort classification or outcome-schema authoring into the minimal review-step prototype.
Earlier dependency comparison: alternatives explored; the within/across-stage choice and collective-satisfaction refinement above take precedence.
Question Management and Annotation Versioning: reuse transition design.
Screening Annotations: existing reconciliation planning; later choice/free-text and operational-veto decisions above revise specific defaults.
Review eligibility policy: do not conflate new-vote admission, selecting saved work, saving answers and completing annotation work.

Current code inspected in this research worktree: AnnotationSession.cs in the project-management core StudyAggregate has one status and filters annotations by stage, reviewer and reconciliation context. SessionSubmissionDto.cs carries one session answer set and a separate optional screening payload. Multiple step-level form submissions are a proposed extension, not an existing capability. Existing tests cited by the research verify legacy behaviour, not this prototype design.

Confirmed candidate match suggestions (MG1 / RD1)¶

Chris, 2 October 2026: SyRF should suggest matches between candidate entity and cohort entries by comparing labels and annotation answers, using an algorithm to find the closest matches. Suggestions are required in the proposed reconciliation experience; whether they should exist is settled. The reconciler can adjust and confirm matches, and original candidate entries and answers remain preserved.

Reuse v10 RECONCILIATION section 4.3 as the proposed implementation design: top-down matching, label overlap, choice-answer agreement and paired-parent context. Exact numeric weights and thresholds are not independently approved. No new sample-size heuristic or ML/AI requirement is implied. Suggestions must not automatically establish authoritative matches or publish gold.

Confirmed contextual-note preservation and attribution (NT1)¶

Contextual notes remain in their original candidate annotations and are never deleted by reconciliation. A reconciler may copy a note, but its original author and source attribution must remain clear; copying must not falsely attribute another reviewer's note to the reconciler. This does not require every contextual note to be synthesized into a gold-standard answer. Actual free-text annotation answers have their own reconciliation handling and are distinct from contextual notes. Preserve applicable candidate visibility and stage blinding rules.

Confirmed revision of published update requirements (FV4)¶

Chris, 2 October 2026: if an admin publishes a question/form update requiring reviewers to update or re-answer, then finds that requirement unnecessary, the admin can revise the impact/update requirement afterwards. Record the new policy decision in history. Preserve the original immutable question/form version, original transition history, candidate submissions and drafts; do not rewrite old versions or silently delete reviewers' work.

This confirms reversibility of the update requirement in that scenario, not unrestricted permission to declare semantically incompatible questions compatible. Reuse existing publishing/admin authority. Exact authorization mapping, concurrency, and effects on work already performed under the original requirement need design. Multiple-selection agreement is separately confirmed under AG2 below.

Confirmed multiple-selection agreement (AG2)¶

Chris, 2 October 2026: overall agreement for a multiple-selection annotation question requires exactly the same selected options (selection order is irrelevant). Differing selection sets are disagreement overall; show option-level overlap separately. For example, A+B versus A is disagreement overall, with shared option A shown as overlap.

This comparison retains question-version compatibility constraints and applicable entity identity rules. It does not specify a kappa formula, missing-answer handling or semantic entity identity. Those remain separate technical or policy rules. Agreement alone does not publish gold; final reconciliation acceptance and applicable profile-governed screening rules remain unchanged. This supersedes earlier statements that multi-select agreement was pending.

Confirmed cross-stage personal-Include dependency (DP1 / OD1)¶

Chris, 2 October 2026: a reviewer's own Include can let them proceed through a configured dependency into a later stage. Extend personal Include with collective-Exclude veto across stages as well as within a stage. Do not require collective Include by default for later-stage work. All other configured dependencies, permissions, allocation and eligibility still apply.

Reuse shared screening-profile evidence and pinned/versioned settings; do not silently merge different profiles. Collective Exclude stops new dependent work. Finishing previously saved work retains the confirmed stage default Allow and advanced per-step override (EW1). Propagation, concurrency and profile-version transition mechanics remain engineering details; they do not reopen this policy direction. A personal Include is not collective agreement or gold publication.

Confirmed minimum target and all qualifying candidates (SF4 / RE3)¶

Chris, 2 October 2026: the form target is minimum sufficiency, not a cap on evidence used in reconciliation. If the target is two and three eligible reviewers complete, reconciliation uses all three qualifying compatible effective reviewer assessments, not just the first two. Extra valid completed assessments remain useful.

Count each shared reviewer/form contribution once. Apply latest explicit current-version semantics (SL3), question/form-version compatibility and eligibility. An older Complete superseded by an incomplete Save is not a current completed contribution. Preserve separate independent/informed exposure reporting. Surplus work that becomes ineligible after exclusion is distinct from an additional qualifying assessment and is not automatically admitted.

Reconciliation UI must handle more than two candidate reviewers: annotation-answer comparison, candidate chips and source labels, entity/cohort match suggestions and confirmation, and outcome/series/time-point comparisons must not hardcode two reviewer slots or only compare the first pair. Use a scalable candidate list/selector or comparison presentation while retaining access to every qualifying candidate and clear source provenance. Preserve stable reviewer aliases and stage-owned identity blinding. This is a required design/implementation capability, not a claim the current prototype or runtime implements it. Exact layout remains design work. No automatic majority-gold decision or specific statistical formula is implied.

Delivery acceptance for multi-candidate reconciliation¶

With target two and three qualifying compatible completed reviewers, all three appear and are available throughout answer, entity/cohort matching and outcome comparisons.
A fourth candidate is accessible without truncation or fixed two-column assumptions; candidate selection does not silently discard other qualifying inputs or their provenance.
Matching groups can contain corresponding entries from all qualifying reviewers; adjustments preserve original candidate records and exact source revisions.
Independent/informed labels, stable aliases and blinding remain correct for every candidate.
A shared reviewer contributes once; incompatible, incomplete-current or ineligible assessments are kept distinct and do not inflate sufficiency or silently become reconciliation candidates.
Final acceptance, validity and the Complete-anyway exposure warning remain applicable; candidate agreement or majority alone does not publish gold.

Confirmed cross-form answer lineage and older-session flags (SF5; clarifies SF3)¶

Chris, 2 October 2026: for the same reviewer, study and question in the applicable annotation/entity/branch context, show the reviewer's own previously supplied answer and answers for all its ancestors, regardless of the stage or form where captured. Preserve exact ancestor/source context and original authored-stage provenance. QuestionId alone must not merge distinct repeated entities or branches. Compatible question-version constraints still apply. If legacy duplicate answers conflict, show prior own answers with conflict indicators rather than silently selecting the latest duplicate.

The reviewer may change the answer. Explicit submission creates a new immutable answer/version set and establishes the reviewer's new current confirmed answer version. Preserve SL3: explicit Save is current but incomplete, Complete is validated and completed, and autosave alone is unconfirmed draft work. Preserve older immutable answers and session references.

When changing shared responses, alert the reviewer that a new version is created and that other affected sessions containing older answer versions will show contains outdated annotations. Flag every other existing session referencing a previous version of any affected answer. The reviewer chooses whether to Fix; resolution is not mandatory by this decision.

Choosing Fix deliberately creates a new incomplete session version and opens that affected session's own annotation form, retaining its form/entity/branch context. This is an explicit transition, not an autosave-only change. The prior complete version remains immutable history; the new incomplete version is current under SL3 and no longer counts as a completed session. Do not mark the entire stage incomplete automatically: this decision concerns that session.

The reviewer updates the form and answers dependent questions made changed or required by revised responses. Complete is available when sufficiently valid with dependencies handled; subsequent explicit Save/Complete follows the existing immutable-version lifecycle. Fix is not merely swapping revision references silently. Preserve original session/annotation versions; autosaved drafts are not auto-confirmed. Do not claim the session fixed while required validity/dependency work remains unresolved.

Do not silently rewrite pinned references or automatically adopt new answers. No automatic migration, mandatory resolution, new target-counting policy or gold change is approved. SF6 confirms that warning alone preserves current Complete qualification; a recorded action/policy creating a current incomplete version removes it. Concurrency remains engineering work. This is answer-version lineage and cross-session flags, not publication of a new question definition or a replacement for the FV1–FV4 publication-impact policy.

Delivery acceptance for cross-form answer reuse¶

A question opened in another form/stage shows the reviewer's prior own answer and all ancestor answers in the matching entity/branch context, retaining source provenance.
An identical QuestionId under a different repeated entity/branch remains separate; legacy conflicting duplicates are visible and flagged rather than silently collapsed.
Explicit Save/Complete creates a new immutable set under SL3; autosave alone does not establish a new current confirmed version or publish gold.
Changing shared responses warns of the new version and affected sessions' contains outdated annotations warning. All sessions pinning superseded affected answers retain exact history.
Choosing Fix explicitly creates a new current incomplete session version and opens its own form/context. Revised answers' changed or required dependent questions must be handled; silently swapping references is not a fix.
Resolution through explicit Save/Complete creates a new immutable session version under SL3; unfinished invalid/dependency work is not presented as fixed or completed. Autosave is draft.
No implicit adoption, deletion, forced resolution or automatic gold/counting change occurs; SF6 confirms current Complete still qualifies despite the warning alone; concurrency is engineering work. Choosing Fix follows the confirmed current-incomplete counting rule, without a stage-wide status change.

Current outstanding-question inventory¶

See the reconciled outstanding questions. It separates remaining owner choices, engineering contracts and UI/prototype validation; source-register Open labels do not override later confirmed decisions.

Confirmed concerns addressed by a replacement answer (QY8)¶

When a new accepted answer demonstrably satisfies a concern's proposed correction, close that individual concern as addressed by update, record the resolving accepted version and notify its author under the existing visibility/privacy rules. Keep the grouped work item open if other concerns remain. Uncertain satisfaction requires manual review; do not infer that every concern is resolved merely because the accepted version changed.

QY9 settles concerns not clearly satisfied by replacement: preserve original target/version, keep open and flag current applicability for the assigned reviewer, without silent retargeting. Concurrent replacement/resolution races remain engineering work. This specifies notification behavior, not authorization to send messages during documentation work.

Confirmed completion qualification with outdated-answer warnings (SF6; resolves P16)¶

Chris, 2 October 2026: if the current session version is Complete, it continues to count as completed despite a contains-outdated-annotations warning. The warning alone does not create an incomplete version or remove completion qualification. Preserve applicable compatibility/eligibility and the admin's recorded publication-treatment policies.

If reviewer action (including choosing Fix) or an applicable recorded admin update treatment creates a new incomplete session version, that version is current under SL3 and the session no longer qualifies as completed. The reviewer must Complete a sufficiently valid replacement to restore qualification. Prior completed versions remain immutable history. This does not authorize every shared-answer change or admin action to automatically create incomplete versions; triggers and mechanisms follow the particular recorded action/policy. No whole-stage status change is implied.

Confirmed deliberate correction of own screening Exclude (DP2; resolves P1/OD3)¶

Chris, 2 October 2026: if reviewing is still possible on that session, the reviewer opens the study through their own review history, chooses correction of their own screening decision, changes personal Exclude to Include and submits a new immutable version. Preserve original Exclude history and re-evaluate screening and dependent eligibility under applicable rules. This is a deliberate correction route, not automatic re-invitation.

Current access, admission and permissions remain enforced; this does not override a closed or restricted stage. To challenge an accepted reconciled decision, use the established query process, not direct replacement of gold. Exact button wording and implementation remain design work. DP3 separately confirms rule-derived individual decisions on explicit submit.

Confirmed rule-derived individual decision on submit (DP3; resolves P2/OD8)¶

Chris, 2 October 2026: a rule-derived individual screening decision is confirmed on explicit submission together with the relevant submitted answers. For a profile excluding nonrandomized studies, answering Nonrandomized shows a proposed Exclude; the field change or autosave does not commit a screening vote. Submission confirms the displayed derived decision and applicable answers without separate per-answer confirmation clicks.

Show reasoning for the proposed Include/Exclude: identify the triggering screening criteria and the reviewer's already-supplied question answers, not merely a calculated decision label. Keep rule/question versions pinned in the existing provenance. This explanation uses permitted own-answer context and must not expose other candidates' answers or bypass stage blinding.

Keep this individual candidate decision distinct from profile-governed collective agreement, reconciliation and accepted gold. Preserve applicable permissions, admission, validation, profile/question/settings versions and provenance. Exact UI and command implementation remain engineering/design work; this does not authorize a runtime change.

Confirmed screening-profile question ownership (DP4; resolves P3/OD7)¶

Chris, 3 October 2026: screening-profile questions express eligibility under that profile's criteria. Their role and scope are distinct from ordinary study-fact annotation questions. Define the screening questions and their actual configuration alongside and within the screening profile itself; do not select ordinary project study-fact questions as implicitly shared screening criteria.

Questions may be imported/copied from reusable templates. Importing into two profiles does not share their actual configuration or answers; later template changes must not silently change either profile. Several stages referencing the same profile share its profile-scoped answers and decision/reason histories, subject to pinned versions and existing compatibility rules. Different profiles remain separate, even with identical template text.

Reuse the question-tree editor, answer types and infrastructure without changing semantic ownership. Ordinary study-fact annotations retain the established same-context cross-form/ cross-stage sharing, ancestor lineage and version rules. The earlier recommendation to select ordinary project questions as screening questions was too broad and is superseded. Older text saying all question definitions remain generic project assets must be read with this explicit profile-owned exception; physical storage design is not prescribed by ownership.

Delivery acceptance¶

Editing a profile exposes its own eligibility-question tree/configuration alongside criteria.
Two profiles importing one template have independent configurations and answer histories; editing a template does not silently alter an existing profile.
Two stages using the same profile reuse its profile-scoped answers without duplicate votes.
Matching wording does not merge ordinary study facts with profile eligibility answers, or answers across separate profiles. Original profile/version/source histories remain preserved.

Recovered screening decision versus supporting-answer resolution (RX1; P4/X3)¶

This is recovered documented behavior, not a new blanket owner approval. The handover's Agreement and adjudication section, earlier FEAT-009 research and supplied v10 RECONCILIATION settings already distinguish decision agreement from required supporting-answer agreement. The profile defines which screening answers must agree for automatic resolution and whether manual review remains mandatory. Choice-answer agreement is the documented default; free text is supporting evidence unless explicitly selected for matching. Unchecked text stays attributed, not automatically an agreed authoritative answer. Derive only agreeing branches when profile rules permit authoritative derivation, retaining every original candidate branch.

Example: two reviewers submit Exclude with conflicting eligibility reasons. The decisions agree, but reasons selected for agreement still require the profile-configured reconciliation. A collective Exclude can veto new dependent work while that reason reconciliation is pending; this does not pretend that reason reconciliation has completed. Ordinary study-fact form reconciliation is independent, subject to its own configured eligibility and authority. An extra vote resolving decision disagreement does not silently resolve supporting-answer conflicts. No invented reason or candidate deletion is permitted.

Source/prototype audit, 3 October 2026: supplied RECONCILIATION.md settings (lines 29–30) include “When decisions agree but a Must agree answer differs”; its decision comparison (lines 78 onward) includes these answers. The supplied Review Form v10.dc.html coll function (lines 1377–1378) calculates collective status from decision values and counts only; it does not demonstrate the full supporting-answer reconciliation contract. Thus remove the generic P4 owner question as already documented; full-flow implementation/validation and technical work-item/claim mechanics remain. This source inspection is not runtime or live-prototype verification.

Chris's presentation clarification, 3 October 2026: when configured profile rules require supporting screening-answer reconciliation, present it as part of reconciliation of a stage containing/using that profile. The stage workspace presents shared profile-scoped work; it does not create independent accepted answers or duplicate authority for each stage. Do not retain the generic placement question as open. RE4 separately confirms the study/form reconciliation task; technical claims/locking and compatibility remain engineering work.

Confirmed profile exclusion-reason reconciliation toggle (DP5; resolves P5/RC9)¶

Chris, 3 October 2026: the screening profile has an on/off setting determining whether exclusion reasons need reconciliation. When enabled, applicable reasons require reconciliation under the configured profile rules. When disabled, there is no exclusion-reason reconciliation requirement; preserve recorded candidate reasons and their history. Screening decision resolution remains separate and follows its own profile rules.

Earlier handover/FEAT-009 research already located reason agreement/reconciliation configuration at the profile and distinguished it from decision resolution. DP5 confirms the explicit toggle; the generic P5 question is no longer open. This does not approve a hard dependency preventing reason reconciliation On when collection is Off, or forcing a change to another setting. Handling that combination and missing/not-collected reason inputs needs precise configuration/ engineering design. Do not invent a mandatory blocking gate, missing reasons or an authoritative reason merely from turning reconciliation Off. Preserve DP4 ownership, shared profile authority, RX1 stage-workspace presentation, versioned settings and original candidate data.

Confirmed shared form reconciliation task (RE4; resolves P6/RD4)¶

Chris, 3 October 2026: one reconciliation task for a given study and annotation form is accessible through any stage using that form. Record the exact form version and candidate answer versions used. Completion satisfies that form's reconciliation requirement across stages using compatible pinned versions/inputs, not unrelated stage or screening-profile work. Later input or requirement changes can require an update; preserve earlier results/history.

Screening-profile reconciliation is a separate part of the workspace, retaining its shared profile-scoped authority. Overlapping forms retain shared question gold: do not create duplicate accepted-answer authority or competing gold simply because another form/stage presents it. Exact task identifiers, claims/locking, concurrent updates and compatibility mechanics remain engineering work. The shared study/form task unit is approved, not awaiting another owner choice. RE5 separately confirms actual free-text exact-match prefill and manual accepted answers, distinct from contextual notes.

Confirmed actual free-text answer reconciliation (RE5; resolves P7/RD6)¶

Chris, 3 October 2026: the reconciler answers an actual free-text annotation question as with other annotation controls. Agreement-based prefill requires exactly matching text among the relevant compatible candidate answers, with the same question/version/entity/branch context. When text does not match exactly, there is no agreement match and no automatic candidate- agreement prefill; the reconciler supplies or chooses the accepted response.

Preserve all original candidate answers, authors and source/version provenance. No fuzzy or semantic match, synthesized prefill, or whitespace/case normalization is approved by this rule. A candidate mismatch must not erase already accepted gold or a reconciler's saved draft: this specifies agreement-based prefill, not destructive reset of existing work.

Actual free-text answers remain distinct from contextual notes (NT1), whose original source attribution is preserved when copied. Ordinary form exact-text agreement does not change screening profiles' supporting-free-text default unless explicitly selected for matching. RE2 still requires obvious autofill marking and the unseen-control warning with Complete anyway; no mandatory per-field confirmation or gold publication merely from agreement.

Delivery acceptance¶

Relevant compatible candidates with identical actual text can prefill an otherwise applicable reconciliation control, with original source provenance and visible autofill indication.
Differing text produces no agreement-based prefill; candidate text remains available for the reconciler to answer/choose without fuzzy equivalence or synthesized values.
Existing gold and saved reconciliation edits survive differing candidate inputs.
Contextual notes and profile screening evidence retain their distinct rules and attribution.

Confirmed first-release outcome schemas and project customization (OC1; resolves P8/OD9)¶

Chris, 3 October 2026: the first outcome-schema release includes a legacy-compatible schema so existing projects' extraction data can be mapped during migration, an event-count schema, and the ability to create/customize a project outcome schema. This supersedes the 27 September system-catalogue-only restriction on first-release project authoring. Retain the existing project-owned configurable/versioned schema design alongside selectable supplied schemas; stages bind validated versions rather than independently changing structure.

Requested configurable-field examples are numerator/denominator, value range, confidence interval, standard error and variation. They are examples for customization, not a third fixed schema requiring every field simultaneously. “Variation” has not been defined as variance or standard deviation. Field meaning, series versus observation scope, data types, validation, requiredness and precise event-count structure need domain/engineering specification; no numeric formulas are approved here. Preserve compatible schema references and existing outcome-entry behavior and source/version provenance.

The legacy-compatible schema permits mapping existing data; this does not approve automatic migration or settle P9 adoption/upgrade policy. Do not reinterpret historical results or invent missing values. Full advanced semantic mapping and additional catalogue breadth can be phased, but supported project creation/customization is confirmed for the first schema release, not an optional deferred capability. This is documentation scope, not runtime/migration authority.

Outcome migration deferred; outcome-direction placement confirmed (OC2)¶

Chris, 3 October 2026: P9 migration/adoption policy will be planned in more detail in a separate dedicated session; it still needs confirmation. This is deferred, not resolved or authorization for automatic migration. No new session is created by this documentation work. The OC1 legacy-compatible schema supports mapping, not an approved migration execution policy.

P10 placement confirmed: “greater is worse” belongs on the outcome measure as versioned interpretation metadata, not on a stage or generic numeric outcome schema. Do not derive its direction automatically from numeric type, or use it as a numeric validator or treatment-effect claim. Preserve outcome-measure definition/version provenance. Conditions under which a context-specific value/override may differ remain unapproved; the coordinator's scoring/context recommendation is not an owner decision. The remaining P10 question concerns those semantics, not where the metadata belongs.

Recovered automatic/manual stage lifecycle (RX2; narrows P11/OD18)¶

Prior-design audit, 3 October 2026: the supplied SyRF Prototype v10.dc.html explicitly includes automatic/manual completion configuration. At line 2583, automatic mode says the stage completes when all studies are resolved and reopens when more studies are added; turning it Off returns completion to manual. Do not reopen that already-described new-study behavior or substitute a blanket keep-closed policy.

At line 2536, Completed is described as closed to new review sessions, with settings/form bindings frozen, submissions pinned and drafts preserved, recorded as a status event. Reopening records another event, retains the earlier completion and leaves settings unchanged unless edited. Lines 2579–2585 expose completion/reopen controls and completed-state editing restrictions. IMPLEMENTATION_PLAN already includes stage lifecycle/reopen. Preserve these recovered baselines; do not invent a separate reopening permission without existing-authority mapping. These are prototype design/local-state messages, not verified runtime lifecycle events or proof an automatic new-study watcher has been implemented.

What the inspected design does not specify precisely is whether/how existing draft completion or corrections that make a previously resolved study unresolved are permitted or trigger reopening while the stage is Completed. Retain only these narrow remaining P11 questions; map authority and event/concurrency mechanics to existing stage-admin/access rules as engineering work. Preserve SL3/SF6 session-version qualification and recorded publication policies; a session correction does not automatically change whole-stage status merely by analogy. Automatic/manual completion and new-study reopening are not awaiting a new choice.

Confirmed project groups and scoped capability design (PM1; narrows P12/RD8/OD6)¶

Chris, 3 October 2026: workflow actions, including assignment, release and expiry, should be grouped into specific permissions. Inventory every proposed capability, refine the matrix and explicitly determine which actions merit separate grants; do not imply them from role labels. Project membership groups are configurable: administrators can create project groups, assign members and grant groups specific permissions, some project-scoped and some stage-scoped. Present this under project membership/groups with permissions subsections. Reuse the existing documented group/grant architecture; configurable groups are not unresolved.

Non-admin pool/held/correction context follows the relevant explicitly granted scoped permissions, not universal answer visibility. Having a capability is distinct from configuring or granting capabilities; permission-administration authority must be checked independently. Ordinary administrators should have most/all ordinary project permissions by default, but ownership transfer is expressly excluded from a blanket admin default. Verify existing owner-only actions before defining the exact default set; that complete set is not approved.

Read-only catalogue check: inspected ResourceSecurity.json ChangeOwner (lines 52–57) permits the project owner, with empty allowed project/application group lists and no all-member or all-user allowance. Its AssignPermissions entry likewise permits the owner in the inspected catalogue. This is evidence to map safely, not proof ordinary admins already have every proposed administration action. Do not silently expand owner-only actions through a default-admin label. Precise grants/scopes/default matrix and technical mappings still need refinement; generic configurable-group existence, placement and explicit-grant direction are settled.

Confirmed unsatisfied concern after accepted replacement (QY9; resolves P13)¶

Chris, 3 October 2026: when a replacement accepted answer does not clearly satisfy a concern, keep that individual concern open with its original target/version link. Additionally flag it for its assigned reviewer to check against the current accepted answer. The reviewer determines current applicability; do not silently retarget, delete or close the concern merely because the accepted version changed. Preserve the historical concern and per-concern grouped outcomes/provenance.

Example: accepted sample size 20 was queried with proposed correction 24; replacement 22 does not clearly address the request. Keep the original 20-target concern open and flag current 22 for review. If a concern is genuinely demonstrably addressed, QY8 still permits individual addressed-by-update closure with resolving-version history and author notification. Concurrency, assignment/current-applicability review mechanics remain engineering work; generic replacement policy is now confirmed. The later AG3 and EX2 decisions below supersede the earlier broader P14 scope; only literal missing-state comparison and denominator handling remain open.

Confirmed N/A and compatible-question-version agreement (AG3; narrows P14)¶

Chris, 3 October 2026: two explicit Not applicable answers agree; Applicable versus Not applicable disagrees. Compatible differing question versions may be compared for agreement/ disagreement, but must be clearly flagged as different versions. A separate result class is a possible presentation, not an approved mandatory statistical split. Do not automatically compare incompatible versions. Preserve exact question/source versions and independent/informed exposure.

This does not define literal missing-versus-missing agreement, unanswered/not-reported handling or their denominator treatment. Do not infer agreement or approve excluding those records by analogy with N/A. These are the remaining narrow P14 choices; formulas and temporal query/ manifest mechanisms are engineering work, not reopened historical-availability questions.

Confirmed available-history download scope (EX2)¶

Chris, 3 October 2026: downloads should include whatever historical review data the database actually supports, including pre-migration data where recoverable. No arbitrary date or retention- length cutoff is approved. Limits reflect available recoverable history, not invented versions. Keep EX1 current-by-default and reproducible as-of history. Do not fabricate snapshots or revision lineage for legacy records without that evidence. Requested as-of instant/timezone interpretation, consistent reconstruction and manifests need engineering specification; this is not approval of runtime querying/migration, nor proof existing historical modes are implemented.

Confirmed existing-type templates and feature-required types (TC1; resolves P15/X2)¶

Chris, 3 October 2026: default reusable templates to already-existing entity types, including legacy disease model, disease-model intervention and treatment, to support mapping legacy projects into the shared domain. Validate the existing catalogue and names/aliases; these examples are not an invented exhaustive list of all type definitions or semantic mappings.

Required system types such as cohorts, outcome measures and experiments are applied when the relevant extraction/export feature is used by an annotation form. They are not universal required types for every project. Preserve existing project-defined types, versioned form/type bindings and ordinary shared annotation infrastructure.

Prototype audit: SyRF Prototype v10.dc.html line 485 distinguishes system templates from project types; lines 2007–2012 show type groups and templates for Disease model (labelled legacy Disease Model Induction), Treatment and candidate Index test. Lines 2305 and 2510 describe form data extraction adding Cohorts, Outcome measures and Experiments with system questions. This supports the default/template and feature-dependency design, not an exhaustive verified catalogue or runtime legacy mapping. Chris's disease-model-intervention wording must be checked against existing legacy identities, not silently renamed to Induction. Catalogue/dependency/alias checks remain engineering/domain verification. The generic template-promotion owner question is settled.

Latest confirmed direction and concrete approval proposals — 3 October 2026¶

This section supersedes earlier deferred/open wording for P9–P14 where stated; original source prototype and historical discussion are retained, not rewritten as implemented behavior.

LC1 / P11: automatic completion requires no unresolved applicable work, including drafts and outstanding corrections. Alert project admin and obtain confirmation before admitting a change that would reopen a Completed stage. Commit approved change then auto transition in automatic mode; manual mode requires explicit reopen/switch-off. Preserve new-study auto reopening under this gate, current Complete counting until actual incomplete-version action, autosave/draft distinction and history. Precise approval/concurrency/draft routing is proposed, not a newly approved permission or spontaneous reopening.
UA1 / P14: required applicable questions cannot be omitted in completed candidates; optional unanswered questions can be decided by the reconciler. Blank is not N/A. Configurable all-applicable-gold completeness was suggested; project/form scope/default and statistical missing/Unknown comparisons/denominators remain approval proposals. AG3 N/A/version and EX2 available-history decisions stay settled; Complete anyway never waives answer validation.
PM2 / P12: project owner can assign permission administration to a membership group; authorized members administer/delegate within approved scope. This deliberately extends currently owner-only AssignPermissions. Ownership transfer remains owner-only. Proposed owner-reserved delegation-envelope administration/non-recursive delegation boundaries are explicit recommendations. Possessing a grant never means administering it. Group template names/bundles are implementer discretion after complete action inventory, not owner blockers.
ODIR1 / P10: one versioned outcome-measure direction across cohorts in a paper/population; no context override. Genuinely different meanings require separate measures. Earlier open override proposal is superseded; retained conflicting legacy values require reviewed mapping.
MIG1 / P9: drafting outcome migration/adoption plan is now authorized, superseding deferred planning status. Execution, activation and live migration remain unauthorized.
IP1: concrete implementation planning authorized, not runtime code. Major product choices are covered; review remaining exact proposals before implementation instead of reopening them.

Reviewable standalone documents:

All are planning deliverables. Approval choices are marked; no default/grant, data conversion, statistical formula, production lifecycle behavior or source-prototype update is claimed.

PRISMA integration review required before implementation approval — 3 October 2026¶

Chris requested existing PRISMA plans be integrated. The prior package approval request is superseded. The PRISMA compatibility comparison identifies existing binding source constraints, verified local gaps and current PR overlaps; the revised implementation plan, permission matrix and migration plan now include phase dependencies, unit/authority boundaries and regression gates directly. Original Approved source specs are not silently changed. Explicit A–F recommendations cover personal admission vs collective authority, report/Citation multiplicity, conflicting source-column queries, reviewed dedup, pending reason coverage and coherent historical report provenance. Existing product decisions remain preserved. No runtime/migration/grant changes are authorized.

DP6 — current cross-stage correction (supersedes DP1 cross-stage extension)¶

Chris, 3 October 2026, during PRISMA integration: personal Include with collective Exclude veto applies to steps within the same stage. Between stages, route availability should be configurable. Proposed choices are Collective Include required versus own Include sufficient; collective Exclude veto, permissions/allocation and independent gating remain. DP7 confirms default Collective Include required, with advanced own-Include option; collective Exclude veto retained. Record this as a change of direction, not a denial of earlier DP1 confirmation. Older blanket personal-Include cross-stage language in historical sections is superseded. Keep within-stage personal work, cross-stage routing and PRISMA collective report authority separate. Cross-stage default is settled under DP7. Review strict within-stage proposal and PRISMA amendments before implementation approval.

DP7 / PR1 — confirmed cross-stage default and collective reporting¶

Chris confirms cross-stage default waits for collective Include; advanced own-Include access is allowed with collective Exclude veto. Within-stage default remains own Include. Optional strict within-stage collective gate needs design; its exact inheritance/override/unfinished-work handling is proposed in the access-policy document. PRISMA reports collective authoritative outcome: Excluded stays Excluded even when extra review/ annotation work was completed under earlier access. Preserve that work and provenance. This settles DP6's pending default, superseding provisional package wording; no runtime approval follows.

SET1 — requested optional setup and template scope¶

Chris requests default screening-profile templates, an encouraged editable initial annotation form, ordinary annotation question-library selection and optional guided preclinical admin setup. Exact contents/steps remain proposals. The setup plan uses existing category editor/import/version/publication machinery and PRISMA dependency contracts; profile templates copy into profile-owned eligibility definitions, never shared ordinary facts. The implementation sequence now includes these deliverables; no runtime implementation implied.

SET2 — existing wizard replacement correction¶

Chris clarifies guided setup replaces the existing CreateProjectWizard/ProjectSetup workflow, not an additional parallel wizard. Current entry/component/checklist inspected; the setup plan now maps retained fields/routes/commands, feature gates and explicit retirement/parity checks. Exact robust replacement UX/content remains proposed; no runtime changes authorized.

OPS1 — existing operations and overview/settings integration¶

Chris requires existing/ongoing materialized statistics, allocation, active-work tracking and batching to be integrated, plus project/stage overviews and project/stage/step settings for shared forms/steps. Operational integration map records inspected source contracts/active PRs, amendments, parallel lanes and join gates. Existing programmes/PRs remain owned; no changes, activation, arbitrary new metrics or extra agents authorized.