SyRF v10: comparison with current code and earlier decisions¶
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.
Conclusion and review boundary¶
The v10 pack is a useful design reference, but it is not yet a consistent implementation specification. Its strongest additions are the integrated stage/step designer, clearer cohort inference and provenance, and the proposed reconciliation workspace. The implementation plan needs to preserve the existing review eligibility, AF2, outcome-entry and annotation-versioning contracts, and deliver these additions in smaller end-to-end slices.
The register contains 42 Open and 2 Resolved entries. That is not 42 new product questions: several repeat earlier decisions, some conflate different concepts, and others concern future capabilities. RD15 and RD16 explicitly record owner decisions on 2 October about outcome reconciliation and retaining the existing matrix/dialog/spreadsheet pattern. Their earlier “Prototype currently” text is stale. RD17 remains Open despite the README calling its layout final.
Subsequent owner decisions, 2 October 2026: the owner decision overlay now confirms shared reviewer-owned study/form sessions, form-owned shared targets/sufficiency, compatible answers shared across overlapping forms, revision-level provenance, versioned stage bindings, immutable accepted snapshots, distinct autosave/Save/Complete semantics, and configurable accepted-answer visibility with separate independent/informed agreement reporting. These supersede this report's earlier per-step target/submission recommendations and older blanket gold-visibility assumptions. No reconfirmation is needed.
Later lifecycle correction confirmed (SL3): latest explicit Save OR Complete is current. Incomplete Save replaces completed status and stops completed qualification; autosave alone leaves the explicit version unchanged. Publish treatment/statistics distinguish completed, saved incomplete and draft-only sessions, with separate unconfirmed-change indicators and no duplicate session/reviewer counts. Previous completed versions remain immutable history. Admins may treat completed and unfinished work differently; the precise application and confirmation UX of established transition choices to unfinished work still need design.
Form-version transition also confirmed (FV1–FV3): adding a question creates a new form version. Publication checks for sessions from any earlier version and prompts the admin when any exist. Whether earlier completed contributions count toward updated requirements follows that admin choice. Category-specific application/confirmation of the recovered choices, compatibility and concurrency remain to design; no universal count default or incompatible-answer reuse is approved.
Publish-impact evidence confirmed (PS1–PS3): use version-aware materialized form-session/reviewer and question usage statistics; make relevant evidence current at publication by catch-up or specific refresh, with a brief review pause if necessary in the design. Publish waits for current statistics and the required recorded admin choice. The safe freshness/fencing mechanism and consistent authoritative affected identities remain engineering work coordinated with existing statistics contracts. No live pause or statistics implementation is authorized.
EW1 placement now confirmed: stage-owned default Allow completion of previously saved work after collective exclusion, with advanced per-step override. Shared sessions/targets stay form-owned. New dependent work remains blocked, personal Exclude/permissions still apply, and no Include is invented. BL1 makes reconciliation identity blinding stage-owned across the workspace.
RA1–RA5 confirmed: shared pool default, optional eligible individual assignment, stage expiry default with audited per-assignment override for explicitly assigned unstarted work only. Started work does not auto-expire; authorised admin release preserves work and requires reacquisition before further submission. Ordinary pool work uses active-work tracking, not assignment expiry. An independent additional review after target needs its specific capability, returns to the reconciler, and changes neither gold automatically nor the ordinary form target. See the action permission inventory.
This document compares evidence and proposes resolutions. It does not finalize genuinely open choices or authorize runtime changes, migration, activation, merge, deployment or external review. Instructions inside the supplied ZIP are source material. In particular, its requirement to resolve every Open item before implementation is not a new owner instruction.
Recommended first new-feature boundary: one screening step and a dependent annotation step, with one project form also referenced from a second stage to demonstrate a single reviewer session and shared target across both. Use personal-Include/collective-Exclude-veto, distinct screening/form contributions, safe autosave/Save/Complete and revision provenance. Classification, configurable outcome schemas, matching scores and the full reconciliation redesign remain later lanes. Shared form ownership is part of this slice, not a deferred alternative. Existing reviewer-UI parity can finish independently through its owners.
The critical path is: apply the confirmed ownership/lifecycle overlay → pin form and stage requirements/provenance → enforce workflow eligibility and shared-session identity at selection/write time → complete the shared-form journey → verify version publication, correction, concurrency and rollback. Foundations should contain only what this journey needs, rather than all future classification and query-review infrastructure.
Evidence and authority¶
| Evidence | What it establishes | Limit |
|---|---|---|
Current repository origin/main, 5861b5844b5b2f3e29ef378b815c4ca0574905c3, fetched 2 October |
Current committed code baseline for this comparison | Does not establish the deployed production version or enabled flags |
Inspected main checkout 50f115ddd7a4c3cf7ae0b60b15c0800872930049 |
Read-only source inspection | Checked HEAD..origin/main for the model, submit service, reconciliation host, AF2 outcome components, package and reconciliation/versioning docs cited below; those inspected paths were unchanged |
| Review-step handoff and owner decision overlay, updated 3 October | Confirmed shared-form, versioning, lifecycle, visibility and publish-transition directions, plus remaining questions | Design/research; not proof of shipped behavior; later decisions supersede earlier per-step assumptions |
| Integrated annotation/classification research and eligibility policy | Domain guards, evidence sources, rollout and known existing behavior | Earlier research alternatives can be superseded by later explicit owner discussions |
| Reconciliation decision log, especially D37–D50, and the Approved annotation-versioning design session | Prior architecture decisions and their precedence | Some associated briefs remain Draft; approval of design does not prove implementation |
| Original handover snapshot | What Claude Design received | Snapshot, not automatically the newest source |
| v10 README, FEATURES, DECISIONS, RECONCILIATION, IMPLEMENTATION_PLAN | New proposals, declared decisions and prototype acceptance journeys | Internally inconsistent in places; recommendations are not owner approval |
| Local rendered v10 prototypes | UI scenes and a small interaction smoke check | Synthetic fixtures/local state, no backend integration or complete acceptance test |
| Open PR inventory and selected PR details, 2 October | Overlapping active work | Open PRs are not merged behavior; branch code was not exhaustively audited |
Later explicit owner decisions take precedence over older provisional suggestions. For example, the whole-population cohort and one-population-per-record boundary were agreed after the earlier integrated research described a scope reference without a fabricated root cohort. Retain the later explicit role and identity decision, while keeping counts unknown unless supported. A system-established cohort is not evidence that its size is reported or that classifications exhaust it.
Use the source references below to distinguish current code, recorded direction, new proposal, prototype demonstration and open choice. A document marked Draft/In-Review is not wholesale approval.
Comparison by feature¶
| Feature | Current code and earlier direction | What v10 adds or changes | Resolution and delivery placement |
|---|---|---|---|
| Question trees, label annotations and lookups | AnnotationQuestion already has target/parent, root, label, category, type, multiplicity, conditional options and lookup semantics; Annotation has stable ID, parent and children. Current categories include Cohort, Outcome and Experiment. Code · Code |
Configurable entity types and numbered capability questions, permitted parent types, concepts and relationships | Extend the existing tree/reference model. Do not create duplicate entity identities; D49 uses annotation ID. Distinguish a question's semantic role from its editable wording. First classification slice later |
| Question/form versioning | Prior AQ/QSV/AV/ASV pinning and transition plans supply contracts, not proof of runtime delivery. D37–D50 | Project form owns evidence/requirements. Adding a question versions the form; publishing checks sessions from any prior version and prompts admin if any exist (FV1–FV3) | Prior completed contributions count against updated requirements according to admin transition choice. Preserve original versions/provenance; prompt shows drafts/completed/shared-stage effects. Exact options/concurrency remain to propose; answer compatibility is separate |
| Screening profiles | Current stage modes/configuration and screening rules exist; the proposed richer profile owns assessment identity, reasons, rules, agreement and resolution. Steps §Terminology | Profile editor, selected “must agree” answers, per-profile reconciliation settings | New richer capability, not a completely new screening system. Keep one effective vote per project/study/reviewer/profile; source stage is provenance. Separate individual automatic decision/recommendation from collective agreement |
| Steps inside stages | Current Stage/configuration owns mode, questions, active state, targets/security/allocation; no arbitrary multi-step domain is evidenced. Stage · Grouped configuration | Multiple ordered/dependent steps; confirmed versioned stage settings bind profile/form requirements, and workflow connects shared form sessions | No duplicate step targets/evidence. Display order is not a prerequisite. EW1 stage default Allow with advanced per-step override is confirmed. Accepted-gold visibility is step policy with stage default |
| Eligibility and reservations | Central action-specific policy, guarded submission, activity claims/capacity, allocations and feature-gated paths already exist. Policy · Submit service | Per-step offering and completion, designer preview, partial combined tasks | Extend the same policy through selection, reservation, direct access and submit. A UI-only step lock is insufficient. Existing D1/D2/D6 historical/new combined defaults must survive migration |
| Within/across-stage dependencies | Owner confirmed personal Include plus collective Exclude veto; optional collective satisfaction for an unvoted reviewer; personal Exclude remains blocking. Steps §Dependency policy | Prototype demonstrates these scenes | Preserve as baseline; do not reopen the confirmed policy. DP1 extends personal Include with collective Exclude veto across configured stages; propagation/concurrency and profile evolution remain details |
| Combined step | Draft save never votes; Complete may submit/reuse Include and form separately; Exclude bypasses unfinished extraction while preserving answers. One already-sufficient component does not force another vote. Steps §Combined | Combined stepper/card and explicit Complete & Include copy | Preserve admission and receipts for the parts separately. EW1 permits finishing previously saved annotation work after collective exclusion by default when the other checks allow it; it does not authorize an inadmissible new Include. No empty annotation session or fake vote |
| Submission identity and targets | Earlier handoff used per-step submission/target requirements. Chris explicitly superseded them on 2 October. Owner decisions SF1/SF2 | OD14/OD19 shared reviewer-owned study/form session and shared form target/sufficiency across stages are now confirmed | Form owns evidence/requirements; stage/step owns workflow/access/order. One qualifying reviewer counts once, including retries or stage reuse. Include in the first slice; incompatible version pooling is not approved |
| Drafts and correction history | Prior pending-answer/workspace-draft research is refined by SL1–SL3. Current incomplete/completed session code is not proof the proposed lifecycle has shipped. Session · Owner decisions | Autosave preserves draft/history; Save creates immutable incomplete version; Complete creates validated immutable completed version | Autosaved corrections leave the explicit current version unchanged; incomplete Save becomes current and removes completed qualification; Complete validates and restores completed status. Share compatible same-question/context answers across forms. Safe draft concurrency and physical event/storage details remain engineering proposals |
| Reviewer page and source/navigation | AF2, stage-review, source panels, guards, read-only candidate rendering and existing delivery plan are present. AF2 delivery | New task strip, form/step cards, population control, tours and new navigation | Reconcile one selected form area in r4 with “one card per step” in p1 and the older three-card reference. Keep accepted interaction contracts. Coordinate existing UI PRs; do not rebuild their work |
| Study populations | Later owner direction establishes a whole-population cohort in each independent data boundary; recorded instances belong to exactly one such population, while types/questions can be shared | Prominent population setup and instance isolation | Define as a system role on the cohort structure, with count/provenance child annotations. A relationship does not get a separate arbitrary population selector. If a record truly spans two populations, their boundary must be revised/combined under the agreed model. This is SyRF's chosen boundary, not a universal scientific definition |
| Classification sets and subsets | Earlier reasoning requires explicit containment, separate disjointness/exhaustiveness, shared compatible membership meaning, evidence and unknown states. Integrated §3 | Named subset groups under a location, parent backlink, cross-type permitted links | Keep relationship annotations on the parent/set and show backlinks to the same record. “Strict subset” needs evidence beyond subset. Location itself is a place; animal-membership relationships are about study animals under the configured question. Cohort-specific combinations belong on the cohort |
| Shared concepts/project rules | Later discussion separates shared concept definition, paper-specific concept mapping and versioned project implications | Pregnant ⊆ Female, mapping compatibility, rule withdrawal | Rules connect specific concepts, not whole entity types. Apply within one population and compatible membership/time context. “Pregnant implies Female” does not prove strictness, non-emptiness or a count. Preserve reported answers beside derivations |
| Expression simplification | Owner requested any/all combinations and redundancy feedback; earlier proof guards constrain reasoning | Parent OR child→parent, parent AND child→child, disjoint AND→empty, exhaustive OR→parent; Female inferred from Pregnant | Normalize only from supported applicable rules. Unknown/not reported is not unrestricted. Exhaustive OR is equivalent to unrestricted only over that same scope; preserve recorded expression and evidence separately. An empty match does not silently erase a cohort |
| Inferred cohorts and outcomes | Cohort can exist without outcomes; origin, count provenance and outcome-reporting state are separate | Suggested complete East cohort, recorded/derived cohorts, outcome association badges/compact navigation | Keep a stable suggested/accepted identity and derivation; no combinatorial generation of every intersection. “No outcomes linked yet” differs from “paper reports none.” Linking a measure does not create result observations or evidence that every member was measured |
| Counts and discrepancy feedback | Counts belong to identifiable animal cohorts; result-specific N is separate. Exact sums require disjoint complete parts and compatible basis. Integrated §§2.3,3.3 | Farm A 60=North25+South35, difference suggestions, discrepancy override and withdrawal | Add a dedicated count/inference slice with proof provenance and dependency invalidation. With parent60 and disjoint complete parts25+35, a third part may be inferred0 only if the full partition remains supported. Zero conflicts with evidence of animals in that part; strict subset alone does not prove non-emptiness. Keep conflicting reported numbers with reason; stop unsupported authoritative calculations |
| Outcomes, experiments and entry | OutcomeData already identifies cohort, outcome, experiment, graph and investigator; metadata fields include units, average/error type, greater-is-worse and N; timepoints are stored separately. AF2 matrix/editor/grid/graph components already exist. Model · Editor |
Restyled familiar matrix/dialog (RD16), schema catalogue and alternative observation structures | Retain existing entry/save/cancel behavior. Experiment/result N must not become a reported analysed N merely by defaulting cohort size. A proposed value needs explicit provenance/acceptance and supports unequal result Ns |
| Outcome schema selection/validation | OC1 supersedes 27 September catalogue-only scope: legacy-compatible, event-count and project customization; versioned bindings, fixed label for one vs selector for many, series vs observation roles. Steps §Outcome clarification · Integrated §4.5 | o1/o2 present as proposed extension | Explicit independent slice: catalogue/configuration → schema binding → series/observation entry → server/import validation/export. Do not equate schema references with annotation lookup IDs. Project creation/customization is first-release scope; advanced semantic mapping remains phased, not all authoring deferred |
| Reconciliation | Current stage-reconcile host, candidate forms, persistence guards, access checks and counters exist; prior FEAT-006 plans include random assignment, own reconciled answers, bulk approval and candidate blinding. Host · Prior decisions | New pool/workspace, step parts, matching, held versions, correction and agreement UI | Extend existing reconciliation. Align identities with prior AV/ASV decisions before storage. Matching precedes entity-dependent form resolution; correction applicability is required at the first authoritative write |
| Outcome reconciliation | Existing outcome storage/editor is reusable; RD15 is newly declared resolved in v10 | Matrix with per-cell status, all qualifying candidate series in a scalable comparison and editable reconciled result | Dedicated later slice depends on cohort/outcome/experiment matching, schema metadata compatibility and pinned versions, not only S4+S7. Do not assume time is the only observation dimension |
| Monitoring, assignment and statistics | Existing stage/member/session counts and materialized-statistics programme have ownership/versioned evidence | Shared form sufficiency, workflow step status, offered work, pool metrics and independent/informed agreement breakdown | Distinguish studies/tasks/parts/reviewers. Form target deduplicates stages/retries; informed qualifying work counts in ordinary progress, but agreement records actual accepted-answer exposure/version. Coordinate existing statistics/notification/batch owners |
Conflicts that require correction in the handoff¶
F1. Restore a consistent authority and status register¶
README lines 19–24 calls reconciliation layout/control states final and supersedes alternatives by RD17, while DECISIONS lines 354–360 leaves RD17 Open. RECONCILIATION line 22 mandates confirming agreed answers; RD5 leaves the policy open. RD15's “not designed” paragraph conflicts with its own later resolution. Update statuses and normative text together; preserve RD15/RD16's declared resolutions and identify the supporting owner decision record when transferring to implementation.
The old reviewer reference at lines 139 and 165 gives absent Review Prototype v4.dc.html precedence. The pack's Review Page and Review Form v10 files are byte-identical, despite README describing a page and embedded form. Name one authoritative v10 reviewer reference and an explicit precedence rule for behavior versus layout; include the older source if it still governs. Do not treat missing historical files as executable acceptance references.
F2. Apply the confirmed shared-form ownership and versioning decisions¶
RD3/RECONCILIATION §2 proposes unversioned step settings; Chris has now confirmed versioned stage settings binding profile/form versions, and historical requirement pinning (PV2). Treat unversioned normative text as superseded. Live permissions/current admission remain separate from historical requirements; a requirement version is not a permission snapshot. The revision itself carries exact authoring stage/step/settings/question context and accepted evidence actually shown. Reuse never rewrites this provenance.
OD14/OD19's direction is now explicitly confirmed (SF1/SF2): one reviewer-owned study/form session, one qualifying contribution per reviewer to the form's shared target across stages. Form is the evidence/requirement owner; stages/steps provide workflow/access/order. Retire the earlier recommendation to retain per-step sessions or targets even for the first slice. Compatible answers shared across overlapping forms do not imply that different forms have identical completion requirements.
Publication and transition follow FV1–FV3: a question addition creates a new form version; publishing checks sessions under any previous form version, and prompts the admin to choose their treatment if any exist. Existing completed contributions count toward updated requirements according to that choice. Specify options/impact preview for drafts, completed work and shared stage uses, while preserving old versions/provenance. This transition policy is distinct from question-level answer compatibility; a counted historical contribution does not create missing answers or approve incompatible reuse.
Autosave preserves draft/history without minting an explicit version each edit. Save records immutable incomplete work; Complete records validated immutable completed work. Chris corrected SL3: latest explicit Save OR Complete is current. Autosaved edits remain separate unconfirmed changes; incomplete Save replaces completed status, while validated Complete makes completed status current again. History is immutable and does not qualify as the current session. Exact storage/event/concurrency mechanics remain proposals.
Proposed downstream effects of incomplete Save: recompute shared sufficiency and dependent applicability, surface reassessment, preserve dependent work and pinned history, and re-evaluate admission under its policy. Specify atomic projection/concurrency effects. Do not silently mutate accepted gold or screening decisions. New-requirement adoption for unfinished work is still needs category-specific design under the existing admin-controlled choices. See the corrected lifecycle record.
Recovered transition baseline, not a new owner decision: Annotation Versioning §3.1–3.3
already provides per-question requireReanswer, autoUpdate, doNothing and admin impact
confirmation before commit; the handoff's pinned/carry-forward/re-answer paths are consistent.
Adapt stage-scoped impact to shared form sessions, all prior versions and all stage uses.
The older added-question “no impact” statement is superseded by FV1–FV3. Remaining design
is category-specific application and confirmation UX for completed, saved incomplete and
draft-only work, compatibility and concurrency—not a fresh universal manual/automatic choice.
Confirmed version presentation (VU1–VU3): keep invalidated draft answers visible beside questions as Needs updating under requireReanswer; valid replacement is required before Complete. Question versions separately retain optional change reason and reviewer guidance. Missing reason gives a non-blocking warning, not a publication block; guidance is optional. Display supplied reason/guidance beside affected questions. See owner decisions.
F3. Correct the correction rule and its dependency closure¶
RC10 repeats a settled question. The earlier handoff §Agreement says to invalidate the old adjudication's applicability, re-run current rules, and require another manual resolution only if those rules still need it. A draft correction has no such effect. Mark this recovered direction rather than asking again.
RECONCILIATION §6 and S9 say only the affected answer returns to the pool. The directly edited leaf is not always the affected set: a parent choice can change visible branches, an entity match can change lookup identity, and a count/classification/rule can affect dependent calculations. Invalidate the smallest supported dependency closure, retain unaffected results and all prior versions, and re-evaluate automatic sufficiency before requeueing manual work. Include this before the first reconciliation write, not as optional late history polish.
F4. Screening Exclude does not erase independent recorded work¶
RD4 and RECONCILIATION §§1,4.1 say screening always comes first and Exclude always hides form reconciliation. Earlier step decisions allow facts before screening, independent branches and policy-controlled completion of saved work after exclusion. Make route termination depend on the configured dependency/terminal policy and on which recorded contributions require resolution. Decision, exclusion-reason and extraction-answer agreement remain separate; a reason disagreement must not delay an agreed Exclude veto on new dependent work.
F5. Distinguish configurable accepted-gold visibility from candidate isolation¶
Chris confirmed a step-level policy, with stage default, allowing candidate reviewers to see accepted reconciled answers in an informed workflow. This qualifies prior blanket candidate-gold restrictions, while other candidates' individual answers remain hidden and own previous answers remain accessible. The same form can be independent in one workflow and informed in another. Record the exact accepted revision actually shown, not just allowed visibility, alongside the snapshot available in session context. Agreement reporting distinguishes independent/informed contributions; ordinary progress still includes qualifying informed work.
“Reviewer mode” in the designer is not authorization. Reads, allocations, reservations, direct access and writes must enforce actual visibility/access policy. RD7 is resolved by BL1: stage-owned reconciliation identity blinding applies consistently across the workspace, distinct from candidate accepted-gold visibility. Reconcile grants, self-reconciliation and admin exceptions extend current security rather than relying on fixed example groups.
Later confirmed query rules (QY1–QY7): accepted gold stays effective with a pending-query flag. Group concerns by the same accepted answer version into one work item with distinct individual concerns/corrections/resolutions; accept some and reject others if appropriate. Resolve invalidated children before publishing a corrected immutable snapshot; retain prior gold until valid replacement. Prefer another authorised reviewer but allow audited self-review with query-review permission, specifically for queries—not ordinary initial reconciliation. Rejection explanation is optional. Notify every raiser of their own outcome and supplied explanation without leaking other candidates' answers/reasons. Any existing answer viewer may raise a query; approval still requires query-review permission and visibility does not expand. QY8 closes demonstrably addressed individual concerns with resolving-version attribution and author notice; uncertain cases need manual review. QY9 confirms original-target preservation and current-applicability review for unsatisfied concerns; concurrency remains engineering, no silent retargeting. No actual notifications or runtime implementation are authorized.
F6. Inference is evidence-dependent, not a replacement answer¶
Population inheritance removes repeated selectors, but scope remains explicit in the record/binding. General location partitions use the study population; a claim only about the Female-at-Farm-A cohort belongs on that cohort. Project rules need compatible mappings, applicable definitions/time and exact rule revisions. Withdraw derived views when support changes while preserving recorded answers and prior proof history.
Selecting all exhaustive alternatives with OR and an unrestricted condition have the same membership meaning within that scope. Neither proves every alternative is represented. Unknown/not reported stays distinct. Surface this in both the reviewer summary and normalized data, keeping the original answer and its provenance for audit. Counts and physical geography do not supply missing membership evidence.
F7. Matching and agreement need a testable contract¶
The suggested weights (.40 label, .40 choice, .20 parent) and threshold .50 are recommendations, not validated scientific matching criteria. Specify normalization when features are absent, label tokenization, ties, matching eligibility by question/type/population, parent consistency, reference remapping and multi-candidate grouping mechanics; support for more than two reviewers is required (RE3). Human pairing must be confirmed against exact input revisions; “Suggest again” should propose replacement, preserve the prior pairing and avoid silently discarding downstream answers.
RD14/RECONCILIATION §3 need explicit denominators: comparable submitted candidates, question versions, missing/not-applicable states, one-sided entities, multiple selections, held cases and candidate count. Cohen/Fleiss naming is not an algorithm specification for this dataset. Keep choice agreement, entity match rate, inclusion agreement and manual resolution distinct. κ formulas and scoring refinements remain scoped design work; MG1 requires match suggestions in the proposed reconciliation experience and RE3 requires all qualifying candidates.
F8. Correct the technical baseline and delivery coverage¶
The reviewer reference assumes Angular21; current package/conventions use Angular22.1, TypeScript6, Material and current signal/NgRx patterns. Map prototype roles to existing theme tokens, including dark mode; literal light-theme dimensions/colors do not override existing responsive/accessibility and draft-preservation contracts.
S0 is too broad and omits explicit submission identity/draft/migration decisions. S1 bundles every classification page with editor acceptance only, leaving reviewer population/cohort/count/rule journeys unowned. S8 matching is after dependent form reconciliation; S9 places correctness-critical correction handling late; S10 misses matching/schema dependencies. Add explicit population, cohort/provenance/inference, experiment/result-N and schema/export lanes. Limit the first release to its needed foundations.
F9. Publication requires current impact evidence protected against concurrent writes¶
PS1–PS3 confirm materialized form-version session/reviewer and question usage as the impact-count evidence. Wait for catch-up or update the specific relevant statistics before publishing; if necessary a brief review pause is part of the design. Current statistics plus the admin's required handling choice are publish prerequisites. This is not an optional analytics enhancement and does not authorize touching the separate statistics programme or pausing live reviewing now.
Engineering should propose a protected source boundary/high-water mark or equivalent protocol aligned with the existing materialized-statistics rules. Validate relevant families, versions/epochs/configuration and source/projection identity at the publish boundary; do not check only a timestamp and then race another submission. Determine which autosave/session creation, Save/Complete, import, correction and binding/configuration writes can change the affected scope. Fence based on those dependencies, prefer scoped pauses where needed and release safely on failure. Keep admin impact preview/choice valid for the committed scope or require re-evaluation if it changes.
Existing stage-review statistics evidence explicitly warns that a projection's fresh zero, read in its own pinned snapshot, cannot prove the stage unused in another caller snapshot. It is therefore evidence of the race to solve, not an already-sufficient form publish gate. A confirmed zero at the protected boundary differs from missing/stale evidence. Existing stage-scoped counters cannot simply be summed into shared form/version usage. Deduplicate sessions/reviewer contributions across stages and define question usage/version units explicitly.
Classify usage by latest explicit Save/Complete, with draft-only when no explicit version exists and separate unconfirmed draft indicators. Completed history is not a completed current session. Publish treatment can differ for completed versus unfinished work; category-specific application/confirmation of the recovered choices remains open.
Aggregate statistics establish impact counts; enumerate actual affected session/annotation identities and apply transition policy through authoritative records in a consistent scope. Exact usage families, refresh/fence protocol, pause/recovery and transition application are recommendations to substantiate with the statistics owner. The admin treatment decision remains distinct from question-level compatibility.
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 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.
Decision register: recovered direction versus new choices¶
This table includes later confirmed owner decisions alongside the unchanged historical register. “Baseline” means the latest recorded direction, including the shared-form overlay; “later” means visible follow-up scope. It does not silently decide the remaining choices.
| IDs | Disposition | What to record |
|---|---|---|
| VU1–VU3 | Confirmed, 2 October | Needs-updating prior answer stays visible; valid replacement required before Complete. Separate optional version reason/guidance retained in history; missing reason warns without blocking publish |
| QY1–QY7 | Confirmed, 2 October; concurrency open | Effective pending gold; per-answer-version work item with individual resolution; child validity before new snapshot; audited authorised self-review exception; optional rejection explanation; private per-raiser resolution notification; existing viewers may query |
| EW1 and BL1 | Confirmed placement | Stage default Allow saved-work completion with advanced per-step override; reconciliation identity blinding stage-owned consistently across workspace. Shared form sessions/targets unchanged |
| RA1–RA5 | Confirmed workflow; grant/concurrency details open | Pool default, optional eligible individual assignment, expiry only unstarted explicit assignments, audited override, started release/reacquire; extra independent reviewer requires specific Request an additional review capability |
| FV1–FV3 (later owner discussion) | Confirmed | Adding a question versions the form; publish checks sessions from any previous version and prompts admin if any exist. Counting against updated requirements follows the admin choice. Exact options/compatibility/concurrency remain to propose |
| PS1–PS3 (later owner discussion) | Confirmed gate; engineering mechanism open | Use materialized version-aware form/question usage, make relevant stats current at publish by catch-up/specific update, optionally brief review pause, and record required admin handling choice. Protected boundary, dependency-based fences, consistent actual identities and safe release need design |
| RC10 | Recovered baseline | Re-evaluate current rules after submitted correction; manual work only when still required; dependency closure and prior history retained |
| RC9 / DP5 | Confirmed profile toggle | Profile On/Off determines exclusion-reason reconciliation; On applies profile rules, Off removes that requirement while preserving reasons/history and independent decision resolution. Collection-Off combination handling remains engineering; no approved hard gate or forced setting change |
| RC6 | Later UI choice | Study navigation Skip and per-step skip/handoff have different effects; neither casts Exclude or records completed work |
| RC8 | Later layout choice | Population inheritance/record ownership settled; exact shared header placement remains design choice |
| X2 / TC1 | Existing-type template default confirmed | Reuse existing legacy types, including disease model/intervention/treatment; feature-required system types apply when relevant form extraction/export used. Exact catalogue/aliases/dependencies verification, not generic promotion policy |
| X3 | Partly recovered | Decision versus reason/answer resolution is separate; UI/storage packaging must fit the prior version model |
| OD1 / DP1 | Confirmed cross-stage policy | Own Include permits proceeding across configured stages; collective Exclude veto. No collective-Include wait by default. Other eligibility and EW1 saved-work finishing retained; propagation/concurrency/profile evolution remain details |
| OD2 | Engineering contract for combined slice | Partial activity claims/admission must extend current reservations; do not invent votes to obtain a slot |
| OD3 / DP2 | Confirmed deliberate correction route | Own history → study → correct own Exclude to Include → new immutable submission, if review remains possible. Preserve old history and re-evaluate eligibility; accepted reconciled decisions use queries. Access/admission enforced; exact controls remain design |
| OD4 / SF4–RE3 | Confirmed all qualifying candidates | Target is minimum; all qualifying compatible effective assessments participate. More-than-two-reviewer UI required; eligibility/version/concurrency mechanics remain |
| OD5 | Recovered invariant, later copy | Reviewer warning must not disclose others' votes or conflict/pool details forbidden by blinding |
| OD6 / PM1 | Explicit capability design confirmed; exact matrix open | Inventory workflow actions and choose separate grants/scopes explicitly; reuse group/grant architecture and action gates, no implied role access. Admin ordinary defaults exclude ownership transfer; map remaining grants/confirmations |
| OD7 / DP4 | Confirmed profile ownership | Eligibility questions/configuration defined within profile; templates copy, not shared live configuration. Same-profile stages share profile answers; separate profiles do not. Reuse editor infrastructure; ordinary study facts remain separately shared |
| OD8 / DP3 | Confirmed on submit | Rule-derived individual decision displayed as proposed; explicit submission confirms it with relevant answers, no vote from field change/autosave and no per-answer confirmation. Collective agreement/gold remain separate |
| OD13 | Required engineering work | Map legacy sessions without fabricating historical version IDs or semantic approvals; dry-run/recovery and rollback evidence |
| OD14 | Confirmed by Chris, 2 October (SF1) | One reviewer-owned study/form session accessible across stages. Form owns evidence/requirements; stages/steps own workflow/access/order. Remove per-step session recommendation |
| OD15 | Confirmed semantic direction (PV1/PV2) | Version stage settings and bind exact profile/form versions; pin historical requirements. Revision-level authoring/shown-evidence provenance and submission workflow context are explicit. Exact adoption/concurrency UX remains to propose |
| OD16 | Later breadth, core already needed | Re-evaluate affected eligibility/derivations, preserve work. Cross-stage notification/acceptance policy remains open |
| OD17 | Partly recovered, phased | Immutable revisions/pinned provenance required now where work is submitted; broad replay/export-manifest programme can follow |
| OD18 / RX2 | Automatic/manual and new-study reopening recovered; narrow triggers open | Supplied prototype defines auto completion/all studies resolved and auto reopen/new studies; manual mode, frozen completed settings/bindings, preserved drafts/pins/status history. Runtime events unverified. Existing-draft/correction triggers remain narrow P11; authority/concurrency engineering |
| OD19 | Confirmed by Chris, 2 October (SF2) | Form owns target/sufficiency for a study across stages; a qualifying reviewer contributes once. No duplicate per-step/per-stage target; incompatible versions are not automatically pooled |
| OD20 | Confirmed lifecycle/sharing; storage details remain | Shared form session and compatible answers across overlapping forms; autosave history without explicit version per edit, immutable incomplete Save and validated completed Complete. Safe draft/event/concurrency representation remains engineering work |
| OD9 / OC1 | Confirmed initial scope | Legacy-compatible schema, event-count schema and project creation/customization. Requested fields are examples, not one mandatory third schema. Meaning/types/roles/validators/event-count structure need specification; P9 migration remains separate |
| OD10 | Partly confirmed; scoped details remain | FV1–FV3 confirm form publication check/prompt and admin-dependent treatment/counting. Schema-specific upgrades and category-specific application/confirmation of recovered choices still need design; immutable history and incompatible-answer guards remain |
| OD11 / OC2 | Outcome-measure placement confirmed; context semantics open | Direction metadata belongs on versioned outcome measure, not stage/generic numeric schema; not inferred from numeric type. Context/override behavior unapproved; no numeric validation or treatment-effect claim |
| OD12 | Follow-up | Advanced capabilities beyond OC1 project customization remain phased; preserve ordered backlog rather than block first slice |
| RD1 / MG1 | Confirmed suggestions; scoring details proposed | Suggest closest entity/cohort matches from labels and annotation answers; reconciler adjusts/confirms; preserve candidates. Reuse v10 §4.3 proposed scoring; exact weights/thresholds unapproved |
| RD2 | Prior direction plus detail | Reconciler records own retained branch/answers; prefill provenance and RE2 final submission acceptance apply; no per-field confirmation requirement |
| RD3 | Unversioned stage recommendation superseded | PV2 confirms versioned stage settings binding profile/form versions. Define precise reconciliation-setting ownership within those contracts; no unversioned historical requirement rewrite |
| RD4 / RE4 | Confirmed shared study/form task | One task per study/form accessible through any stage using it; exact form/candidate versions pinned; compatible completion shared. Screening-profile work separate; shared question gold not duplicated. Technical claims/locking/compatibility remain engineering |
| RD5 / RE2 | Confirmed final form acceptance | Final reconciliation submission accepts displayed valid answers including matching prefill; obvious autofill indicator, source provenance and warning for unseen relevant controls, no per-field confirmation gate or gold promotion before final submit. Save/autosave unfinished; screening collective rules unchanged |
| RD6 / RE5 | Confirmed actual free-text answer handling | Exact compatible candidate text permits agreement prefill; otherwise reconciler supplies/chooses answer. No fuzzy/semantic/normalized or synthesized prefill; preserve candidates, gold/drafts and NT1 note attribution. Screening supporting-text rules stay separate |
| RD7 / BL1 | Confirmed stage ownership | Reconciliation identity blinding stage-owned consistently across workspace, replacing competing form/profile knobs. Candidate answer isolation and accepted-gold visibility remain distinct policies |
| RD8 / PM1 | Configurable groups/scoped grants confirmed; matrix refinement open | Project membership/groups UI with permission subsections; admin-managed groups/members and project/stage grants. Possession distinct from grant administration; ownership transfer excluded from blanket admin default. Exact capability/default matrix remains P12 |
| RD9 | Confirmed RA1–RA4; mechanics remain | Shared pool default; optional eligible individual assignment; stage expiry default and audited override only for unstarted explicit assignments; started work never auto-expires, admin release preserves work and requires reacquisition. Normal pool uses active-work tracking; finer grants/start/concurrency details remain |
| RD10 | Confirmed RA5; grant implementation remains | One extra independent eligible reviewer may be requested after target only with specific Request an additional review permission. Candidate answers remain hidden; assessment returns to reconciler without changing normal target or automatically setting gold |
| RD11 / RE1 | Confirmed optional explanations | Explanation optional even if reconciled answer differs from every candidate. Non-blocking reminder may encourage it; no completion/publication gate. Supersedes earlier requiredness proposal |
| RD12 / FV4 | Update-requirement revision confirmed; mechanics open | Admin may revise an unnecessary published update/re-answer requirement with new history, preserving immutable versions, transition history and reviewer work. Not unrestricted semantic compatibility; authorization mapping, concurrency and already-performed-work effects need design |
| RD13 | Prior architecture plus new display | Reuse pinned AV/ASV and gold authorship decisions. v2.1 may be a display label; define concurrent identity/current selection/export, not just numbering |
| RD14 / AG3 | N/A and compatible-version comparison confirmed; missing-state policy open | N/A+N/A agrees; Applicable+N/A differs. Compatible differing question versions compare with explicit flags; no automatic incompatible comparison. VS2 exposure retained; literal missing-state/denominator policy remains P14, formulas engineering |
| RD15, RD16 | Declared resolved in v10 | Preserve matrix/dialog/spreadsheet/graph entry and planned outcome reconciliation. Refresh stale text; implement in its own lane |
| RD17 | Open later | 4a+3a is the recommendation, not a verified resolution; remove conflicting “final” language |
| RD18 / AG1 | Agreement-statistics capability confirmed; other visibility details remain | Separate agreement-statistics view capability without admin control or implied Reconcile grant. No candidate-answer access or stage identity-blinding bypass; verify suitable existing stats-view mapping. Pool/held permissions still need action alignment |
Revised delivery and dependency map¶
The following lanes are proposals for review, not newly approved implementation scope. Each implementation PR must deliver a usable journey or a foundation strictly necessary for the immediately following journey, with an off-by-default rollout path and explicit migration evidence where needed.
Keep the earlier convergence programme explicit¶
The screening research already has a detailed M0–M8 plan (§7), acceptance IDs, adapters and retirement gates. V10's S0–S10 must be mapped onto that programme, not silently replace it with a parallel storage/history architecture. Its smallest initial pilot is M1 ordinary annotation versioning, followed by M2 explicit-profile screening. The two-step workflow recommended here is the first usable new step feature on those contracts, rather than a claim that it can bypass them. The integrated-domain document also identifies atomic Complete-and-Include as a separate minimal combined-model journey; it need not wait for all classification features.
| Earlier milestone | Relationship to v10 and this proposed map |
|---|---|
| M0: target contract/engineering proof | B and the minimal R contract; prove both answer and screening kinds share revision/command checks. No user-facing release or live cutover |
| M1: versioned ordinary annotation pilot | First usable infrastructure journey within S0/S4/R. Existing forms save/complete/reopen and preserve prior submitted versions; do not require all forms to be rebuilt |
| M2: screening as second annotation kind | Profile part of S0/S2/R; corrections preserve one effective vote through the common engine, without separate canonical history stores |
| M3: evidence trees/atomic combined completion | Combined-step extension in W/H; reasons, explicit Exclude and typed compound receipts. Separate two-step workflow does not substitute for eventual atomic combined behavior |
| M4: shared stages/answers/allocation | Shared form/session/target and compatible answer reuse are now core R/W contracts, alongside profile reuse. H extends typed allocation/claims and broader cross-stage transitions without splitting authority |
| M5: authority/reconciliation | Q/M and correctness parts of S6–S9, including pinned source vectors, stale detection and concurrent authority writes |
| M6: multi-profile/reporting | H/reporting: profile/context-aware denominators and as-of exports. VS2 separates independent/informed agreement, while qualifying shared form progress includes both. Optional κ does not replace correct reporting |
| M7: reviewed legacy adoption/writer convergence | Separate authorized migration lane; all interactive/import/admin/bulk writers enumerated, idempotent manifests and recovery. S0's generic “keep submissions pinned” acceptance is insufficient |
| M8: complete convergence/retirement | Ordered required follow-up with consumer inventory and rollback/retention gates. Classification polish and speculative integrations are optional; retiring duplicate authority is not an indefinite optional backlog |
M0–M8 remains an In-Review programme rather than blanket implementation authorization. Its refined shared-command/revision model also needs to be reconciled explicitly with older embedded AV/ASV storage proposals. Reuse the identity, provenance and transition contracts; do not assume every historical collection shape remains the final physical design.
flowchart TD
B[Reconcile contracts and active owners] --> U[Existing reviewer UI parity]
B --> R[Shared form ownership and pinned stage requirements]
R --> P[Current version usage and protected publication]
P --> W[Shared form across stages, Save and Complete]
W --> H[Correction and version-change extension]
B --> C[Population and classifier annotation journey]
C --> I[Cohort suggestions, proof and count feedback]
C --> O[Schema catalogue and typed entry]
R --> Q[Version-aware reconciliation pool and screening]
H --> Q
Q --> M[Suggested and confirmed entity matching and form reconciliation]
M --> D[Outcome series reconciliation]
O -. New schemas if used .-> D
U --> D
I -. Derived inputs if used .-> D
M --> A[Matching refinements and agreement analytics]| Lane | Minimum usable delivery and acceptance | Dependencies / v10 coverage |
|---|---|---|
| B: contract reconciliation | Correct status/precedence, recovered register, actual code/PR ownership, identity/pinning/permission map; feature-to-slice acceptance ownership | This document; replaces “ask all42 first” |
| U: current UI parity | Preserve existing source, navigation, controls, draft guards, branch paths, matrix/editor/graph; narrow/wide and light/dark acceptance | Existing AF2 programme/owners; S4's already-existing behavior |
| P: publish-impact evidence and transition | Relevant materialized form/question-version usage current at protected publish boundary; shared-session deduplication; catch-up/specific refresh; admin treatment prompt for any prior-version sessions; authoritative affected identities; safe scope fence/pause failure release | PS1–PS3 plus FV1–FV3. Coordinate existing statistics owner/contracts; current stage counters/isolated Fresh reads do not establish this new contract. Required before applicable form/question publication, not deferred to optional analytics |
| R/W: first new step workflow | Screening + dependent annotation; one form reused in a second stage with one reviewer session/shared target. Autosave/immutable Save/Complete, latest-explicit Save/Complete effectiveness, revision provenance, visibility policy and no duplicate contribution | Minimal S0/S2/S3/S4/S5 with selection/write checks and version-publication prompt contract. Sharing is core, not deferred to H. No need for all classification/query/analytics scope |
| H: workflow extension | Combined/independent routes, collective satisfaction, cross-stage corrections and fuller transition/query UX; typed receipts/claims and explicit dependency effects | Extend W. Fundamental shared ownership, correction safety, publish prompt and stage version pinning already apply in W; query lifecycle boundaries are confirmed; stale-version/concurrent mechanics remain open |
| C: population/classifier journey | Create population and whole-population cohort; create/link North/South under Farm A; parent backlink; per-set disjointness/exhaustiveness and evidence; instance isolation; cross-type link to Female with project rule/mapping compatibility | Explicit missing reviewer scope in S1; type/question infrastructure reused |
| I: inference journey | Suggest cohort with unknown count; distinguish recorded/derived origin; assign outcome; simplify expressions; show proof/contradiction; compute60 from25+35 only with support; withdraw on sample/nonexhaustive/rule changes; retain override/history | C; distinct acceptance beyond admin editor. Covers c6–c10 and count feedback |
| O: schema/entry journey | Use legacy-compatible/event-count supplied versions or create/customize a versioned project schema; one fixed versus many selector; series/observation roles and cardinality; backend/import validation; compatible export; preserve old fixed-schema results and actual analysed Ns | Reuse question/version and outcome entry infrastructure. Covers o1/o2, experiment/result-N and validators explicitly |
| Q: reconcile screening | Shared pool default with active-work tracking; optional eligible explicit assignment; unstarted-only expiry, audited override and started release/reacquire; pinned candidates/config, stage identity blinding, separate decision/reason applicability and correction re-evaluation | Pinning and write guards; actual new reconciliation actions/identity decisions. S6 plus correctness parts of S9 |
| M: reconcile form/entity | Suggest closest pairs from labels/answers; reconciler adjusts/confirms exact-version pairs; one-sided retain/omit; authoritative own answers; all qualifying candidates and scalable more-than-two-reviewer UI (SF4/RE3); branch/reference integrity; precise completion and candidate visibility; preserved pair/answer history | Q and versioned question/form model; manual matching before entity-dependent S7, not after it |
| D: reconcile outcomes | Match cohort/outcome/experiment/series identity; compare schema/units/count basis/dimensions; all qualifying candidate series in a scalable comparison; editable authoritative series; save/cancel and Complete gate; history/export provenance | U,M and schema compatibility. O is required for newly configurable schemas, not existing fixed-schema results; I only when derived inputs are used. S10 dependency expansion |
| A: enhancements | Automatic pairing, κ/CSV, assignment notifications, advanced replay/migration UX, schema authoring, richer expression language | Explicit contracts/fixtures and owners; not first-slice prerequisites |
Do not substitute a separate feature flag per horizontal layer for an end-to-end release boundary. Flags must have a defined reader/writer compatibility and rollback path. A flag cannot make newly written incompatible data safe for legacy readers.
First-slice acceptance in concrete terms¶
- Configure project form F with target two reviewers and pinned question requirements. Stage A has screening plus a dependent F step; Stage B also references F. Stage settings are versioned and bind profile/form versions. Neither step owns another copy of F's target or evidence.
- Alice's Include unlocks dependent new work under the personal-plus-veto rule. Bob's personal Exclude blocks his route. Collective satisfaction can admit an unvoted Carol when configured without inventing her vote; other reviewers' decisions stay hidden.
- Autosave preserves draft changes/history without creating an explicit session version per edit. Save creates an immutable incomplete version, with no completed contribution or implicit screening vote. Complete validates and creates an immutable completed version that can qualify for F.
- Alice opens F through both stages: the same reviewer-owned study/form session is accessible subject to each workflow's permission/admission. Her completed contribution counts once toward F's shared target. Reopening, retries and another stage entry do not add a reviewer contribution.
- Compatible Q1/Q2 answers are shared with overlapping form G, which additionally requires Q3. F and G can have different completion states. Revision provenance retains the exact original stage/step/settings/question context; reuse does not rewrite ownership or authoring history.
- A step's accepted-gold visibility policy, with stage default, supports independent or informed work. Own prior answers remain accessible; other candidates' individual answers remain hidden. Record the exact accepted revision actually shown and the snapshot available. Qualifying informed work counts for ordinary progress; agreement distinguishes it from independent work.
- Collective Exclude blocks new dependent work. Previously saved work can be finished by default (EW1), subject to personal Exclude/permissions; Preserve-only retains it without completion. Use the confirmed stage default with advanced per-step override. No Include vote is invented, and sufficiency-change behavior is not inferred from this default.
- Autosaved corrections leave the current explicit version unchanged. An incomplete Save becomes current, so the session stops counting as completed; validated Complete restores one completed contribution. Preserve immutable history/provenance and separately indicate draft changes. Publication statistics/treatment distinguish completed, saved incomplete and draft-only sessions without duplicate sessions/reviewers. Compatibility and adoption for new requirements follow explicit admin policy; apply recovered requireReanswer/autoUpdate/doNothing choices; exact unfinished-work effects need design.
- Adding Q3 to F creates F-v2. Publication automatically checks sessions under any previous F version; if any exist, the admin prompt explains effects on drafts, completed contributions and all shared stage uses. Earlier completed contributions count against updated requirements according to the chosen transition policy. Original submissions/provenance remain immutable; policy choice does not manufacture Q3 or approve incompatible-answer reuse. Category-specific application/confirmation and concurrency must be specified before implementing this prompt.
- Accepted gold is an immutable study snapshot of exact reconciled revisions. An approved change creates another snapshot retaining unchanged references. Session context records what snapshot was available, and answer provenance records evidence actually shown. The confirmed dissent/query workflow is not required to be fully implemented to demonstrate this contract.
- Flag-off legacy behavior, historical defaults, authorization, allocations/claims, source/navigation and outcome entry pass regression acceptance. Legacy adoption is rehearsed separately with provenance and rollback; no historical approval or version is fabricated.
- Form/question publication verifies relevant version-aware materialized usage at a protected current source boundary. Stale statistics wait for catch-up or targeted refresh; missing evidence never passes as zero. A concurrent dependency-relevant write cannot escape the admin impact choice. Any necessary pause is scoped with safe failure release. Aggregate impact counts and authoritative affected-record enumeration agree for shared cross-stage sessions; actual transition identities are not inferred from counts.
Additional acceptance for applicable update/query slices: requireReanswer preserves the invalid old answer as Needs updating and blocks Complete until valid replacement; optional reason/guidance persists with the question version and empty reason warns without blocking publication. Query examples must cover individual mixed dispositions within one accepted-version work item, permitted audited self-review, private resolution notices, and invalidated children resolved before new gold. QY8 demonstrably addressed concerns close individually; QY9 settles unsatisfied-concern handling; concurrent races remain engineering work. These are confirmed boundaries, not a requirement to implement query infrastructure in the first shared-form slice. Pause/retry UX remains a recommendation.
Next design batch — owner directions already settled:
| Detail to propose | Recommended design work | Status |
|---|---|---|
| Application of recovered publish-time choices | Present impact on all prior-version drafts, completed contributions and shared cross-stage uses; distinguish admin transition/counting policy from answer compatibility, preserve originals and make adoption/concurrency effects clear | FV1–FV3 already confirm prompt and admin-dependent counting. No universal count/does-not-count default remains to ask Chris |
| Action permission and assignment mechanics | Map individual assignment, expiry override and release to existing admin authority; specify finer delegated grants, start detection and release/reacquire concurrency | EW1 stage/per-step placement and BL1 stage identity blinding are settled. Specific additional-review permission required; no implicit reconciler grant |
| Shared draft and Save/Complete concurrency | Engineering proposes stale-base handling, event/storage semantics and atomic immutable version/receipt publication without duplicate contributions | Semantic lifecycle and sharing are confirmed; mechanics remain to design |
| Publish statistics freshness/concurrency | Propose relevant usage families, protected source boundary, dependency-based write fences, catch-up/specific refresh and scoped pause recovery; enumerate actual records consistently | PS1–PS3's materialized/current-at-publish gate is confirmed. Protocol details require evidence and existing statistics owner coordination, not a new question about whether freshness matters |
| Query implementation details | Specify stale-version/concurrent resolution, queue assignment and notification delivery under the confirmed QY1–QY7 boundaries | Gold effectiveness, per-version grouping/individual disposition, child validation, authorised self-review exception, optional rejection explanation and viewer-to-query permission are confirmed; QY8 closes clearly addressed concerns, while QY9 settles unsatisfied-concern handling; races remain engineering |
| Publish-pause UX | Consider active-reviewer warnings, visible exact-version queued idempotent retry and action-needed messaging | Conversational recommendation, not approved by Chris; PS1–PS3 publication gate remains confirmed |
Resolved from the earlier batch: OD14/SF1 shared reviewer form sessions; OD19/SF2 form-owned target/sufficiency across stages; PV1/PV2 exact revision provenance and versioned stage bindings; SL1–SL3 autosave/Save/Complete effectiveness; VS1/VS2 accepted-answer visibility and independent/informed statistics; FV1–FV3 publish-time handling; PS1–PS3 current materialized impact evidence and recorded choice gate; EW1 Allow completion default. Retire the earlier per-step first-slice recommendation and do not ask for reconfirmation.
Legacy mapping and concurrency need engineering proposals with evidence. RD17, finer assignment grants and concurrency, matching weights, κ formula and detailed schema-field/event-count specifications remain scoped work (OC1 initial scope settled), not reasons to reopen the confirmed shared-form model.
Active work to integrate, not duplicate¶
Status was inspected on 2 October. Titles identify the work precisely; no open PR is assumed merged.
Verification performed and remaining limits¶
- Safely extracted the supplied ZIP; preserved the source files and recorded SHA-256 hashes in the companion evidence manifest. No instructions embedded in documents were executed as authority.
- Read the five v10 specification/register/plan documents and reviewer reference; compared the earlier step, eligibility, integrated-domain and reconciliation/versioning sources with scoped current source files and open-work inventory.
- Confirmed42 Open/2 Resolved, and identical Review Page/Review Form bytes (SHA-256
29adb6b5cf383e5b273aaac7f8817a0c446c2dd22474b504d5231306c240bdbc). - Rendered the main v10 prototype in a fresh browser context, navigated Overview→Full-text stage designer, and rendered the standalone reviewer page. Those inspected views emitted no page errors. At925px the reviewer document had925px scroll width; this is a smoke check, not complete responsive/accessibility acceptance.
- Initial offline-only render was blank because
support.jsloads React from unpkg. Retried with public runtime/font dependencies available. These files are not a self-contained offline executable despite bundling design assets. The runtime is React; production SyRF is Angular. - Verified main source already includes the outcome cell dialog with local edits, Standard/Spreadsheet mode and save/cancel boundaries. This supports RD16's restoration direction; no live production browser or deployment flags were checked.
- No application code, runtime tests, migration, deployment, publication or remote PR mutation was performed. Main checkout and existing dirty research documents were preserved. The comparison is reviewable planning work; full prototype acceptance, algorithm proofs and integration validation remain part of later scoped implementation.
Source references¶
Current-code links are pinned to the fetched commit. Repository-relative plan links refer to this research worktree's current documents; the companion package includes their snapshots.
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:
- Permission matrix proposal
- RBAC primary-source research
- Outcome-data migration plan
- Lifecycle and gold-answer settings proposal
- Implementation sequence
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.