Owner decisions from 2–3 October 2026¶

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.

This is the authoritative decision overlay for the interactive review of the Claude Design v10 handoff. The entries explicitly marked Confirmed record Chris's direction on their stated dates. Recovered baselines are separately identified. Recommendations, proposals and remaining questions are distinguished below. The document's In-Review status does not undo the individual confirmed decisions or approve all implementation details. This is planning only; it does not authorize runtime changes, migration, activation, merge, deployment, external review or sending notifications.

This record supersedes earlier per-step submission/target recommendations in the review-step handoff and comparison. Those documents should use this overlay when reading historical research and the unchanged supplied v10 pack. Do not ask Chris to reconfirm shared form sessions or form-owned targets merely because the old register labels OD14/OD19 Open.

Confirmed decisions¶

ID	Owner decision	Boundary
SF1 — shared form evidence and session	An annotation form is a project-level evidence/requirement owner. One reviewer-owned form session for a study is accessible through any stage using that form. Stages/steps govern workflow, access and order; they do not create duplicate form evidence or sessions.	Form/version compatibility boundaries remain to specify. This does not pool incompatible requirements or remove workflow permission checks.
SF2 — shared target and sufficiency	The form owns its review target. A study satisfies that target across stages using the form. One qualifying reviewer contributes once to that shared target, even after opening/submitting through two stages.	No per-stage/per-step duplicate target. Corrections and retries do not create additional reviewers. Qualification after version changes follows FV1–FV3, not automatic incompatible-version pooling.
SF3 — overlapping forms	Compatible answers to the same question in the same context are shared even across overlapping forms. Each form still has its own requirements and completion state; additional questions can make one complete and the other incomplete.	Share annotation identity/revisions, not an assertion that completing one form completes every overlapping form. Context/question compatibility remains mandatory; SF5 adds ancestor reuse and flags for other sessions pinning older affected answers, without automatic adoption.
PV1 — annotation revision provenance	The annotation revision itself records source stage/step, exact stage-settings version and question version under which it was authored, plus the accepted answer version actually shown where applicable. Reuse retains this original provenance.	Source stage is provenance, not annotation ownership. Sessions/submission versions also capture workflow context and the revisions submitted together. Allowed visibility alone does not prove exposure.
PV2 — stage requirements	Stage settings are versioned, bind profile/form versions, and historical work pins its requirements.	Live access and current eligibility still need re-evaluation. Publishing does not rewrite prior work. The exact adoption and compatibility transition is not yet decided.
GS1 — accepted snapshot	Gold standard is a versioned snapshot per study referencing exact reconciled annotation revisions. Approved changes create a new immutable snapshot retaining unchanged revision references.	Session context records the snapshot available; each answer's provenance records accepted evidence actually shown. Snapshot identity/current selection/storage mechanics remain engineering design.
SL1 — autosave	Autosave preserves draft changes/history without creating an explicit saved/submitted session version on every edit.	The storage/event representation and event granularity are not settled by this decision. Do not label every draft edit as an incomplete session version.
SL2 — Save and Complete	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.	Autosave, Save and Complete are distinct. Save/Complete behavior does not invent a screening vote; combined completion follows separate screening admission rules.
SL3 — current explicit version (corrected by Chris, 2 October)	The most recent explicit Save OR Complete is current. Saving an incomplete correction replaces a completed version as current, so that session no longer counts as completed. Autosaved edits alone do not supersede the current explicit version.	Previous versions remain immutable history. Distinguish current completed, current saved incomplete and draft-only sessions, with a separate draft-changes indicator. Count one session/reviewer, not versions or drafts. This supersedes the earlier effective-completed-until-Complete assumption.
VS1 — accepted-answer visibility	A step-level “show reconciled answers to candidate reviewers” policy has a stage default, allowing the same form to serve independent or informed workflows. Own previous answers remain accessible; other candidates' individual answers remain hidden.	Accepted gold visibility is configurable; the earlier always-show proposal is qualified by this policy. Existing grants/access still apply.
VS2 — statistics and exposure	Agreement statistics distinguish independent answers from contributions made after viewing accepted answers. Ordinary progress still counts qualifying work in either workflow. Record the exact shown version.	Being permitted to see gold is not evidence it was shown. Do not silently treat informed answers as independent observations or exclude them from ordinary progress solely for being informed.
EW1 — existing saved work	Stage-owned default Allow completion of previously saved work after collective exclusion, with an advanced per-step override. Preserve-only remains the alternative; preserve drafts in either case.	Placement is now confirmed, superseding earlier open stage/form discussion. It does not permit new work, invent votes, override personal Exclude/permissions or set behavior after sufficiency changes.
FV1 — new requirement version	Adding a question creates a new annotation form version.	Original requirement/submission versions remain immutable; publication does not silently mutate previous submissions.
FV2 — publish-time session check	On publishing the new form version, automatically check 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.	Include shared cross-stage uses and show effects for drafts and completed contributions. Application/confirmation of recovered requireReanswer/autoUpdate/doNothing choices, compatibility/concurrency and migration mechanics remain to design.
FV3 — transition-dependent counting	Whether earlier completed sessions count toward the updated form requirements depends on the admin's publish-time choice.	No universal hard-coded count/does-not-count rule. Transition policy is distinct from question-level answer compatibility; incompatible answers are not approved for reuse. Preserve original provenance and versions.
PS1 — usage evidence	Use materialized statistics for existing reviewer/form-session usage for each form version, and question-level usage/statistics with version awareness as appropriate.	Shared sessions/reviewer contributions are counted once across stages. Aggregate counts establish impact, not the actual identities to transition.
PS2 — current-at-publish gate	Before publishing a new form/question version, verify relevant materialized statistics are current at the publish point. If stale, wait for catch-up or actively update the specific relevant statistics there and then. If necessary, briefly pause reviewing to make them current.	Design direction only: no live pause, statistics implementation or resumption of the separate statistics task is authorized. Missing/stale statistics are not confirmed zero usage.
PS3 — publish prerequisites	Publish only once required statistics are current and the required admin handling choice for affected sessions is recorded.	Currentness must survive concurrent writes through the publish boundary; engineering must propose the actual safe protocol. No timestamp-only race is approved.
RA1–RA5 — pool, assignment and extra review	Pool default; optional eligible individual assignment; stage expiry default and audited override for unstarted explicit work only; started release/reacquire; independently requested extra review after target.	Request an additional review requires its own capability; no implicit reconciler grant, target change or automatic gold. Normal pool tracking is not assignment expiry.
EX1 — reproducible downloads	Current answers by default; previous versions and date-specific review state downloadable, including gold/candidates as applicable.	Recovered code is not proof historical modes ship; existing authority and visibility apply.
AG1 — agreement-statistics access	Separate view capability grantable without admin control; not implied by Reconcile.	No candidate-answer visibility or identity-blinding bypass; verify/reuse suitable existing stats-view mapping.
RE2 — reconciliation form acceptance	Final reconciliation submission accepts valid displayed answers including matching prefill; obvious autofill indicator, retained source provenance and warning for unseen relevant controls.	No per-field confirmation or pre-submit gold promotion. Save/autosave unfinished; query child validity and profile screening rules preserved.
RE1 — reconciled explanation	Optional even when answer differs from every candidate; non-blocking reminder permitted.	No completion/publication gate; keep Reconcile and extra-review capability separate. EX1 confirms current/historical downloads.
BL1 — reconciliation identity blinding	Stage-owned consistently across workspace.	Separate from accepted-answer visibility; no competing form/profile identity controls.
VU1–VU3 — version presentation	Keep invalidated answers visible as Needs updating; valid replacement required before Complete. Version-specific change reason and reviewer guidance are separate optional fields retained in history.	Missing reason triggers non-blocking warning, not publication refusal; missing guidance also does not block.
QY1–QY3 — query authority and gold	Effective accepted answer plus pending flag; one work item per answer version with per-concern resolution; resolve invalidated children before publishing replacement gold.	Preserve previous snapshot until valid replacement; no invented child values.
QY4–QY7 — query permissions and outcomes	Prefer another authorised reviewer but permitted self-review is audited. Rejection explanation optional. Each raiser receives their resolution; anyone with answer-view permission can query.	Query-review permission needed for approval; preserve candidate isolation. No blanket ordinary-reconciliation self-review exception or actual notifications.

Worked ownership and lifecycle example¶

Form F requires Q1 and Q2 and has target two reviewers. Stage A and Stage B both use F. Alice opens F in A, autosaves edits, Saves an incomplete version, and Completes a validated version. Alice supplies one qualifying contribution to F for that study. Opening F in B resumes the same reviewer-owned form session; a retry or completion through B does not create a second contribution. A revision authored in A retains A's exact settings/question provenance when reused in B. A later revision authored in B records B's own context.

Form G requires the compatible Q1/Q2 plus Q3. Alice's compatible Q1/Q2 answers are reused, but G remains incomplete until its own requirements are met. F and G do not acquire the same completion state merely because they overlap.

After F is completed, Alice edits a correction. Autosave alone leaves the completed explicit version current, with unconfirmed edits separately indicated. An explicit incomplete Save becomes current instead: Alice no longer supplies a completed contribution to F. Completing a validated replacement restores a completed current version, never a second contribution. Previous versions and their exact revisions remain immutable history. If Alice saw accepted Q1 revision R7 while authoring the correction, record R7 as shown evidence on the relevant revision; the session also records the accepted snapshot available. The new contribution can count toward ordinary form progress while agreement reporting identifies the informed contribution.

This example uses compatible requirements. If adding Q3 creates F-v2, publishing checks for sessions under F-v1 and any other earlier F versions. The admin is prompted to choose what happens to those sessions; the selected transition policy determines whether Alice's earlier completed contribution counts against updated requirements. Its original version/provenance is preserved, and a missing Q3 answer is not manufactured. The exact policy options are not approved by this example.

Confirmed form-version transition decision¶

Chris, 2 October 2026 (FV1–FV3): adding a question creates a new form version. Publishing checks for sessions associated with any earlier version, rather than only the immediate predecessor. If any exist, the publishing administrator chooses how to handle them. The earlier completed contributions' qualification for the new requirements depends on that publish-time choice, not a universal default Chris must choose now.

The prompt must distinguish currently completed sessions, explicitly saved incomplete sessions and autosaved drafts, across every stage sharing the form/session. Admins can choose differing treatment for completed versus unfinished work. The application and confirmation UI of established choices for saved incomplete work and drafts still need design; manual versus automatic is not a new universal decision. Keep original immutable versions and source/shown- evidence provenance. Admin transition policy and question-level answer compatibility are separate decisions: accepting an older contribution does not invent answers to new required questions or approve incompatible-answer reuse. Category-specific application/confirmation of recovered choices, adoption/binding effects, concurrent publish/Save/Complete handling and recoverable application of the policy remain design and engineering work. This is not authorization to migrate existing data or implement the prompt.

Recovered admin-controlled transition baseline¶

Recovery from existing documentation, not a new Chris decision: Annotation Versioning Design Session §3.1–3.3 already specifies per-question impact choices requireReanswer, autoUpdate and doNothing, confirmed by the admin before commit. The review-step handoff also already allows pinned submissions, compatible answer carry-forward, and updated drafts requiring re-answer, with admin-chosen adoption and version bindings. Do not ask for a new universal manual-versus-automatic product decision.

Existing choice	Apply within the confirmed shared-form model
`requireReanswer`	Admin requests re-answer for affected questions; preserve old revisions and make missing required work visible. Exact current-state/adoption effects need category-specific design.
`autoUpdate`	Admin selects automatic update where compatible; retain source/shown-evidence provenance and history. This is a chosen transition, not unconditional automatic rebasing.
`doNothing`	Leave existing work/version references pinned under the chosen policy; do not silently invent answers or upgrade bindings.

The older stage-question-set impact scope adapts to the shared study/form session and all stages using it. Check sessions from any previous form version, classify them using the latest explicit Save/Complete plus separate autosaved changes, and use current materialized usage at the protected publish point. Admin choices determine treatment and qualification against new requirements, without duplicate reviewer/session contributions.

Remaining design is the exact application and confirmation UX for current completed, saved incomplete and draft-only sessions, including unsaved changes over an explicit version, compatibility, concurrency and reproducible counts. It is not whether admin-controlled manual/automatic choices exist. The older §3.2 statement “Questions added: No impact on existing sessions” is superseded by FV1–FV3's publish-time assessment and admin-controlled required-question treatment. A missing required answer never becomes answered by policy.

Current state, publication treatment and downstream effects¶

Confirmed correction, Chris, 2 October: classify each session by its latest explicit version: completed for Complete, saved_incomplete for Save, or draft_only when no explicit version exists. Record draft presence/changes separately for either explicit state and warn about unconfirmed changes at publication. A completed history entry does not make a currently saved incomplete session completed. History/current/draft never count as multiple sessions or reviewers.

Proposed effects to specify: after incomplete Save, remove that session from current completed qualification and recompute shared sufficiency and dependent applicability. Show the affected steps as needing reassessment; retain their work and pinned historical requirements. Re-evaluate eligibility and allocations under the applicable policy rather than silently deleting dependent work. An explicit session Save does not itself change accepted gold snapshots or submit/retract a screening vote; those have their own transitions. Define atomic projection updates, concurrency and how current insufficiency affects admission separately. The existing admin-controlled transition baseline applies; precise adoption effects on saved incomplete sessions and autosaved drafts still need design.

Confirmed publish-impact statistics direction¶

Chris, 2 October 2026 (PS1–PS3): determine prior form-version session/reviewer usage and question usage with materialized statistics. Before publication, make the relevant statistics current by waiting for catch-up or updating those specific statistics. A brief review pause may be needed in the design. Publication waits for current statistics and the admin's required transition choice. This does not authorize an actual pause or any statistics/runtime changes.

Engineering recommendations, not approved implementation specifics: align with the existing materialized-statistics owner's freshness, source-revision, family/epoch, configuration and fencing contracts. Propose a protected publish boundary/high-water mark or equivalent protocol, not a wall-clock freshness check followed by an unprotected save. Verify required evidence and the impact preview/admin choice against the same stable scope at commit; re-evaluate if the scope changes. A current confirmed zero differs from missing/stale evidence.

Enumerate which writes change that scope: autosave/session creation if relevant, explicit Save/Complete, imports, corrections, bindings or other version/context changes. Fence based on actual dependencies, without automatically pausing unrelated work. Prefer a scoped pause when needed, retain drafts, and guarantee safe release/recovery on failure. Define authorization, timeout/retry and durable post-commit behavior with the existing statistics owner.

Statistics do not enumerate affected records. Resolve actual session/annotation identities and apply transition assessments through authoritative records in a consistent scope. Do not sum stage counts to infer shared form usage or sum overlapping version rows blindly. Precise usage units, relevant statistic families, deduplication and concurrency mechanism remain to propose with evidence; this decision does not assert existing stage counters already provide the required form/version statistics.

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 action-by-action permission inventory for confirmed capabilities, existing permission mappings, proposed mappings and remaining grant gaps.

Open choices and next focus¶

Topic	Current status	What remains to specify
Form-version transition details	Owner rule FV1–FV3 confirmed; specifics to propose	Recovered choices: requireReanswer, autoUpdate, doNothing, confirmed by admin before commit. Specify their category-specific effects and confirmation UX, compatibility/missing-required checks, adoption/bindings, concurrency and reproducible counts. No universal count default remains to ask Chris; no incompatible pooling is approved.
Workflow action grants	Explicit additional-review capability confirmed; finer granularity open	Track assignment, expiry override and release against existing admin/design authority; decide delegated grant identifiers/scope without duplicating existing permissions. See the action inventory.
Draft concurrency and physical storage	Engineering proposal required	Safe shared session/answer draft ownership, stale base handling, autosave history, immutable Save/Complete transactions and receipts; retain approved semantic boundaries without treating every older collection proposal as current.
Publish evidence/freshness protocol	Owner gate PS1–PS3 confirmed; mechanism to substantiate	Version-aware form/question usage families and deduplication, protected source boundary, catch-up/scoped refresh, dependency-based write fences, consistent authoritative affected identities and safe pause release. Coordinate existing statistics contracts.
Accepted-answer query concurrency	QY1–QY7 confirmed; scoped details open	Stale-version/concurrent resolution and queue/permission/notification mechanics. QY8 closes demonstrably addressed individual concerns; uncertain satisfaction requires manual review and QY9 preserves unsatisfied concerns open with original target/current-review flag. Existing effective gold, child validation, self-review exception, optional rejection explanation and viewer-to-query rights are settled.
Publish-pause UX	Recommendation, not owner approval	Active-reviewer warning, visible exact-version queued retry and action-needed messaging require design/approval; the underlying current-statistics gate is confirmed.

Next specify the category-specific effects and UX of the recovered publish-time choices rather than reopening SF1/SF2 or asking for one universal count default. Scope adoption separately from publication: publishing does not itself approve migration, make a missing required answer exist, or erase completed historical work.

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.