Open questions, contracts to settle and provisional assumptions¶
Temporary planning document; planning only. Settled decisions are in the decision register and are not asked again here. This page lists only what is genuinely undecided, when each answer is needed, the recommended answer, and what the integrated plan does until an answer arrives. Nothing here is built without consent. "Needed by" names the release or gate that cannot pass without an answer. Every recommendation is a proposal. Release and gate names follow the integrated plan §5–§6.
Revised after the round-2 review (3 October 2026): Batch D added; engineering items E36–E93, assumptions A-25–A-40 and UI validations U30–U45 added; several items rewritten. Batch D1 was answered the same evening (decision register §1.13).
1. Owner and product decisions for Chris¶
Answered by Chris on 3 October 2026¶
These are settled and recorded in the decision register §1.11 (D1-01 in §1.12; D1-02 to D1-09 in §1.13). The original question texts follow below for traceability.
| ID | Decision | Where it lands |
|---|---|---|
| Security | Fix now: owner-only ownership transfer, and no grants of owner-reserved activities (ChangeOwner, AssignPermissions, Delete) | PR #3964, merged 3 October 2026 (85e6facf7); R1b entry criterion (met) |
| Q-10 | Make the #3944 changes, with conversations on their own flag (route a) | PR #3965, stacked on #3947 |
| Q-07 | Pilots are new projects and the seeded projects in staging and preview; add seed projects where helpful | Acceptance criteria §6 |
| Q-08 | Harvest the QM v2 stack | F1a |
| Q-09 | #2224's author has left; harvest the work into R1c | R1c |
| Q-13 | As recommended | R1a; C17 |
| Q-03a | As recommended | R1c, R1d; C10 |
| Q-25 | As recommended | Plan §5.11 |
| Q-31 | As recommended | R2c; C8 |
| Q-06a | Approved, plus ASySD deduplication inside SyRF and manual reporting of steps done outside SyRF | PRISMA amendments K and L; P1, P2, R5b |
| D1-01 | Keep #3964 for the ownership fix; port #3969's active-member check and tests; close #3969 | PR #3964, merged 3 October 2026 (85e6facf7); #3969 closed |
| D1-02 | As recommended: #3961's Phase 0 fixes continue; #3985 and #3973 are F1a prerequisites (X-ARCH-a); #3986 is decided before R0 guards PM consumers; #3988 is folded into E24 or deferred until after R2a; #3989 runs only as L5 seam slices until R3a ships | Plan §6.1 F1a entry; delivery operating model §15; programme integration §10, §12 (X-ARCH-a to d) |
| D1-03 | As recommended: activate the ProjectStatistics families this plan uses (#3987); freeze is not chosen, so Q-31(b) is not extended to GA. The activation date is still to be set; G0 needs it | Plan §6.1 F1a entry ("#3987 decided"); X-STATS-b1 to b7 on the GA path |
| D1-04 | As recommended: implementation is authorised per freeze gate through Chris's approval of each gate's dossier; merges keep his /approve, batched daily; product decisions, production enablement and adoption waves stay with him |
Plan §6.1 and §12; delivery operating model §2, §3 |
| D1-05 | As recommended: merge the owner ledger, this package and its research inputs to main as a docs-only PR (PR #3617); promote contracts into ADRs and feature specs as they freeze. Merged on 3 October 2026 (PR #3617, f5318074d) |
G0 entry (step 0); plan §11, §12 |
| D1-06 | As recommended: five CAMARADES reviewers and administrators for T1 releases and three for the rest; sessions batched monthly; at least two external SyRF users where possible. The names are still needed for G0 | Acceptance criteria release tiers and §5; UX strategy §9; G0 exit |
| D1-07 | As recommended: opt-in production pilots for new projects after staging acceptance, R0's production soak and AF2 per-project admission; one production pilot per family (R2, R3, R4a) before GA | Plan §9; acceptance criteria §5.2; A-23 |
| D1-08 | As recommended: the FEAT-024 gate (b) shape at 1, 2, 5 and 10 concurrent reviewers; start budgets Save ≤ 150 ms and Complete ≤ 300 ms (p95, 200-question form); tiers of 50, 340 and 2,023 questions; E28 in pins and bytes. F1a confirms the thresholds from M0 evidence | AC-M0-02, AC-ALL-26, AC-R2a-19; M0 go/no-go; F1a |
| D1-09 | As recommended: #3964 (done), then #3932 → #3938 → #3941 → #3942 → #3943 → #3944 → #3965 → #3945 → #3947. Restacking #3965 onto #3944 needs the stack owner's agreement; otherwise it stays on #3947 and lands in the same train before any environment enables conversations | Notifications integration merge order; programme integration §8; X-NOTIF |
Correction to Q-25's tracking line (round 2, 3 October). Q-25 stands as decided. Its
recommendation said activeReviewerTrackingEnabled is "not needed for slot-reservation claims"; that
premise was false. Claims, capacity guards and typed admission exist only when tracking is on, and
tracking is off in every deployed environment (on only in the E2E stack). Enabling it is a FEAT-024
durable reviewer-mode transition with no owner (M15), and it never protects reconciliation. So R2b's
claims, R3a's reservation admission and any capacity promise need a production claims route
(X-CLAIMS), now put to Chris as D3-16, and R4a needs the reconciliation-task editor claim in every
environment (X-RECLAIM). See programme integration §6.
Original question texts (answered):
| ID | Question | Recommendation | Until answered | Needed by |
|---|---|---|---|---|
| Q-10 | What must hold before #3944's reconciliation conversations are enabled, and how should it merge? #3944 adds reconciler questions to selected candidates behind studyAttention; #3945 (study issues) and #3947 (PDF proposals) are stacked on it and share that flag. As inspected: every participant sees every reply (conflicts with VS1 candidate isolation); incomplete sessions can be questioned, and the reviewer's link opens the editable review route (an independence and exposure risk that extends the PV1/VS2 principle; VS2 itself concerns accepted answers); any Reconcile holder can start a thread, including one who reviewed the study; threads are stage-scoped and owned by their creator (gaps against RE4 and RA4); labels are unstable (BL1); threads stay usable after gold exists (overlaps QY). |
Required before conversations are enabled, not necessarily before merge: reviewer-private (one-to-one) visibility; an exposure marker on any questioned session plus a read-only context link; a reconciler-eligibility check, so a reconciler who reviewed the study can't start a thread; requested additional reviewers excluded until they return their review. Merge route: (a) give conversations their own flag that depends on notificationInbox, so #3945 and #3947 can be enabled separately; (b) restack #3945/#3947 below #3944; or © merge with the flag off and gate enablement on the changes. Recommend (a). Task identity, handover, stable aliases and open-task-only threads become R4a follow-ups. Explicit reconciliation assignees are notified. Details: notifications integration §2. |
Conversations stay disabled; the plan treats #3944 as a clarification channel, never as queries | Before conversations are enabled; F4 |
| Q-07 | Which projects pilot each release (R2a/R2b, R3a/R3b, R4a, C1, O1)? | Start every release on synthetic projects in the local e2e stack and on staging (both disposable), then one or two real, low-risk projects that Chris nominates, admitted through R0's admission service. Pilot entry criteria follow plan §5.10: R2 pilots need no reconciliation before R4a, or use target-1 forms (Q-29); R3a pilots using Stop on a profile that feeds a cross-stage route accept waiting for R4p. Production pilots wait for Q-25. | Synthetic and staging acceptance only | R2a pilot |
| Q-08 | What should happen to the dormant QM v2 stack (#2572–#2575, plus #2461)? | Harvest, don't revive wholesale. Audit #2572's AQ/AQV/QSV domain and #2573's impact/transition services against C1/C4; port what fits into small new PRs; close the stack once harvested. | Reference code only | F1a |
| Q-09 | Should #2224 (custom project groups, authored by nurikarakaya, conflicting) become the basis for R1c? | Reuse its API shape and tests, as the authorization plan's D10 already says, rather than merging it as is. Agree the route with its author: they rebase it in slices, or agree a hand-over. | Groups UI designed, not started | R1c |
| Q-13 | The question area's name: v10's alternate navigation calls it "Library", but Study Management already uses "Library" for studies. And what do we call the reusable question collection? | Keep "Library" for studies. Group definition work under "Design". Call the reusable collection "question templates", not a library. | Docs use "Design" and "question templates" provisionally | R1a |
| Q-03a | Who may create and edit project groups, and under which anti-escalation rule? (The group part of the permission matrix, needed early so the authorization programme can plan WP11.) | Group create/edit under EditMemberships. An editor can't add themselves or anyone else to a group whose grants exceed what the editor may administer. ChangeOwner is never grantable (ownership transfer stays owner-only, PM1); AssignPermissions is grantable only through R1d's delegation envelope (PM2); Delete follows Q-03. | Existing groups only | R1c |
| Q-25 | Production pilots depend on environment-wide flags owned by other programmes. Which route does each owner agree? | Per flag, agreed with its owner: annotationFormV2 (AF2 programme): per-project admission through AF2 eligibility, which already falls back to v1; this is an AF2 contract change because eligibility must read the generated selector. stageReviewRedesign / stageReviewDockview (stage-review programme): per-project admission or production readiness where the new UI extends the shell. reviewEligibilityPolicy (eligibility programme): enable after the reservation migration and the D7 tool, or per-project admission. activeReviewerTrackingEnabled (presence owner): not needed for slot-reservation claims; R4a uses a dedicated reconciliation claim if tracking stays off. Notification flags: never a release dependency (feature queues). FEAT-024 flags: per Q-31. |
R2–R4 pilots run on staging only | Any production pilot |
| Q-31 | PS1 in production. PS1 asks for materialized, version-aware usage statistics at publication. FEAT-024 is dark in production and refuses fold enable on the production database until its gate (b). For R2c production publication: (a) wait for the FEAT-024 usage family plus production activation, as an explicit cross-programme dependency; or (b) for named pilot projects, accept authoritative counting and identity enumeration from canonical records under the same protected boundary, switching to the materialized family once it is live? | (a) as the target. Allow (b) only for named pilots, and only if gate (b) isn't reached when R2c is otherwise ready; (b) keeps PS3's protected boundary and never treats missing evidence as zero. | A-08 applies: strict PS1; R2c production waits for gate (b) | F2 |
| Q-06a | Approve the PRISMA amendments that shape writes, through the FEAT-011 change policy: A (within-stage admission and configurable routing separate from collective outcomes; "entering screening" defined as protocol scope or actual release, including shared batches and personal grants), C (one downstream source column from the earliest import), D (admin-reviewed dedup when review evidence exists; no double counting), and the new G (per-project adoption replaces platform-wide MIG-11/MIG-12), H (screening outcome per profile with route provenance instead of one stage ID, authority values including legacy-compatible/unknown, structured reason with coverage status), I (canonical-aware rollback replaces $unset rollbacks) and J (deletion and withdrawn searches keep Citation history, per Q-33) |
Approve, so amendment PRs land before the P1 build and the F3 freeze | P1 and R3a don't write PRISMA-shaped data | F3, F-P |
Batch B: needed before the F2, F3 and F5 freezes and P1¶
| ID | Question | Recommendation | Until answered | Needed by |
|---|---|---|---|---|
| Q-03 | Approve the rest of the permission matrix: the new capability list, defaults beyond PM1's ordinary-admin rule, a non-recursive owner-managed delegation envelope, and each capability's mapping to its view | Approve the matrix proposal, with one rule: each new capability ships with the feature that uses it. Subsets: catalogue at G0 (so F1b can freeze C10); Publish at F2; stage-lifecycle approval and Monitor ("Who is offered what") at F3; reconcile, assign, request an additional review and view agreement at F4. | Existing grants only; no new capability identifiers | G0 (catalogue subset, earlier than the rest of Batch B), F2–F4 subsets; R1d |
| Q-20 | Approve or replace the publish-pause UX recommendation (active-reviewer warning, queued exact-version retry). Also: when should "contains outdated annotations" (SF5) send a notice rather than only flag the session in-app? | Approve a minimal pause version: an admin impact summary and a non-disruptive reviewer notice only when action is needed. The active-reviewer warning needs a form-scoped "who has form F open now", which needs presence keyed by form with tracking on; the minimal version drops it. Outdated annotations (PROPOSAL, narrowed): no notice when the session owner caused the flag (candidate answers are their own, and the ledger already requires an in-form alert); otherwise one in-app notice per recipient per cause, when the cause is a support on-behalf-of write, an adoption remap or a shared-gold revision. (A publication never causes this flag: under D2-01 its autoUpdate writes no revision, and Q-34's derived mapping revisions are excluded from outdated flags; its effects reach reviewers through the "form version published" notice.) |
Publication without a pause; reviewer writes fenced by the protected boundary; outdated annotations flagged in-app only | R2c, R2d |
| Q-27 | Approve the ledger's "proposed effects" of an incomplete Save, and the cascade rule for cross-stage corrections | Recompute shared sufficiency and dependent applicability; show affected steps as needing reassessment; never silently reopen, delete or change gold or screening decisions as a side effect (ledger "Current state…" section; OD16) | Effects designed but not activated | R2a (Save effects), R3a (cascade) |
| Q-34 | QM v2's publication wizard offers "map answers to updated options", which transforms recorded answers. Is that an approved form of autoUpdate under FV3? | Allow only as an explicit per-option mapping recorded in the publication policy, applied as new revisions with provenance (old revisions untouched), and only where an option's meaning is unchanged; otherwise use requireReanswer | R2c offers requireReanswer, autoUpdate (carry forward unchanged where compatible) and doNothing only | F2 |
| Q-15 | Cross-stage routing interpretations: candidate rules for the default and for the advanced option | (a) Default, collective required. Options: Mode B, collective Included admits anyone (even a personal Excluder); Mode C, both personal and collective Include required (unvoted reviewers never admitted); or a hybrid, collective Included admits unless the reviewer personally Excluded. Recommend the hybrid: it matches the within-stage veto on personal Exclude and lets unvoted reviewers proceed without an invented vote. (b) Advanced option. Either a relaxation (own Include or collective Included admits) or a replacement (only own Include admits, as in the access-policy proposal, where "personal policy + no own decision" means the prerequisite is still to do). Recommend the relaxation, so the faster option never blocks someone the default admits; this departs from the access-policy proposal. | Assumptions A-06 and A-18 | F3 |
| Q-24 | Confirm how the review-eligibility programme's decisions carry into the step model. D3a ("no closure concept") is superseded for the new stage model by the later LC1/RX2 under the precedence rule; this is recorded, not asked. Confirm: (a) D3b (independent contributions; the AnnotationHasNoScreeningPrerequisite test) applies to independent steps and migrated combined stages, while configured dependency edges follow DP6/DP7; (b) D1/D2 Allow/Stop for new screening votes after sufficiency becomes a combined-step "extra-vote admission" setting, with migrated combined stages keeping their resolved values and new combined steps defaulting to Stop; © D4 (refuse newly unavailable activity after a stage is disabled or its mode changes, preserving drafts) applies to step availability changes and coexists with EW1; (d) D6 capacity and "Apply anyway" semantics carry into typed claims (C7). D5 (excluded work) and D7 (keep each stage's mode in migration) carry over unchanged. |
Confirm all four; amend the eligibility policy document in the R3a PRs | R3a design follows this mapping (A-16) | F3 |
| Q-26 | Does the FV1–FV3 publication model apply to screening-profile versions? That is: a publish-time check over decisions cast under prior profile versions, an admin choice of treatment (keep pinned, require a new decision, or compatible carry-forward), collective outcomes recomputed only under that choice, and PRISMA snapshots frozen | Yes, mirroring form publication; profile changes never silently alter cast decisions, collective outcomes or past reports. #2621's screening-profiles prototype shows a per-stage migration policy (keep on old version / re-screen / archive stage) that becomes per profile under DP4. | Profile versions publishable only before any decision exists | F5 |
| Q-28 | Some stage-owned policies apply to evidence reachable through several stages: BL1 blinding for one study × form reconciliation task (RE4), EW1 on one shared session, VS1 on a shared form, and tracking's settings on a shared form (EnforceAnnotationTarget, the idle timeout, MaxInProgress, and the binding-scope tracking setting proposed for #3876). Which policy applies when the stages differ? |
Task blinding uses the most restrictive setting among the stages that can reach the task. EW1 is evaluated for the route (stage/step) the reviewer is using and never changes the shared target. VS1 is evaluated per route, with exposure recorded per PV1/VS2. Tracking settings (D3-18): the most restrictive bound stage sets the capacity cap and the idle timeout; the stage in use sets the in-progress limit, counting a shared session once; the form is tracked if any bound stage is. | Pilots use one stage per form, or identical settings | F3 (EW1, VS1, tracking), F4 (BL1) |
| Q-12 | Reviewer page structure: one form area driven by the selected step (v10 r4), one card per step (v10 p1), or the earlier three-card page? | A step strip plus one form area inside the existing AF2/Dockview workspace; validate in user testing (U7) | Prototype both; ship neither until U7 passes | R3a |
| Q-01 | Should optional strict within-stage collective gating exist, and in what form? | Yes, as an advanced stage setting with a tighten-only step override, default off, shipped in R3c once pilot users confirm the need | R3a ships own-Include within-stage only (DP6) | R3c |
| Q-02 | Approve the exact LC1 flow: a pending change request for a Completed stage, admin approval of that specific change, a recheck at commit, automatic transition in automatic mode, an explicit Reopen in manual mode, and the same gate for new arrivals | Approve the lifecycle proposal | Lifecycle work stays at design level | R3c |
| Q-30 | Default values for confirmed settings with stage defaults: VS1 (show reconciled answers to candidates), BL1 (reconciliation identity blinding), RA3 (expiry for explicitly assigned, unstarted reconciliation work) | VS1 off (independent workflows by default); BL1 blinded with stable aliases; expiry 7 days, changeable per stage, with audited per-assignment override | Settings ship only with these values visibly marked provisional | R3a (VS1), R4a (BL1, RA3) |
| Q-33 | Search and project deletion currently fail closed until the reversible-deletion scheduler exists. When a search is withdrawn, what should PRISMA show? | Citations stay immutable identification history; a withdrawal is an appended event; current reports exclude withdrawn searches and say so; frozen reports never change (amendment J) | P1 records nothing for withdrawal; deletion stays disabled | F-P |
| Q-37 | Confirm the detailed rules proposed for the two amendments Chris asked for: K (external step records, how reported counts combine with computed ones, the consistency warning, no double counting, who may enter counts) and L (FEAT-012 implemented as specified, the ASySD parity tolerance, no hard deletes, reviewed merges through the engine, admission exclusion); and the round-2 extensions to K (entry phase per search or import, per-box combination, K.2/K.3 agreement, box 1 per D4-11, withdrawn searches) and L (merge as an alias per D2-12, scenarios by form and profile, privacy, extended pool exclusion, QC sample and reviewer flag, parity metric per D4-21) | Approve as written in PRISMA amendments K and L, including the parity tolerance in AC-P2-01r, as revised after the round-2 review (3 October) | P1 records no external counts; P2 waits | F-P (K), P2 (L) |
Batch C: needed before F4, F6a, F6b, R5c and the remaining lanes¶
| ID | Question | Recommendation | Until answered | Needed by |
|---|---|---|---|---|
| Q-29 | How do target-1 forms (one reviewer, common for extraction) reach gold, and how are legacy single-reviewer studies adopted? Under RE2/AG2, gold needs an explicit final reconciliation submission; earlier designs auto-promoted single-annotator studies (QM v2 RECON-03, MIG-08; annotation-versioning migration step 6). | Target-1 forms create no reconciliation task. The single qualifying assessment is the effective answer for exports, labelled "single reviewer, unreconciled". An optional "accept as gold" action by a reconciler creates an attributed snapshot when a project wants gold. Never automatic promotion, including at adoption. | Target-1 exports show unreconciled answers, labelled as such | F4, R6 |
| Q-35 | How are legacy reconciled answers (one overwritten set per question, authority unknown) treated in exports, queries, R4a readiness and adoption? | Exportable as "legacy reconciled (authority unknown)"; never a gold snapshot (GS1); not queryable through QY; R4a treats such a study as still needing canonical reconciliation for gold; a canonical task supersedes it with explicit provenance | Legacy projects keep today's exports. An aggregate-only production count of legacy reconciled sessions runs off-peak before F4 (a first read-only attempt on 3 October timed out on an unindexed scan); if the count is near zero, Q-35 shrinks to a fail-closed refusal. | F4, R6 |
| Q-36 | Default authority policy (research §8 #3): may any project permit self-reconciliation (today's AllowSelfReconciliation stage setting has no writer), which adjudication overrides need explicit grants, and may a gate use stale authority for new admissions? The ledger already rules out a blanket self-review exception for ordinary reconciliation (QY4's audited self-review applies to query review only). |
Explicit grants for overrides; no self-reconciliation by default; authoritative gates require current authority, and a stale result is shown as needing revalidation, never as freshly reconciled; saved work stays | A reconciler is never offered a study they reviewed; stale authority pauses new admissions | F4, R4p |
| Q-04 | Approve (a) a gold-completeness setting (project default "Follow question requiredness", form override, no stage override) and (b) a missing-state statistics contract (missing = "comparison not assessed", reported separately; Unknown/Not reported is a recorded state) | Approve both as proposed | R4a follows requiredness only (UA1-consistent); statistics show missing counts without an agreement value | F4 / R5c |
| Q-11 | Should admins be able to bulk-approve studies where every candidate agrees (v10 §3; QM v2 RECON-09)? | Optional per-form setting after R4a, default off. RE2 still applies: approval is an explicit final acceptance by an authorised reconciler of displayed valid answers, shown per study with the unseen-content warning summarised. Recorded with candidate-agreement provenance; never automatic gold. | Not built | After R4a |
| Q-32 | v10 lets a profile require a rationale for a reconciled screening decision, with a blocking error. RE1 makes reconciled-answer explanations optional. May a profile require a rationale for an adjudicated screening decision? | Allow as a profile setting, default off, for screening-decision adjudication only (RX1); RE1 stays for ordinary reconciled answers | Rationale optional everywhere | R4p |
| Q-05 | Approve the outcome-migration plan: read-only dry-run first, approved manifest, staged copy, project-scoped fence, rollback boundary | Approve the plan, with the default-value rules (legacy false direction, SD, mean and zero counts treated as "value or default, unknown" unless an explicit answer is proven); execution needs separate authorisation |
Read-only design and synthetic dry-run only | O2 |
| Q-06b | Approve the remaining PRISMA amendments: B (report identity and records/report multiplicity), E (reasons coverage and gold separation), F (time, protocol amendments and frozen reports) | Approve, so reporting work can start at F6b | Exports label citation totals as records, not reports; no complete-diagram claim | F6b |
| Q-17 | Field-level specification of the event-count schema, and what "variation" means | Domain specification by Chris or a CAMARADES methodologist before the O1 build | O1 builds catalogue infrastructure and the legacy-compatible schema first | F-O |
| Q-18 | Scope of the first classification reasoner | Conjunction, containment, disjointness and exhaustiveness only, as the research recommends | C2 design assumes that scope | C2 |
| Q-19 | Who may publish project rules and shared-concept mappings? | Design capability publishes rules; reviewers confirm per-paper applicability through mapping answers; reconciliation applies as normal | Design-only authority | F-C |
| Q-16 | Agreement formula and denominators for more than two reviewers and for entities (AG2's identical-set rule for multi-selects is settled and not reopened) | Method review with a statistician; show percent agreement plus explicit denominators first | Percent agreement with counts only | R5c |
| Q-22 | PRISMA reason reporting: one primary reason or several counted reasons per excluded study? | Follow the FEAT-011 primary-reason MVP; report coverage when reasons are pending or off (amendment E) | Primary reason plus coverage status | F6b |
| Q-23 | PRISMA report multiplicity: approve report identity as in amendment B, or keep labelled citation totals? | Approve amendment B; until then label totals honestly | Labelled totals | F6b |
| Q-21 | For each existing project adopted later, what did its legacy screening represent? | Admin-reviewed labelling of a "legacy project screening" compatibility profile, set at adoption | Legacy projects stay on the legacy path | R6 per project |
Batch D: decisions raised by the round-2 reviews¶
The round-2 reviews (see the round-2 resolution matrix) produced the 71 decisions below, each with a recommendation. Batch D1 is answered: Chris decided D1-01 on 3 October and approved D1-02 to D1-09 as recommended that evening (decision register §1.12 and §1.13). The other 62 (D2-01 to D2-16, D3-01 to D3-25 and D4-01 to D4-21) are open: none of them is decided until Chris answers. They are grouped by when the answer is needed. "Source" names the review findings behind each one.
D1: needed before G0 (operating model and delivery)¶
All nine are answered. Parts still open: G0 needs D1-03's activation date and D1-06's tester names; F1a confirms D1-08's start thresholds from M0 evidence; D1-05's merge (step 0) is in progress; D1-09's restack of #3965 onto #3944 depends on the stack owner agreeing. G0 itself, Chris's approval of this package, has not happened, and nothing is built before it (decision register §1.13, "What G0 still needs").
| ID | Question | Recommendation | Until answered | Needed by | Source |
|---|---|---|---|---|---|
| D1-01 | Answered by Chris on 3 October 2026: keep #3964. #3964 (this plan) and #3969 (the architecture review) fix the same defect. | Decided as recommended: keep #3964. It compares the caller with the persisted owner, so a stored ChangeOwner grant cannot bypass it (the policy #3969 relies on is satisfiable by such a grant), and it also refuses owner-reserved grants and fixes the UI. Port #3969's active-member check and its tests into #3964, then close #3969. Carried out: #3964 merged on 3 October 2026 (85e6facf7) and #3969 is closed. |
Neither merges | Decided (3 October 2026); it was needed by G0 and before #3941 merges, because both edit ProjectController.UpdateProject |
DS-19, DS Q7, #3964 verifier |
| D1-02 | Answered by Chris on 3 October 2026: as recommended. Precedence with the architecture-review roadmap (#3961). Both programmes compete for the same approver, agents, CI and files, and #3961 changes foundations F1a freezes. | Decided as recommended: #3961's Phase 0 security fixes continue as they are. #3985 (non-upsert saves, version bump on direct writes) and #3973 (await domain events) become F1a prerequisites (X-ARCH-a). #3986 (MassTransit after v8) is decided before R0 guards PM consumers. #3988 (v0/v1 schema retirement) is folded into E24 or deferred until after R2a. #3989 (web state convergence) runs only as L5 seam slices until R3a ships. | Both proceed independently, with collision risk | Decided (3 October 2026) | DS-02, DS Q1 |
| D1-03 | Answered by Chris on 3 October 2026: activate. ProjectStatistics: activate or freeze (#3987), and what counts as current statistics at GA. | Decided as recommended: activate the families this plan uses, on a date still to be set. Freeze is not chosen, so Q-31(b) (authoritative counting at the protected boundary) stays for named pilots and is not extended to GA; GA depends on X-STATS-b1 to b7. | Q-31(b) stays pilot-only; GA depends on X-STATS-b | Decided (3 October 2026); the activation date is still needed for G0 | DS Q2, MS-01 |
| D1-04 | Answered by Chris on 3 October 2026: as recommended. Implementation authorisation per freeze gate instead of per PR. | Decided as recommended: yes. Chris approves each gate's dossier, including its slice list and its decisions. Merges keep his /approve, batched daily. He keeps every product decision, every production enablement and every adoption wave. Nothing is built under this plan before G0. |
Per-PR authorisation (§12) | Decided (3 October 2026) | DS-01, DS Q3 |
| D1-05 | Answered by Chris on 3 October 2026: as recommended. Commit and merge the owner ledger, this package and its research inputs to main now (they are committed only on the PR #3617 branch, not yet on main, so agents starting from main cannot see them). |
Decided as recommended: yes, as a docs-only PR (PR #3617). As contracts freeze, promote them into ADRs and feature specs; keep one append-only ledger on main. Merged on 3 October 2026 (PR #3617, f5318074d). |
The package stays on the PR #3617 branch only | Decided (3 October 2026); step 0 (G0's entry) merged on 3 October 2026 (f5318074d) |
DS-17 |
| D1-06 | Answered by Chris on 3 October 2026: as recommended. Tester panel and tiers. | Decided as recommended: five CAMARADES reviewers and administrators for T1 releases and three for the rest; sessions batched monthly; at least two external SyRF users where possible. The names are still needed for G0. | User-testing criteria cannot be run | Decided (3 October 2026); the testers' names are still needed for G0 | DS-16, DS Q6, review AC-25, AC Q7 |
| D1-07 | Answered by Chris on 3 October 2026: as recommended. Production opt-in pilots before GA (A-23). | Decided as recommended: yes, for new projects whose creators opt in, after the release passes staging acceptance, R0 has completed a production soak and AF2 per-project admission exists. One production pilot per family (R2, R3, R4a) is required before GA. | Pilots stay on staging and preview | Decided (3 October 2026); binding before the first production pilot | DS Q4, AC Q4, review AC-33 |
| D1-08 | Answered by Chris on 3 October 2026: as recommended. Write-path gate and scale commitment. A canonical Save writes several documents, so "no more than 1.2 × today's p95" cannot be met by construction. | Decided as recommended: the shape of the FEAT-024 gate (b): zero engine-caused exhausted submissions at 1, 2, 5 and 10 concurrent reviewers, same study and different studies. Absolute p95 budgets are set after M0, starting at Save ≤ 150 ms and Complete ≤ 300 ms on a 200-question form. Three benchmark tiers: typical (50 questions), p99 (340) and max (2,023, the largest real project). The form-size limit (E28) is expressed in pins and bytes per commit. The start thresholds apply now; F1a confirms them from M0 evidence. | M0 records numbers but nothing gates | Decided (3 October 2026) for the start thresholds; F1a confirms them from M0 evidence | DC-16, PH-01, VB-12, MS Q5, review AC-18, AC Q8 |
| D1-09 | Answered by Chris on 3 October 2026: as recommended. Notification stack merge order and #3965's place in it. | Decided as recommended: the ownership fix first (done: #3964 merged on 3 October 2026), then #3932 → #3938 → #3941 → #3942 (with tolerant preferences) → #3943 → #3944 → #3965 → #3945 → #3947 last. Restack #3965 onto #3944 if the stack owner agrees; otherwise keep it on #3947 and land it in the same merge train before any environment enables conversations. | #3965 waits on top of #3947 | Decided (3 October 2026); the restack of #3965 depends on the stack owner agreeing | NS-05, NS-17, NS §4.3 |
D2: needed before F1a (engine and versioning contracts)¶
| ID | Question | Recommendation | Until answered | Needed by | Source |
|---|---|---|---|---|---|
| D2-01 | Publication writes no evidence. Publishing a form version records a policy; its effects on sessions (qualifying, needs updating, pinned under an older version) are derived when read, and query-path projections are rewritten afterwards by a resumable operation. No session version is created by the publication itself; SF6's "creates a new incomplete session version" is read as "changes the session's effective status". | Yes. It keeps SL3 literally true (only a reviewer's explicit Save or Complete creates a version), scales to large forms, and makes FV4 revisions and late saves simple. | The versioning model stays unfrozen | F1a | VA-03, DD-10, DC-06, VB-06 |
| D2-02 | When is compatibility between question versions decided, and can it change? | Declared when the version is committed in the designer: SyRF suggests it from the change (removed or changed options, a new data type or multiplicity → incompatible; added options, wording, help → compatible), the admin confirms or tightens it, and it becomes immutable once any answer pins that version. FV4 revises the counting and re-answer policy of a publication, never the compatibility declaration. | Sharing, agreement and reconciliation rules can't be frozen | F1a | VA-01, VA Q1 |
| D2-03 | A data-type or single/multi-select change: a new question, or an incompatible version of the same question? Treating it as a new identity (FEAT-001 D38) recreates the whole subtree under the "parent is identity" rule and severs answer history. | An incompatible version of the same identity. Parent and owner scope stay part of identity; data type and multiplicity become version content, always classed incompatible. | D38 stays a proposal | F1a | VA-16, VA Q2 |
| D2-04 | What "stage settings bind form versions" (PV2) means. | A stage binds the form and records the version it bound and when. The live route always presents the session's resolved version; a Completed stage's frozen binding governs only its historical display and readiness. This is the only reading consistent with one session per study and form (SF1) and per-form publication (FV2). | Shared sessions across stages can't be specified | F1a | VA-08, VA Q5 |
| D2-05 | Operational settings outside requirement versions. Form target, reconciliation compare settings, gold completeness, guidance, DP5, resolution routes, allocation, batches and expiry would be audited settings that never trigger the publication impact flow; PV1's "stage-settings version" stamp refers to the requirement-bearing part. | Yes. Otherwise a target change or a DP5 toggle forces a publication and a decision over every session. | Every settings change mints a version | F1a | VA-07, VA-08, VA-19, AP-11 |
| D2-06 | System question versions. | Store system questions as versioned data (identity = question ID plus SystemQuestionVersion). A new CAMARADES version reaches a project only when its admin next publishes a form version; deploying code never changes a published form or prompts every project. | System snapshots stay per code revision (E24) | F1a | VA-09, VB-11, VA Q6 |
| D2-07 | Does an autosaved draft hold the reviewer's place? One review says never (earlier designs); another says yes until Save, Complete, discard, admin release or 14 days. | Middle ground: a draft keeps the place while the reviewer is active, under today's idle and disconnect timers counting draft activity, so nobody loses a place mid-work. When the timers lapse, the place is released but the draft is kept; the reviewer can still Complete it as an extra contribution (the target is a minimum, SF4) unless an optional capacity cap applies (D3-17), in which case they are told honestly. An unattended draft never blocks capacity for days. | Capacity rules for canonical sessions can't be frozen | F1a | PH-03, RT-09, RT Q-RT2 |
| D2-08 | Two tabs or devices on one session. | The second tab is read-only with "Take over editing"; the displaced tab's unsaved edits are kept as a recoverable conflict copy. | Two-tab behaviour stays undefined | F1a | DC-07, VA-12, RT Q-RT7, DC Q-DC4 |
| D2-09 | Shared-question gold across two forms. First publisher wins (others challenge only by query), or the second form's reconciler sees the existing gold prefilled as accepted and may revise it in their own final submission (a new snapshot with provenance)? | The second may revise. It keeps the second form's candidates, often different reviewers, in the gold decision, and keeps queries for later challenges. | First-publisher-wins stays a proposal | F1a (shape), F4 | VA-11, VA Q4 |
| D2-10 | Short, scoped pauses. Publication phase 1 drains in-flight saves for that form (target under 90 seconds); while a publication's follow-up operation runs, new study admission and reconciliation-readiness changes pause for that form only (reviewers keep saving; the admin sees progress; it stops and reports at a limit, e.g. 30 minutes); stage completion, stage settings changes (in-flight submissions may commit during the drain; the change takes effect after it) and adoption cutover use the same drain. | Yes. The alternative is serialising every save in a project through one document, which FEAT-024 measured as failing at ten reviewers. | Publication and completion consistency can't be frozen | F1a | DC-06, DC-09, VB-06, VB Q1, DC Q-DC2, DC Q-DC3 |
| D2-11 | One active publication per form at a time. | Yes. Publications are rare; this removes a class of policy-composition errors. | Overlapping publications stay undefined | F1a | VB-06, VB Q2 |
| D2-12 | Duplicate merge as an alias. Records stay attributed to the study they were made on; the primary study shows them as candidates with lineage; a split is a clean reversal; one reviewer who reviewed both is counted once. | Yes. Re-keying would rewrite immutable records. | Merges of reviewed studies stay unspecified | F1a (shape), F-P | V2-02, DD-08, DC-19, DD Q-D3 |
| D2-13 | Restore policy for canonical data. | No selective per-project restore. Whole-database point-in-time restore into an isolated database, then manifest-driven recovery; affected projects get a recorded history discontinuity that exports report. | Restore rehearsals have no target | F1a | DC-17, VB-20, DC Q-DC5 |
| D2-14 | Account erasure and immutable answers. | A deleted reviewer's answers stay in history under an anonymised identity; as-of exports stay identical except for erased identities, and the manifest records the erasure. | E32 stays open | F1a | VB-19, DC Q-DC6, VB Q4 |
| D2-15 | Who owns question, profile and form templates? | A CAMARADES-curated system catalogue (an application role), plus "copy from a project I administer". Copies only, never links. | Templates stay project-scoped | F1a (R1a scope) | DD-25, PH-27, DD Q-D1, PH Q11 |
| D2-16 | Initial size ceiling for canonical forms until benchmarks prove larger forms safe (the 2,023-question project stays on the legacy path even after adoption opens). | Yes; revisit after M0. | No ceiling | F1a | VB-12, VB Q3 |
D3: needed before F1c and F3 (UX, workflow and in-flight programmes)¶
| ID | Question | Recommendation | Until answered | Needed by | Source |
|---|---|---|---|---|---|
| D3-01 | What UI1 (Material 3) requires before FEAT-023's cutover. The app emits only Material 2 component themes today, with M3 tokens alongside. | Build new screens on M3 roles over the current components (no mixing), register every new route for the cutover baselines, and sequence FEAT-023's light cutover before R2a's reviewer UI if possible. The notification stack's inbox and preferences meet UI1 before testers see them; its conversation, issue and PDF screens before production. Dark-mode evidence comes from token checks and staging, where the theme toggle is on. | UI-3 can't be verified | F1c | UX-12, review AC-17, AC Q1, NS-10 |
| D3-02 | Design acceptance cadence. | A per-release walkthrough on one staging build, with per-PR preview acceptance only for new shared patterns and five high-risk surfaces (publication dialog, reconciliation workspace, stage designer, Members & groups, guided setup). Agents run tier-1 design QA on every PR. | Per-PR acceptance of every new screen (UI-8) | F1c | UX-13, review AC-25, AC Q2 |
| D3-03 | User-facing terms. | "Save progress", "Complete", autosave status "Changes kept, not yet saved", "Needs updating", "Outdated answers", "Fix", "Accepted answers (gold standard)" and "Screening result" (so "outcome" means measured outcomes). Never "Save draft". | Copy deck stays provisional | F1c | UX-05, PH-19, DD Q-D4, DD Q-D5, UX Q4 |
| D3-04 | Button and type language. | Material 3 sentence case across the reviewer page; re-audit the v4 stage-review spec (ALL-CAPS 13 px buttons) before further parity work. | Two button languages on one page | F1c | UX-07, UX Q3 |
| D3-05 | Phone screening. | Supported for title/abstract screening steps; annotation stays tablet and desktop. | No phone criteria | F3 | UX-15, UX Q6 |
| D3-06 | Visual refresh of legacy screens. Legacy projects stay legacy for years. | An M3 restyle of shared chrome and shared pages under FEAT-023, with no behaviour change, so the app doesn't look like two generations. | Two visual generations coexist | F1c | UX-11, UX Q7 |
| D3-07 | "My work". | A project-level "My work" surface (R3c/R4a) listing every actionable item by role, a cross-project tab and a global badge with read-time counts that work with notifications off, and an admin banner for pending stage-change approvals; a global landing page after GA. | Queues stay per project, unsurfaced | F3 | UX-08, NS-07, UX Q8 |
| D3-08 | Research participants and telemetry. | Recruit external SyRF users for sessions, and collect privacy-safe timing events on pilots (study opened → decision; form opened → Complete), with consent at pilot admission and no content captured. | Moderated sessions only | F1c | UX-01, UX-21, UX Q5 |
| D3-09 | The paused eligibility programme. | R3a absorbs the browser's consumption of the eligibility response (S6b) and, if the programme stays paused, S4-B, S4-C and S6a; map eligibility decision D8 as recommended (a disabled stage blocks only its own route; hiding excluded saved work becomes a display sub-setting of EW1; an authorised admin may start reconciliation before readiness with a warning; removal becomes a versioned withdrawal; claim release carries over). | R3a waits on X-ELIG | F3 | AP-09, DS Q5, PH-04, PH Q3 |
| D3-10 | Statistics integration. (a) A FEAT-024 read at the publication fence (stored row, or its pinned authoritative fallback, with identity recorded) counts as "current" for PS2/PS3. (b) Keep seed project "Ready for Annotation" (the FEAT-024 staging pilot) out of R2a–R3a pilots until the statistics seam fixture passes. © Serve the three screening families live for multi-profile R3b pilots; add profile-grain families at F5. (d) Exempt preview pilots from PS1. | Yes to all four. | PS2/PS3 block on admin backfill; pilots collide with the statistics pilot | F2 (a, b, d), F5 © | MS-04, MS-08, MS-10, MS Q1–Q3, Q6 |
| D3-11 | Agreement statistics storage. | Their own rebuildable derived store with a watermark, outside FEAT-024 (whose README excludes kappa), with an absolute performance budget. | R5c design open | F4 | MS-20, MS Q4 |
| D3-12 | Deletion versus history. The reversible-deletion design (ADR-014, product decisions approved 12 August) physically deletes a search's studies after 24 hours; amendment J and QD1 keep identification history. | Withdrawing a search hides its studies but keeps Citations and canonical evidence; deleting a whole project keeps ADR-014's physical removal with a tombstone; file and PDF cleanup is unchanged. | X-DEL conflict unresolved | F3 (first part), F-P (identification part) | PH-02, PH Q1 |
| D3-13 | Allocation and batches. (a) Refuse proportional allocation on canonical stages until AL1. (b) Record #3939's decision that sufficiently excluded studies stay in a batch's denominator and count as finished. © Let an RA5 requested reviewer bypass allocation buckets and the enforced target, once, audited. (d) Ship "Who is offered what" as pool-level counts until the out-of-request authority resolver (#3251) exists. (e) A study "enters screening" at its first release to anyone; record shared openings and personal grants separately. (f) Merge #3939 in slices: completion and progression decisions and durable openings first; selection integration after a performance gate. | Yes to all six. | Allocation and batches stay legacy-only | F3, F-A | AP-02..06, AP-12, AP Q1–Q6 |
| D3-14 | Staging seed data. | An additive, idempotent "seed-if-absent" job on preview and staging that never alters or wipes existing data. | New seeds reach preview only | F1a (S0), or before S0-4 is enabled if earlier | V2-09, review AC-11, AC Q5 |
| D3-15 | Browsers and touch. | Firefox and WebKit smoke journeys and touch-capable drag in acceptance for reviewer and reconciler screens; CDK pointer drag, never native HTML5 drag. | Chromium only | F1c, or before S0-7's browser projects count as evidence if earlier | PH-13, review AC-19, AC Q6 |
| D3-16 | Production claims route. Q-25's answer assumed tracking was not needed for claims; in fact claims, capacity guards and typed admission exist only when active reviewer tracking is on, which is off in every deployed environment. Options: (a) reshape #3876 into a binding-scope setting and enable it per admitted pilot project (and for legacy projects that opt in, addressing #2446); (b) enable fleet-wide once FEAT-024's mode transition (M15) has an owner and load tests pass; © no production claims, with RA1 met only by the reconciliation task claim. | (a). | Capacity promises do nothing in production | F1a (contract part: the claim contract fields and route seam), F3 (production route), before any R2b/R3a production pilot | RT-02, RT-03, RT Q-RT1 |
| D3-17 | Capacity cap separate from the minimum target. | An optional per-stage or per-route cap, off by default; when on it defaults to the form target, never limits requested extra reviews (RA5) and never evicts existing work. | Target doubles as cap | F1a (C7) | RT-13, RT Q-RT3 |
| D3-18 | A form bound to stages with different tracking settings (extends Q-28). | The most restrictive bound stage sets the cap and idle timeout; the stage in use sets the in-progress limit, counting a shared session once; the form is tracked if any bound stage is. | Q-28 open | F3 | RT-12, RT Q-RT4, PH-05 |
| D3-19 | Places on dependent forms during screening. | Hold no place on a dependent form while the reviewer is still screening; claim it at Include; if refused, show "enough reviewers" for that step and keep the screening decision. | Claim timing open | F3 | RT Q-RT5 |
| D3-20 | Who may see who is reviewing a study now. | Reviewers see counts and their own place; names only for holders of the Monitor capability; never across reconciliation blinding. | Presence names every claim holder to every member | F1b (C10) | RT-14, RT Q-RT6 |
| D3-21 | Notification enablement. | Pilot projects first through per-project notification admission, platform-wide only after the pilot exit review; staging and preview overrides only with your approval per release, email kept in Mailpit; an operator delivery halt (pause, not cancel) before any production email; a G-NOTIF gate per environment and kind family. | Notifications stay off everywhere | Before any notification enablement | NS-04, NS Q-N1, Q-N8 |
| D3-22 | Email content. | Notification emails and digests may name the project; never study titles, aliases, answers or free text. | Titles only | Before production email | NS Q-N2 |
| D3-23 | Auto-resolve. When one person resolves a workflow item, others' related notices show "resolved" and leave the unread count, staying in history. | Yes. | Notices stay unread | F3 (R3c) | NS Q-N3 |
| D3-24 | Per-project email mute (the inbox still records). | Yes, before production email. | No mute | Before production email | NS Q-N4 |
| D3-25 | Reconciliation conversations as records. | Part of the project's audit record: kept while the project exists, exportable only behind an audit or export capability with aliases, never in candidate-answer exports or agreement statistics except as exposure markers. | Retention undefined | F4 | NS Q-N6 |
D4: needed before F4–F6 and the lanes (methodology and scope additions)¶
| ID | Question | Recommendation | Until answered | Needed by | Source |
|---|---|---|---|---|---|
| D4-01 | "Unsure" at title/abstract. | A per-profile option, on by default in the title/abstract template: Unsure routes like Include for availability, the collective rule is configurable, PRISMA counts it as not excluded, agreement reports it separately and collapsed. | Binary decisions only | F5 | SR-13, SR Q-1 |
| D4-02 | Discussion as a conflict-resolution route. | A per-profile route, off by default: after a conflict both candidates may see each other's decision and reasons (exposure recorded), either may correct via DP2, and agreement uses the initial decisions. | Extra vote or adjudication only | F5 | SR-23, SR Q-2 |
| D4-03 | Extract-and-verify. | A verification step on target-1 forms: a second reviewer confirms or edits the single extraction (exposure recorded) and the result is gold with Verified authority, labelled distinctly in exports and the methods summary. |
Not supported | F4 | SR-12, SR Q-3 |
| D4-04 | Calibration or training rounds. | A step kind whose records never vote, qualify or count for PRISMA, with live agreement feedback; promotion to live decisions only by an explicit admin action. Build in R3c, or after GA with the admission hook kept now. | Not supported | F3 | SR-11, SR Q-4, PH Q12 |
| D4-05 | Protocol, registration and search documentation. | Search documentation fields (date, platform, strategy, limits, round) in P1; a protocol and registration record with an append-only amendments log in R3d or earlier; publishing a profile version that changes eligibility requires an amendment entry. | Protocol URL only | F-P (search fields), F5 (amendment rule) | SR-04, SR-24, SR Q-5 |
| D4-06 | Risk-of-bias and reporting-quality templates. | SYRCLE (per-outcome items bound to Outcome Assessment), the CAMARADES checklist and ARRIVE Essential 10 as curated templates owned by CAMARADES methodologists. | Ad-hoc questions | F1a (R1a catalogue part), F-O | SR-05, SR Q-6 |
| D4-07 | Full-text retrieval. | Explicit actions (Sought, Retrieved, Not retrieved with a reason) by admins and stage-granted reviewers; a PDF attachment only suggests Retrieved; retrieval is fullTextStatus, never a lifecycle state (amendment M). |
Boxes 6, 7, 12 and 13 can't be truthful | F-P | SR-02, SR-15, SR Q-7 |
| D4-08 | Several reports describing one study. | A "link reports to one study" action for boxes 10 and 16 (amendment O); linking never merges extraction. | Reports counted as studies | F-P | SR-07, SR Q-8 |
| D4-09 | Analysis-ready and RIS exports. | A lane X1: a comparison-level export shaped for meta-analysis tools (no effect-size computation inside SyRF), a machine-readable codebook, and RIS export of any study set. | Long and wide exports only | F6a | SR-08, SR-20, SR Q-9 |
| D4-10 | Graph digitisation. | Ship an "estimated from graph" provenance flag in O1 now; decide on a digitiser lane after pilots show how often graphs are the only source. | Graph regions link only | F-O | SR-06, SR Q-10 |
| D4-11 | Box 1 (previous review version). | Populate it from amendment K's reported counts, switching the diagram to the updated-review template; full updated-review support stays deferred. | Box 1 deferred | F6b | SR-14, V2-04, SR Q-11 |
| D4-12 | Agreement observation basis. | Default to initial independent observations; screening agreement per profile; pooled pairwise κ or Krippendorff's α for rotating raters, with percent agreement and prevalence always shown; confirmed by a statistician before κ ships. | Basis undefined | F1a (markers in C3), F4 | SR-01, SR Q-12 |
| D4-13 | Primary exclusion reason. | The first failing criterion in the profile's configured order, on by default, with a per-profile override allowing reviewer choice. | Reviewer choice | F5 | SR-10, SR Q-13 |
| D4-14 | Importing answers from other tools (FEAT-004). | A lane after R2a: imported answers carry their own provenance, are excluded from independence statistics, count toward the target only when mapped to a SyRF reviewer, and never become gold automatically. | Not in scope | After R2a | PH-10, PH Q6 |
| D4-15 | Routing studies by answer values. | A lane after R4a, expressed as a step-dependency rule on gold values; not required for GA. | Not in scope | After R4a | PH-05, PH Q8 |
| D4-16 | Early screening-profile adoption for existing projects. | Allow admin-initiated adoption of screening-only, unreconciled stages after R3b, reversible until the first canonical write. | Adoption waits for R6 | After R3b | PH-23, PH Q9 |
| D4-17 | Stale-answer acknowledgement (FEAT-001 D54/D55). | Replace with RE2's non-blocking warning and Complete anyway; drop per-project enforcement levels. | E34 open | F4 | PH-17, PH Q10 |
| D4-18 | Funder deliverables. | Map each NC3Rs and SSI RSMF deliverable to a release, confirm with the funders, and run an independent WCAG 2.1 AA audit at GA. | Unmapped | G0 (mapping), GA (audit) | PH-12, PH Q4 |
| D4-19 | Blinding and random serving as core behaviours. | Candidates are always blinded (the stage chooses only the alias scheme); unmasking only through the audited export disclosure contract; random serving is the default and explicit assignment an audited exception. | BL1 stage setting may disable blinding | F3 | PH-12, PH Q5 |
| D4-20 | Completed work of disabled members. | Keeps counting and stays in reconciliation; an audited admin action can exclude a reviewer's contributions from a form. | "Eligible" undefined | F4 | PH-22, PH Q7 |
| D4-21 | What ASySD parity means (Q-37). | Parity with pinned R package outputs (identical auto-confirmed groups; probable-duplicate pair-set F1 ≥ 0.99) and the published sensitivity and specificity on labelled datasets; 80,000 citations in under an hour on Bramble. | AC-P2-01 not computable (retired; AC-P2-01r) | F-P | SR-22, review AC-21, AC Q9 |
Answered by the evidence (no question needed): Q-N9 (RA5 in Q-10): #3965's completed-sessions-only eligibility already excludes requested reviewers until they return their review. Q-D2 (two reconciliation tasks for one study and form): RE4 already decides one task per study and form; the plan's "compatibility class" task key was a contradiction and is corrected.
2. Engineering contracts to settle (no owner question needed)¶
These need written contracts with evidence before the gate shown. Owners are lanes from the integrated plan; contract IDs are from contracts. E76–E81 (delivery tooling, from the delivery operating model), E82–E87 (from the UX strategy) and E94–E99 (acceptance tooling, from the acceptance criteria §10) name an owner or lane and no contract.
| ID | Contract | Lane / contract | Gate |
|---|---|---|---|
| E1 | Treatment vocabulary and derived effects: per-question change classes (added, removed, changedCompatible, changedIncompatible, mapped) with their treatments and defaults; per-category application and the counting choice for sessions left pinned; autoUpdate only within a class for valid answers; one session effective-state evaluator (per-answer state enum, requirement standing, qualification) used by admission, readiness, AF2 and exports; Upgrade and late-Save pin rules; FV4 as an appended policy generation (versioning model §7.4, §7.5, §8) |
L2, L1, L7 / C4, C5 | F1a design, F2 |
| E2 | Context identity for ancestors, repeated entities and branches; legacy duplicate detection; stale-base writes; atomic Fix transition | L1 / C2, C5 | F1a |
| E3 | Version-usage families over canonical sources (E72), protected publish boundary, definition-rewrite fence, digest compatibility, the scoped-rebuild-at-pinned-snapshot service API, fence-read identity recorded in the manifest, draft-only counts from the draft collection, authoritative affected identities; profile-version usage. The reviewer pause is the engine's scoped fence | L7 / C8 | F2 |
| E4 | Query concurrency, snapshot replacement, task claims/locking, query queues, notice delivery | L6 / C9, C15 | R4b |
| E5 | Cross-stage propagation mechanics (policy in Q-26/Q-27), partial combined-step reservations | L4 / C6, C7 | F3 |
| E6 | Map grants to existing authority; assignment start, release and reacquire races; additional-review idempotency; blinded aliases; the reconciliation task editor claim (CAS plus lease) in every environment, working with tracking off (X-RECLAIM) | L8, L6 / C10, C9 | F4 |
| E7 | Match scoring, missing features, ties, groups of more than two, reference remapping on re-pair | L6 / C9 | F4 |
| E8 | Snapshot identifiers, current-snapshot pointer CAS, historical reconstruction, as-of manifests | L6, L11 / C9, C11 | F4/F6a |
| E9 | Statistical method and denominators (depends on Q-04/Q-16) | L11 / C11 | R5c |
| E10 | Evidence-based legacy session mapping: a membership rule ("membership-uncertain" where an answer's stage differs from the session's), an admin choice when merging sessions into a shared form, adoption-time validation ("legacy-completed, unvalidated" with an admin count/don't-count decision), definitionVersionAtAuthoring = unknown on adopted pins; dry-run invariants; recovery |
L15 | R6 |
| E11 | Reason collection Off while reason reconciliation is On | L3 / C4 | F5/R4p |
| E12 | Legacy-compatible and event-count schema fields, roles, types, validation, export | L10 / C14 | F-O |
| E13 | Stage lifecycle actions mapped to existing authority; readiness events; idempotency | L4 / C6 | R3c |
| E14 | Validate the entity-type catalogue, legacy aliases and feature-required system types at F-C/F-O; the identities themselves (EntityTypeId for the seven legacy categories, cohort, outcome measure, experiment) are minted at F1a |
L9, L10 / C13, C14 | F1a (identities), F-C/F-O (catalogue) |
| E15 | Physical storage of every logical boundary in domain-model §4 (revisions, sessions, drafts and snapshots), recorded as the F1a storage ADR from VB's blueprint: revisions never embedded in sessions, a full pin map per session version in its own document, revisions in their own collection, only the canonical summary in Study. It shows the largest transaction stays within MongoDB's size and duration limits at the three fixture tiers, decides the canonical summary versus legacy-shaped stub sessions on M0 evidence (E48), lists each new pmStudy index with its operator build route, and fixes explicit collection names | L1 / C1, C18 | F1a |
| E16 | Compatibility floor: capture (never ignore-only) on every extended embedded type one release ahead; R0's reader floor (getter and claim-pipeline merges, IReviewMembershipFacts, predicate fragments); the writer floor (ServiceVersionFloor); ownership markers and the composite guard (E49); the per-project enrolment service; the minimum rollback image per service and its rehearsal |
L0 / C16 | F1a, R0 |
| E17 | Review-workflow notification events through C15 v2 (E73): kind registration, capture mode per operation, deterministic occurrence identity, write-time recipient expansion, read-time shaping through the disclosure hook | L14 / C15 | Per feature |
| E18 | Claim/reservation identity: claim contract v2 (detailed in E68), typed claims per (study, kind, scope, reviewer) keyed by form or profile identity, with route-stage provenance; capacity claims on Study, editor claims on their aggregates; versioned hub methods, additive DTOs, new command contracts; one reservation migration shared with the eligibility programme's S4-B; signed by the presence, eligibility and FEAT-024 owners | L7 / C7 | F1a (contract), F3 (routing) |
| E19 | Shared-form compatibility for progressive batches (evidence seam, pool-entry-based membership and durable opening, E67) and proportional allocation (refusal until AL1, then the AL1 adapter, E65), with their owners | L7 / C7 | F3 (batches), F-A (allocation) |
| E20 | Study canonical summary (built under E48): Study.CanonicalSummary keyed by form and profile with per-reviewer membership markers (session state, standing, claim activities, admitting regime), per-profile outcomes (screeningOutcomes[]), a per-bound-stage projection, readiness flags and its definition-version vector. Written with a Study version bump in every study-scoped canonical transaction through FEAT-024's seam (isolated read, version-guarded non-upsert replace, opaque fields preserved) and by projection-rewrite operations; Core policies read it only through IReviewMembershipFacts (E64), whose conformance suite is the eligibility truth table; R0's floor makes legacy getters, predicates and the claim pipeline read it; an inventory of every reader of embedded tallies and membership, tracking's writers and readers included, with its cutover; retired at R7 |
L1, L7 / C1, C7 | F1a |
| E21 | Drafts: one draft record per session, stored outside Study, with lease holder (stable client tab ID, RT-10), etag, per-holder write sequence and heartbeat; bounded conflict copies; take-over; Save/Complete consume the draft atomically; stale autosave rejection; deterministic SessionId created on first autosave; patches against the base with the E28 cap; no TTL, audited discard feeding LC1; indexed by base form version; invisible to reconcilers and exports; cross-form stale-base conflict; whether a draft holds a place is D2-07 (versioning model §7.6) | L1, L5 / C5 | F1a |
| E22 | Publication: O(1) phase 1 (form fence, drain, preview-digest re-check, CAS of the form head, policy record generation 1, operation record); phase 2 as an ADR-020-style operation rewriting projections by predicate until clean, writing Q-34 mapping revisions and capturing notices once per recipient by recorded fan-out; manifest built after commit from authoritative records with draft_only from drafts; one active publication per form; FV4 generation CAS; scoped admission and readiness pause (versioning model §8; consistency model §4, §7) |
L2, L7 / C4, C8 | F2 |
| E23 | One applicability specification (conditional parents, filtered options, branch context, ADR-011) with shared fixtures run by the .NET validator and AF2; typed errors | L1, L5 / C4, C5 | F1a |
| E24 | System questions stored as data in a global pmSystemQuestionVersion store keyed (guid, SystemQuestionVersion, seq), seeded idempotently from code, identity (guid, SystemQuestionVersion) so v0 and v1 structural variants are distinct, CAMARADES content versions with the ordinary compatibility declaration, adoption only through a project form publication (D2-06); never rebuilt per read on canonical paths; no code-revision key (versioning model §3.7) |
L2 / C4 | F1a |
| E25 | Ordering and as-of (built under E51): per-aggregate versions, with per-study order given by the Study version, plus an HLC stamp on every canonical record from the first write; no per-project commit sequence in any interactive transaction (the M0 evidence is recorded in the C11 ADR with ADR-019's numbers); as-of(T) only for T older than the watermark (transaction lifetime + sweep + twice the skew bound + margin); dataset classes in manifests | L1, L11 / C1, C11, C18 | F1a (stamps), F6a (as-of) |
| E26 | History capture from first enrolment (built under E54): legacy screening writes (R2a), pool-entry events (R3a), retrieval and lifecycle events (P1), captured inside the aggregate in the same document write and moved to pmLegacyWriteLedger by a leased worker; overflow is a coverage gap; every writer named and tested |
L1, L12 / C3, C12 | F1a |
| E27 | Identifiers: deterministic SHA-256 IDs over a versioned canonical key (as CSUUID) for aggregates with natural keys (FormSession, AnnotationHead from the key hash, ReconciliationTask, StudyGold, default population, CanonicalOwnership) with the natural-key unique index as the real guard; client-proposed, server-validated IDs for revisions and entity instances (well-formed, unused, same project); legacy IDs kept through LegacyIdAlias (versioning model §12.3) |
L1 / C1, C2 | F1a |
| E28 | Commit limits expressed as maximum pins per session version, maximum changed revisions per commit and maximum BSON bytes per commit (not question count), refused before any write; draft size cap tied to the same limits; three fixture tiers (typical, p99, max) from D1-08; an initial form size ceiling until benchmarks prove larger forms safe (D2-16) | L1 / C1, C5 | F1a |
| E29 | LC1 stage completion in two steps: the Completing fence, a drain, readiness verified from authoritative records in a pinned snapshot, then Completed or back to Active. Readiness-relevant commands are refused while Completing and become change requests once Completed; approval re-validates at commit and commits the underlying change with the status; claims are withdrawn through the outbox; notices inline, with flags-off queues | L4 / C6, C18 | F3 (design), R3c |
| E30 | Post-commit effects (C19, E47): every effect classified as derived on read, durable intent or best-effort hint, with the event catalogue in domain-model §6.2. Outdated flags are derived on read. Durable intents use the claim-revocation outbox pattern or an operation record. Notifications are captured inline (bounded) or by recorded fan-out, with deterministic SourceIds. The existing mechanisms are reconciled: FEAT-024's pending entries and its notification outbox (#3107), the claim-revocation outbox, Identity's recovery-email outbox, the notification stack's inbox rows and change-stream hint, and in-process IDomainEvent (loss-tolerant only, after #3973) |
L1, L14 / C1, C15, C19 | F1a |
| E31 | Restore (E55): no selective per-project restore of canonical data (D2-13); a whole-database point-in-time restore into an isolated database plus manifest-driven forward recovery; a history-discontinuity record; the integrity checker across collections (pointers, pins, drafts, command-bearing records, the canonical summary, markers and the registry) passes before writes reopen; scheduled state is reconciled from Mongo | L15 / C16, C18 | F1a (policy), R2a (rehearsal) |
| E32 | Erasure and retention: canonical records store only opaque investigator GUIDs (with a schema check); account deletion anonymises the Investigator record, and answers stay attributed to it (D2-14); as-of exports are identical except erased identities, recorded in manifests; retention rules for drafts (audited discard only, no TTL), conflict copies, exposure events, presence and connection records (pmReviewerPresence, kept indefinitely today, and pmReviewSessionConnection), inbox items and the notification stack's stores (preferences, the delivery ledger, digests that hold notification IDs, conversation and issue posts as free text under the annotation erasure rule, and checked PDF bytes); retention never orphans ledger or digest references |
L1, L8, notification programme, presence owner / C1, C10, C11, C15 | F1a |
| E33 | Reviewed-record merge and split as an alias (D2-12): Study.mergedInto and a StudyAlias entry on the primary; per-reviewer resolution (AliasResolutionPolicy) counted once; no immutable record re-keyed; ADR-020-style operations writing both Study documents and refusing busy studies; a split removes the alias; FEAT-024 staged fences and a rebuild |
L1, L12 / C1, C2, C18 | F1a (design), P2 |
| E34 | Cross-form conditional consistency: FEAT-001's D51 (materialised crossStageConsistency via domain events) is replaced by the derived per-answer states NotApplicable and NeedsUpdatingValue bounded to one reviewer's sessions on one study; D53's immediate client-side warning stays as AF2 behaviour using the shared E23 evaluator; D54 and D55 (reconciler acknowledgement and enforcement levels) are replaced by RE2's non-blocking warning per Batch D D4-17 |
L2, L1, L5 / C4, C2, C5 | F1a |
| E35 | Replaced by E50, the canonical command ledger (C18; consistency model §5). FEAT-024 receipts stay statistics-protocol receipts, with the CommandId as their OperationId |
— | — |
| E36 | Compatibility and class evaluator: diff classifier producing the system suggestion, class derivation and classSeq stamping, immutability guard (refuse a flip once any revision pins the version; re-validate active publication policies before that), designer pending-edit record with lease and etag (versioning model §3.5, §3.9) |
L2 / C4 | F1a |
| E37 | Option identity and payload contract: optionId minting, typed payload (value XOR response mode, metadata, option IDs), display value and label resolution, v0/v1 legacy option and condition mapping with a manifest of unmatched values (versioning model §3.3, §11) |
L2, L1 / C1, C4 | F1a (payload); R6 (mapping) |
| E38 | Composition and renderability validator: applicability graph validated against pinned parent versions by option ID; AF2 structural guards run server-side at publication with shared fixtures; typed refusals naming the question (versioning model §4.2, §4.3) | L2, L5 / C4 | F1a |
| E39 | System question store: idempotent seeding, (guid, SystemQuestionVersion) identity, the CAMARADES publication command, no per-read rebuild on canonical paths (versioning model §3.7; replaces the mechanics part of E24) |
L2 / C4 | F1a |
| E40 | Session effective-state evaluator: per-answer state enum (eight states), requirement standing, qualification, policy composition across publications and FV4 generations; one implementation for admission, readiness, AF2 and exports; projections carry the input-version vector (versioning model §7.4, §7.5, §8.4) | L1, L7 / C5 | F1a design; F2 |
| E41 | Head key value object, versioned canonical serialisation and hash, partial unique indexes per kind, Conflicted head state, AuthoredUnder typed union, LegacyIdAlias (versioning model §6.1, §6.2, §6.6, §11) |
L1, L15 / C2 | F1a; R6 for the alias |
| E42 | Entity instance commands (create, rename, withdraw, duplicate), population membership as an instance attribute, outcome cells keyed by instance, per-session presentation record outside versions (versioning model §6.5) | L1 / C2, C13 | F1a |
| E43 | Append-only persistence: AppendOnlyRecord base, IAppendOnlyRepository<T>, explicit collection-name map with its test, content digests on every immutable record, the architecture test forbidding updates on immutable collections, no TTL on canonical collections, string enums, the read-only integrity checker for invariants I1 to I6 (versioning model §12.2 to §12.4) |
L1 / C1 | F1a; checker in R2a |
| E44 | AF2 VersionedAnnotationFormDataSource (pinned versions by ID), the Needs-updating presenter contract (fromVersion, toVersion, treatment, reason, guidance, prior value rendered with fromVersion's labels), immutable-definition cache with Cache-Control: immutable, typed no-fallback error for canonical routes (versioning model §4.3, §12.5) |
L5 / C17 | F1c (seam), R2a |
| E45 | Reconciliation under versioning: task input-set versions, per-question held derivation, gold re-reconciliation derivation, second-task revision of shared gold (D2-09), query target as the reconciled revision ID (versioning model §9) | L6 / C9 | F4 |
| E46 | Canonical transaction admission ADR (C18): options and deadlines, re-execution, free retries with MaintenanceSequence, the typed outcome catalogue, the cache rule, non-upsert saves, collection and index creation (pmStudy through the operator route), DuplicateKey handling, CanonicalCommitCommandBudgetTests |
L1, L0 / C18 | F1a |
| E47 | Durable effects and events ADR (C19): the three classes, a generic durable-intent store on the claim-revocation outbox pattern, the operation record family, change streams as hints, IDomainEvent only after #3973; with the notification programme, the inline and recorded fan-out capture modes, scheduler markers and deterministic notification IDs |
L1, L14 / C19, C15 | F1a |
| E48 | Study.CanonicalSummary and R0's behavioural floor: shape, write rules, getter and claim-pipeline merges, IReviewMembershipFacts, shared predicate fragments; the M0 evidence that decides against legacy-shaped stub sessions; floor steps before R2b and R3a |
L1, L7 (with the presence and FEAT-024 owners) / C1, C7, C16 | F1a (design), R0 (floor) |
| E49 | Ownership markers and the composite write guard: the CanonicalScopes vocabulary, aggregate-method checks, the ambient writer scope, the architecture-test extension, project-wide pre-checks, registry reconciliation, the greenfield stamping sweep, and the writer and reader inventory (every pmStudy UpdateMany, tracking writers, notification-stack writers) |
L0, L15 / C16 | F1a (design), R0 (build) |
| E50 | Canonical command ledger: CommandId and digest rules, the command-bearing record per command class, outcome-unknown resolution, FEAT-024 OperationId correlation, inbox SourceId derivation |
L1 / C1, C18 | F1a |
| E51 | Ordering and as-of: the HLC stamp format and stamp collector, the per-study clock, maximum-drift refusal, the watermark rule, dataset classes, versioned alias records, erasure in manifests | L1, L11 / C11, C18 | F1a (stamps), F6a (as-of) |
| E52 | Fences and operations: ScopeFence, the drain from measured server settings (with an optional host in-flight beacon), lease and operator release; pmCanonicalOperation with lease, generation, stable cursor, chunks, final pass, one-active index and limits; bulk-lock interplay |
L1 (primitive); L2, L4, L12, L15 (uses) / C19 | F1a (primitive); F2, F3, P2, R6 |
| E53 | Derived records: the DefinitionVersionVector on every derived record, fail-closed gates, predicate sweeps, the race fixtures (decision against profile publication, threshold change against decision, binding change against Save) |
L1, L3, L4 / C1, C6, C18 | F1a (shape); F3, F5 |
| E54 | Legacy history capture: the bounded Study log, the PM worker into pmLegacyWriteLedger, overflow as coverage, one test per named writer, pool-entry writer enumeration |
L1, L12 / C3, C12 | F1a (design), R2a |
| E55 | Integrity checker and restore policy: checker contents and schedule, the post-restore gate, the discontinuity record, scheduled-state reconciliation, the isolated-database rehearsal | L15, L1 / C16 | F1a (design); R2a (checker; rehearsal before the first production pilot) |
| E56 | Write-path evidence: a canonical-commit arm in FEAT-024's benchmark harness (1, 2, 5 and 10 reviewers; same and different study; eligibility off and on; capture on; fold, claims and a sweep running), three fixture tiers, a failure-injection harness (crash points, unknown commit, failover) | L1, L17 / C18 | M0 (evidence for F1a); every release gate |
| E57 | Claim consistency: the claim contract v2 rules (capacity claims on Study, editor claims on their aggregates, uniqueness, last-page release, draft-aware release, lease expiry and a backstop sweep), the canonical claim pipeline, the M15 dependency for X-CLAIMS, budget test updates | L7 (with the presence and FEAT-024 owners), L6 (editor claims) / C7, C9, C18 | F1a (contract); F4 (editor claim); X-CLAIMS |
| E58 | Context map as the first contract ADR: one namespace per bounded context under Core/Model/<Context>/ and Core/Services/<Context>/, internal by default with Core/Contracts/<Context>/ as the public surface, and architecture fitness tests (a source-scanning test extending StudyWriteLockArchitectureTests for ownership filters and append-only writes; a reflection-based dependency test for the allowed context dependencies and the hosting rule) |
L0 / all | F1a |
| E59 | Command catalogue and hosting rule: every canonical command has one handler in ProjectManagement.Application; API and PM are hosts; PM receives notification-capture capability (flags or the admission-record pattern) as an R0 item; platform-architecture.md §2 corrected in the F1a docs PR |
L0, L1, L14 / C18, C19 | F1a (catalogue), R0 (PM capture) |
| E60 | Policy catalogue (domain-model §7.1): each policy a pure Core domain service with a fixture suite; IReviewMembershipFacts extracted now with the embedded-Study provider, so the eligibility truth table becomes the conformance suite |
L1, L4, L7 / C5, C6, C7 | F1a |
| E61 | Shared-kernel value objects frozen with equality rules (domain-model §7.2): AnswerContextKey and hash, typed EntityPath, DefinitionOwner versus owningParent, Provenance, ExposureState, AuthorityValue, DefinitionVersionVector, ClaimKey, EntityTypeId; a joint conformance suite per shared type |
L1, L2, L9 / C1, C2, C13 | F1a |
| E62 | One Stage aggregate for canonical projects (settings versions, lifecycle, change requests, status history; Active derived); the settings placement table for every existing per-stage setting; settings versions reference the allocation regime and batch plan by ID with embedded Stage.WorkloadShares and ProgressiveBatches legacy-only; two-step completion |
L4, L7 / C6, C7 | F3 |
| E63 | Reconciliation task identity (study × form) with versions recorded as state; ReconciliationSession as a task entity with a task-keyed draft; the editor claim; PublicationImpactPolicy for drift; the compatibility-class decision removed from F4 |
L6 / C9 | F4 (shape at F1a) |
| E64 | Membership-facts seam: IReviewMembershipFacts, behind which the pool predicates, StageWorkloadShareEligibility, AllocationClaimSlot, ActivityReservationAdmission, the own-place checks and the capacity pipelines read per-reviewer facts (own session state per form, claim kinds held, own decision per profile, other reviewers holding a place); embedded-Study provider first with truth-table parity and no behaviour change; CanonicalSummary provider at R0/R2a |
Eligibility owner, L1, L7 / C6, C7 | F1a (seam), R0 |
| E65 | Allocation on canonical stages: refusal guard until AL1 (no shares on canonical stages; R0 refuses a stage with an enabled regime); AL1 adapter with regime schema v2 (form binding, target source), a floor one release ahead, the compatibility check, read APIs and editor on the membership projection, the D8 slot rule on form-keyed claims, and refusal of a form publication that changes the target under an active regime | L7, allocation owner / C7 | R0 (guard); F-A, AL1 (adapter) |
| E66 | Requested-review admission and capacity cap: the requestedReview claim written by the AdditionalReviewRequest command (single use, expiring, audited), honoured by pool filters, allocation, typed admission and capacity guards for that reviewer only; target unchanged; counted outside allocation progress; the optional capacity cap (D3-17); the set of sessions that hold a place |
L6, L7 / C7, C9 | F4 (design), R4a (build) |
| E67 | Progressive batches for canonical stages: IStudyObligationEvidence with legacy and canonical providers; pool-entry-based membership with late cohorts; compare-and-swap opening and personal grant writing pool-entry events and durable intents; read-only status; performance gate (Next p95 at 100,000 studies and 2,500 batches; AC-R3a-26, AC-R3c-17) |
L7, batch owner, L12 / C7, C12 | F3 (contract), X-BATCH |
| E68 | Claim contract v2 and one reservation-key migration: typed claims unique per (study, kind, scope, reviewer), released when the last page ends; capacity claims on Study, editor claims on their aggregates; keyed by form identity; versioned hub methods, additive DTOs, new commands with old handlers kept at least the suspension grace plus the idle timeout; presence index create–read-both–drop; S4-B targets the final key with stage provenance; consumer inventory (pool predicates, D8 slot rule, typed admission, Study.GetSlotReservation, FEAT-024 reservation fold kinds, presence index, hub join, idle/suspension/liveness consumers and their scheduled commands, claim-revocation intents) |
L7 with presence, eligibility and FEAT-024 owners / C7 | F1a (contract), R2b (ship), X-ELIG (migration) |
| E69 | Production claims route (X-CLAIMS): per D3-16, the binding-scope tracking setting enabled per admitted pilot, or the M15 transition with an admin route rehearsed on staging; API and PM switched together statically; orphan-claim backstop (absolute lease expiry, or a bounded sweep behind its own flag); load and failover on Bramble; E2E in both tracking modes | Presence owner, FEAT-024 owner, L17 / C7, C16 | Before R2b/R3a production claims |
| E70 | Tracking adapters: at R0, the tally getter and claim pipeline merge canonical counts and markers, and tracking's writers and readers join the inventory with tests; at R2a, own-place detection through E64, claim release on the first explicit Save/Complete in the canonical transaction, presence FormSessionId, dirty = draft-changes flag, draft-aware release (D2-07), and the draft lease on a stable tab ID that works with tracking off (D2-08) |
Presence owner with L0, L1, L5 / C5, C7, C16 | R0, R2a |
| E71 | Target-aware annotation classification: replace the fixed two at StudyStats.cs:353-355, AnnotationThresholds.MinimumNumberSessions (a digest input) and StudyRepository.GetSessionFilter (#3979) with the effective target; catalogue bump and digest migration with a reconciliation plan (forced rebuild of allowlisted projects; retained checkpoints keep their identity); ProjectStageConfigurationChange.AffectedFamilies extended |
FEAT-024 owner; architecture-review owner (#3979) / C7 | Before R2b pilots on allowlisted projects; before R3a (X-STATS-c) |
| E72 | FEAT-024 canonical-sources amendment: technical-plan amendment and ADR for families over canonical collections in the same pinned snapshot (FormVersionUsage, QuestionVersionAnswers at F2; profile families at F5 per D3-10c); scope kinds and key components with tolerant maps; a new-family onboarding contract with an N-1 test; #3506; usage over explicit versions with drafts counted authoritatively; the scoped-rebuild-at-pinned-snapshot service API; fence-read identity in the manifest; protocol 5 batched after gate (b) |
FEAT-024 owner with L2, L7 / C8 | F2, F5 |
| E73 | C15 v2 in the notification stack: kind registry through DI; Source sub-document; one capture service (bulk upsert with $setOnInsert); deterministic SourceId and row ID; inline and recorded fan-out (NotificationFanOut and a leased expander); server label, context, availability and state; disclosure hook per channel; unknown kinds leave the ledger row ready, one deploy ahead; registry test |
Notification programme; L14 (specification), L8 (hook) / C15, C19 | ADR in W0; frozen at F1b; landed after the base merges and before the first review-workflow kind |
| E74 | Notification enablement controls (G-NOTIF evidence): tolerant preferences and a kind→category map before #3942 merges; declared email→inbox dependency; operator delivery halt; inbox reads independent of capture admission; per-project notification admission (an interim registry, then an R0 enrolment scope); idle workers when nothing is enabled or pending; route guards with opt-out reachable; flood controls; retention per E32 | Notification programme with L0 / C15, C16 | Before any enablement outside e2e and Mailpit; flood controls before R2c |
| E75 | Flag delivery and evaluation consistency: reviewEligibilityPolicy and proportionalStudyAllocation delivered to PM (one block replacing #3939's partial one) with a cross-host agreement check before either is enabled; PM-hosted branches inventoried; one flag evaluation per request passed into admission, with a test; no gate or evidence relies on runtime overrides until #3975 is fixed; R0 admission is the domain enrolment that P7 per-project targeting keys to |
L0 with eligibility, allocation and flag-overhaul owners / C6, C16 | Before X-ELIG enablement; F1a (P7 alignment) |
| E76 | The STATUS ledger format, slice-issue labels, claim records and a gh-based weekly digest script (decision ages, start delays, chain RAG, WIP, criteria coverage from the traceability file) |
Programme lead | S0 (S0-5) |
| E77 | Flags registered once: the five stream kill switches and R0's admission flag in env-mapping.yaml with regenerated outputs, catalogue counts and consumer-manifest entries; later slices only flip defaults at enablement |
Stream A with each stream | S0 (S0-6) |
| E78 | Release-candidate and acceptance-record tooling: candidate commit and image SHAs captured from the staging GitOps values; the acceptance-record template; the rerun rule when later merges touch the release's paths; the staging promotion-pause procedure agreed with the cluster-gitops owner and tested once | Programme lead with L17 | Before R0's ship gate |
| E79 | Fresh-context verifier checklists: one per programme rules file (§2.5) and the ship-gate verifier (criterion IDs to evidence; invariants 1 to 12 to INV checks), with a fixed PASS, FAIL or N/A report format and an exceptions list for the dossier | Programme lead | F1a (first use) |
| E80 | CI and host instrumentation: start-delay capture for the digest; path-filtered conformance test projects with a five-minute target and their routing-contract changes; a capped, niced local-build wrapper for Juniper sessions; the Bramble booking table in STATUS | Programme lead with stream A | S0, then F1a |
| E81 | Conflict-avoidance checks: a non-generated, non-test changed-line counter reported in the PR body; an ADR number uniqueness and block check in docs validation; a shell-file lease check against STATUS | Programme lead with L17 | S0 |
| E82 | Save-status state machine, bounded local copy (IndexedDB) with sequence replay, conflict and take-over screens, typed-outcome recovery copy; lease by stable client tab ID with REST heartbeat; works with tracking off | L5 with L1 | F1c (copy), R2a |
| E83 | Copy deck mechanism: deck document, typed message constants per feature, shared core-terms file, banned-string and import guard spec, user-guide glossary parity script in docs CI | L16 | F1c |
| E84 | Pattern inventory as shared components, spec gallery route behind a flag, handoff template, "What changed" panel with per-user dismissal, anchored tour component, contextual help on every new screen | L16 with L5 | F1c, R2a (panel), R3a (tour) |
| E85 | Accessibility and browser harness: @axe-core/playwright with baselines and journey-state checks, screenshot matrix at the UI-6 widths, forced-colours and reduced-motion runs, Firefox and WebKit smoke projects, native-drag guard spec, CDK drag for the question tree before R1a, browser floor (.browserslistrc, target, polyfills) |
L17 | W0 and S0; R1a precondition |
| E86 | My work: read-time counts endpoint over the four queues and admission-based work, project-level surface, global badge, cross-project tab, admin LC1 banner, deep links by task identity and alias; workflow version badge and panel, admission action, containment banner, legacy explainer | L16 with L6, L4, L0 | R0 (panel), R3c, R4a |
| E87 | Reviewer efficiency: keyboard screening path reconciled with DP3 and DP5, live completeness and jump on every host, input-latency budget under autosave, privacy-safe timing events (subject to D3-08) and the baseline measurement protocol | L5 with L3 and L17 | R2a (count, latency), R3a, R3b (keys) |
| E88 | Observation-basis markers and the agreement store: initial-independent-submission marker derived at commit; collective-exposure record at correction with route kinds; "questioned in reconciliation" exposure looked up by session (#3965); imported authority and independence declaration; calibration purpose; computation from canonical revisions into the rebuildable agreement store (D3-11) under the method contract (E9) | L1, L11 / C3, C11 | F1a (markers), R5c (store) |
| E89 | Full-text retrieval event model: StudyLifecycleEvent kinds for Sought, Retrieved (how) and Not retrieved (reason list, author-contact date) with actor; automatic Pending → Sought on title/abstract collective Include; the "suggest Retrieved" hook from the PDF programmes; full-text admission on fullTextStatus; box derivations per amendment M |
L12, L4 / C12, C6 | F-P (P1), F3 (admission) |
| E90 | Extraction provenance and validators: extractionMethod and dataSource roles; unit vocabulary with SI-aware labels and the same-measure validator; dispersion catalogue; domain validators; nSource rule; graph-estimated default on region link; extraction QC view queries |
L10 / C14 | F-O (O1) |
| E91 | PRISMA arithmetic and authoritative snapshots: identity checker I1–I13 with remainders and administrator explanations; entry-phase and per-box combination for external records; computation from authoritative records at a hybrid-logical-clock watermark; template-variant switch for box 1; withdrawn-search exclusion | L12 / C12 | F6b (R5b); K and L parts at F-P |
| E92 | Link records: CitationPublicationLink (amendment N; whether P1 also creates Publications for exact DOI/PMID matches) and StudyLink groups (amendment O), with alias and group resolution in counting and exports |
L12, L1 / C12, C11 | F-P (N), P2 (O) |
| E93 | Analysis-ready exports and transparency outputs: comparison pairing rules; codebook schema; RIS tag mapping; Record synthesis inclusion capability and attribute; near-miss preset; methods-summary schema; domain × study RoB matrix |
L11, L12 / C11, C10 | X1, R5b |
| E94 | Traceability file and check: the YAML format in acceptance criteria §9.1; generated views (decision to criteria, criterion to tests, per-release acceptance record, pending view, tag check); a docs-CI job that fails on an uncovered ledger or §1.11 decision, a row without Source or Status, or a test tag naming an unknown or retired ID | L17 | S0 |
| E95 | Mixed-version harness: starts the current image, writes canonical fixture data to a persistent database, starts the recorded minimum image against it, runs legacy flows and an unrelated-field replace round trip, and reports both image SHAs | L17, L0 / C16 | S0 skeleton; F1a |
| E96 | Deterministic barrier harness on MongoDbReplicaSetTestFixture: named interleaving points (after read, before commit, after commit and before dispatch), fixed seeded schedules, and an assertion that the forced interleaving happened |
L17 / C18 | S0; F1a |
| E97 | Seed-if-absent job: additive and idempotent, keyed by fixed GUIDs, run on preview and staging separately from ownership reconciliation; canonical seed projects created through canonical commands once R0 and R2a exist (D3-14) | L17, L0 | S0; each release |
| E98 | Benchmark arms: today's session submit and screening save, then the canonical-commit arm, on RV-DS-01 to 05 at the D1-08 tiers, with 20 warm-up and 200 recorded iterations, a same-host main baseline and a report naming commit, dataset and host |
L17 / C18 | S0 baseline; F1a |
| E99 | Cross-language fixture corpus: versioned JSON under src/libs/testing/SyRF.Testing.Common/ with a schema check, loaders for xUnit theories and Vitest describe.each, a differential runner across the .NET and AF2 evaluators, and per-release assertion files |
L17 / C1, C2, C5, C12 | S0 |
3. UI validations before building¶
Each validation also checks accessibility (keyboard paths, screen-reader meaning, contrast in both themes), the copy contract and the Material 3 UI standard (acceptance criteria §3).
| ID | What must be shown in a prototype or usability session | Release |
|---|---|---|
| U1 | The reconciliation workspace handles 3, 4 and more candidates (answers, matching, outcome series) without two-slot assumptions; stable aliases and blinding (RD17, SF4/RE3); agreement icons and prefill when answers are partial or blank (UA1, RE5, no majority); a candidate selector never hides a disagreeing candidate; a keyboard alternative to drag-pairing; performance with N candidates on large forms | R4a |
| U2 | A per-step Skip/handoff action versus study-level Skip; scope is obvious; Skip never records Exclude or completion (RC6) | R3a |
| U3 | Population context placement in the reviewer form; compact cohort selection that doesn't push the form down (RC8) | C1 |
| U4 | Clear autofill marks, unseen-control warning with routes, Complete anyway; affected-session Fix navigation, including route choice and the wait for LC1 approval (RE2, SF5) | R2d/R4a |
| U5 | Publication pause/retry and route-change messages preserve work and never reveal votes (OD5) | R2c/R3a |
| U6 | The publication flow as four steps (Review changes → Impact summary → Choices with defaults → Confirm) with a "what reviewers will see" preview and a dry-run summary; completed, saved-incomplete and draft-only impact, existing choices, missing-reason warnings and conflicting per-question decisions within one session (FV1–FV4, VU1–VU3); comprehension per category (AC-UX-02) | R2c |
| U7 | Step strip plus one form area versus card-per-step (Q-12) | R3a |
| U8 | Members & groups with project and stage permission subsections; delegation envelope; why a person can or cannot act | R1b (visibility), R1c (dialog and groups), R1d (delegation) |
| U9 | Ordinary question editor versus profile-owned eligibility editor: one editor, unmistakable ownership | R2a/R3b |
| U10 | Completed-stage change approval dialog (LC1) for automatic and manual modes | R3c |
| U11 | Replacement guided setup: resumable draft, preview and publish with impact gates, manual route kept | R3d |
| U12 | Stage designer: dependency edges separate from display order, effective-policy preview, cycle rejection, EW1, VS1, BL1, lifecycle mode, versioned-settings publish preview | R3a |
| U13 | Reviewer states: kept changes vs Save progress vs Complete vs current version, how to tell which version counts, and the slot states (held, released, enough reviewers, offline; U38 details) | R2a |
| U14 | Forms page, form composition and minimal stage binding | R2a |
| U15 | History panel | R2a |
| U16 | VS1 accepted-answer display with exposure capture and the VS2 disclosure interstitial ("You are about to view accepted answers for this study. Your contribution will be recorded as informed.") | R4a |
| U17 | Profile eligibility questions and derived-decision reasoning on the screening renderer (DP3) | R3b |
| U18 | Deliberate correction of one's own Exclude from history (DP2) | R3b |
| U19 | Question-template browse and import | R1a |
| U20 | Assignment, expiry, release/reacquire and Request an additional review | R4a |
| U21 | Raising a query, the query queue and per-raiser outcomes | R4b |
| U22 | As-of export selector, manifest and coverage labels | R5a |
| U23 | PRISMA views, reconciling #2621's prisma-workflows prototype with FEAT-011 and C12 | R5b |
| U24 | Outcome-measure and custom-schema authoring | O1 |
| U25 | Review-workflow items in the inbox: action labels, deep links that respect task identity (RE4) and aliases (BL1), "Related item unavailable" (joint with the notification programme) | Per release |
| U26 | Export disclosure: who may unmask identities, and candidate vs gold separation | R2a |
| U27 | Coexistence: navigation and editor behaviour for classic and versioned projects, checked with a tester who holds both kinds of project; the workflow version badge | R2a, GA |
| U28 | Pilot rollback: what reviewers and admins see when a pilot becomes read-only | R2a |
| U29 | Agreement view: its own capability-gated place in the navigation, the independent/informed split, missing-state reporting and compatible-version flags | R5c |
| U30 | My work: from the project index, reach an assignment in an unopened project in one step; as an admin, see a pending change request in the badge and banner without opening the project; the four queue filters; empty states; all with every notification flag off (NS-07, UX-08; pending D3-07) | R3c, R4a |
| U31 | Save-status indicator and recovery: Saving, Kept, Retrying, Offline kept on this device, Failed; take over editing from a second tab; recover a stale base; "keeps both" copies in history (UX-04, UX-17, RT-10; pending D2-08) | R2a |
| U32 | Workflow version badge and panel, the admit or remove action, the legacy explainer and the read-only containment banner (UX-11, UX-18, U28) | R0, R2a |
| U33 | Keyboard screening path: 20 studies by keyboard on a desktop and 20 on a 390 px phone with the keyboard hidden; the plain-profile, DP5 reasons and DP3 derived-decision variants; at most two actions per decision beyond answering eligibility questions (UX-02, PH-35; pending D3-05) | R3a, R3b |
| U34 | Live completeness ("N required missing · Jump to next") and Unanswered only on a 200-question form; input latency under autosave (AC-UX-04) | R2a, R3a |
| U35 | The "What changed" panel (read, dismiss per user), the anchored tour (pause, resume, replay) and contextual help links (UX-09) | R2a (panel), R3a (tour) |
| U36 | The reconciler journey end to end (pool → task → screening part → matching → form → Complete → next) at 1440 px and 925 px and in the narrow layout; the next-task rule; release and reacquire (UX-14) | R4a |
| U37 | The redesigned notification inbox and preferences (UI-1 to UI-11), mark all read, project and kind filters, context line, hide unavailable, "resolved" state, grouped digest (NS-10, NS-13; pending D3-01, D3-23) | before R2c |
| U38 | Slot and presence states: held, idle warning, released with and without the capacity cap, an Include refused for a dependent step, offline; presence counts without names (RT-22, RT-14; pending D2-07, D3-17, D3-19, D3-20) | R2b, R3a |
| U39 | The interim readiness-based setup checklist in the navigation footer at R2a, timed to a screenable stage (UX-19) | R2a |
| U40 | Long-running operations in the job language: publication phase 2, ASySD matching, as-of export generation, O2 dry-run, adoption wave; where each appears (Processing or a release-owned surface) and its pause copy (UX-16; pending D2-10) | R2c, P2, R5a, O2 |
| U41 | The duplicate review queue and the merge or split wizard with alias presentation (V2-25; pending D2-12) | P2 |
| U42 | Terminology card sort and "which version counts" vignettes for the copy deck terms (UX-05; pending D3-03) | F1c |
| U43 | Pattern gallery review: every shared pattern's states, keyboard model, narrow behaviour and copy keys, accepted per pattern before its first consumer builds (UX-07; pending D3-02) | F1c, then per pattern |
| U44 | Screening with bibliographic details hidden per profile (SR-25, PROPOSAL, default off); the exposure provenance records it |
R3b |
| U45 | The legacy chrome and shared pages after the Material 3 restyle, walked by a tester who holds both kinds of project; no behaviour change (D3-06) | GA |
4. Provisional assumptions used by the plan¶
If an assumption turns out wrong, the "cost" column names what changes.
| ID | Assumption | Basis | Cost if wrong |
|---|---|---|---|
| A-01 | A form version is the immutable, ordered selection of question versions (with ancestors), plus form-owned requirements and target. The QM v2 "question set version" maps to it. | SF1/SF2, FV1, QM-08/09 | Contract C4 changes; R2a scope shifts |
| A-02 | The existing AF2 reviewer form is extended for drafts, Save/Complete versions, needs-updating and provenance; it is not rebuilt. Screening-only steps need an AF2 admission change or a dedicated renderer (F5). | AF2 is on main; COMPARISON lane U | A reviewer-UI rebuild would add a large lane before R2a |
| A-03 | New capability names in this package are placeholders until Q-03 and the endpoint audit | Permission matrix | Naming only |
| A-04 | Admission is per project: new projects and admitted pilots first; no legacy project is adopted automatically | Screening research §5/§7; MIG1 | Adoption order changes |
| A-05 | Physical storage is decided by ADR at F1a (E15); the plan presumes no collection layout | Research separates domain from storage | Contract C1 detail |
| A-06 | Cross-stage collective policy (hybrid of Q-15a): unvoted reviewers may proceed once a study is collectively Included; a personal Exclude blocks that reviewer | Access-policy proposal; within-stage rule | Admission rule in C6 |
| A-07 | Review-workflow notifications use the existing notification stack (#3932–#3947, plus #3965) once its owners merge it, through the C15 v2 capture contract, with no parallel notification machinery. Confirmed obligations don't depend on that merge: feature-owned queues are the source of truth and the fallback (my concerns and outcomes for QY6/QY8; changes awaiting approval with an admin alert for LC1; assigned reconciliation work for RA2–RA4; requested reviews for RA5), surfaced without notifications by a badge, a "My work" view and an admin banner. Notifications add delivery only after G-NOTIF, per environment and kind family, with per-project notification admission and an operator delivery halt. Email is never a release dependency. | Chris, 3 October; ledger QY6, QY8, LC1, RA2–RA5; review NS | R3c/R4a/R4b scope; notification enablement timing |
| A-08 | The publication gate reads the version-usage families (PS1) at a fence. A Stale scope is answered by FEAT-024's pinned authoritative value in the same snapshot, or rebuilt through FEAT-024's "scoped rebuild at a pinned snapshot" service API, with the read's identity recorded in the frozen manifest (PS2's "actively update the specific relevant statistics there and then"; D3-10a). The reviewer pause is the engine's scoped write fence. Production publication from the materialised families needs FEAT-024's production chain (X-STATS-b1–b7); per Chris's Q-31 answer, named pilot projects use authoritative counting under the same boundary if that chain isn't complete when R2c is otherwise ready, so that path is designed as the first pilot path. | PS1–PS3; Q-31; review MS | R2c production timing |
| A-09 | Proportional allocation stays off for every canonical stage, whether its form is bound to one stage or several, until lane release AL1 ships; R0 refuses to admit a stage whose allocation is enabled (D3-13a) | The regime reads stage.SessionCountTarget and requires ReviewMode.Annotation, neither valid on a canonical stage; current allocation is stage-keyed |
Pilot configuration limits until AL1 |
| A-10 | Lanes are scope responsibilities, not people. One accountable approver (Chris) and agent sessions deliver the plan through five streams: a lane owner is a stream brief plus a stream-lead session, and a programme-owner sign-off is a fresh-context agent checklist against that programme's rules file, with Chris ruling on the exceptions (delivery operating model §2) | DS-01: all 400 PRs since 8 September were authored through Chris's account; main recorded at least 412 PR merges on 24 of the 31 days to 3 October |
If human teams were staffed instead, stream leads become people and checklists become signatures; the ready queue, the WIP limits and the order are unchanged |
| A-11 | Until amendment B is approved, exports label citation totals as records, never reports | PRISMA amendment B | Reporting copy |
| A-12 | v10 matching weights (0.40/0.40/0.20, threshold 0.50) are configurable initial defaults validated by fixtures, not approved values | MG1 | Defaults only |
| A-13 | The notification PR stack and FEAT-024 continue under their current owners; this plan only consumes their contracts | OPS1, 3 October update | Coordination load |
| A-14 | During R2a and R2b, a published form requirement version never changes and no new version can be published until R2c; an unpublished requirement version can change freely, and operational settings change with audit at any time. Pilots that need to evolve a used form wait for R2c, or stop using it. | FV1 without R2c's publication path | Pilot friction until R2c |
| A-15 | Category guidance (today a project value with a per-stage override) is reviewer-facing presentation text, not evidence. It stays a stage-level presentation setting alongside form-level guidance and is not versioned with the form. | SF1 governs evidence, not instructions | Guidance moves into form versions; small C4/C6 change |
| A-16 | Interpretation for Q-24: legacy combined stages migrate to steps without a dependency edge, preserving today's D3b behaviour, and keep their D1/D2 Allow/Stop value as the step's extra-vote admission setting | Eligibility D1/D2, D3b, D7 | Migration mapping for combined stages |
| A-17 | Custom group management and the generalised permissions dialog (#3335 WP11) can't ship before the authorization programme's gates: X-AUTH-SCHEMA (G-D in #3335's handover plan: membership schema 1 in production) and X-AUTH-ENFORCE (the authority-transition plan's M6 staged cutover, its gate G-C), unless parity tests prove legacy and evaluator decisions identical; and WP11 follows WP9 | #3335 handover plan; authority-transition plan | R1c timing |
| A-18 | The advanced cross-stage option "own Include sufficient" relaxes the default: own Include or collective Included admits, while personal Exclude and collective Exclude still block (Q-15, part b) | DP7 describes a faster advanced option, not a stricter one | Admission rule in C6 |
| A-19 | Until R2d, no answerable question, including an answerable ancestor, may belong to two forms in one project. Entity-category label questions are answerable (each unit's label), so in practice two forms can't both use the same entity category; Study-level questions (an implicit root without a label) can be split across forms. A fixture with two forms under one entity category proves the refusal is clear. | Avoids SF5 obligations before flags exist | Pilots needing overlapping forms wait for R2d |
| A-20 | Outcome measures are reviewer-created per-study entities, as the owner clarification recorded in the classification research says ("Outcome measures themselves are still created by reviewers from the paper"); direction is a single measure-level answer, revisable and reconcilable, shared across cohorts in that paper (ODIR1). Project-level schemas are definitions; measures aren't. | ODIR1 ("in a paper/population"); classification research 24 and 27 September clarifications | C14 changes; ask Chris before O1 if the C14 ADR finds otherwise |
| A-21 | R2a binds each form version to exactly one stage; multi-stage binding arrives in R2b | Keeps R2a free of multi-stage tally, allocation and claim-sharing joins. R2a is not free of claim joins: it changes own-place detection through the membership-facts seam (canonical sessions live outside Study), releases the slot claim on the first explicit Save or Complete inside the canonical transaction, links presence to FormSessionId and redefines "dirty" as the draft-changes flag (E70); claims stay stage-keyed until R2b |
R2a scope grows |
| A-22 | Admission and canonical ownership are data owned by R0's admission service (the enrolment record) and ownership marker, not configuration allowlists. The same admission record carries per-project notification admission, the AF2, shell and eligibility admission slices and the binding-scope tracking pilot, and the flag overhaul's P7 targeting keys to it. FEAT-024's durable eligibility (#3524) stays a separate record with the same shape and audit | B-01 compatibility analysis; reviews DS-04, PH-14, NS-04, MS-24 | R0 design |
| A-23 | Before GA, a new production project joins the canonical path only when its creator opts in at creation; staging and preview pilots use seeded and tester-created projects | Q-07 answer (new and seeded projects); production prerequisites | R0's admission rule changes to admit all new production projects |
| A-24 | Chris accepts each release's new and materially changed screens on staging at the ship gate, with the tier-1 design-QA evidence; per-PR preview acceptance is needed only for new shared patterns and for the publication flow, the reconciliation workspace, the stage designer, Members & groups and guided setup (UI-8). "Materially changed" is defined in UX strategy §13.3. Until D3-02 is answered, per-PR preview acceptance applies to every new or materially changed screen | UI1; D3-02 recommendation; UX-13; review AC-25 | If Chris wants per-PR acceptance for every screen, merge throughput falls to his review capacity (about 40 previews) and stream C drops to one release in acceptance |
| A-25 | Question versions form one linear sequence per identity (seq 1..n); branches never exist; a copy from a template or another profile is a new identity at seq 1 |
FEAT-001's sequential VersionNumber; DP4 copies |
Class derivation and classSeq need DAG rules; the designer needs merge semantics |
| A-26 | A requirement version pins at most one version of each question identity; two forms may pin different versions of one question only across forms, never within one | FEAT-001 QSV: one AQVersionRef per question |
Composition, the pin map and the head key need a per-pin version dimension |
| A-27 | Production Atlas runs MongoDB 4.4 or later (ADR-019) with the default transactionLifetimeLimitSeconds of 60, an expired-transaction sweep of at most 60 s, majority write concern with journal, and the default minSnapshotHistoryWindowInSeconds |
MongoDB defaults; none was read from Atlas (UNVERIFIED) | Drain, watermark and retry values change; D2-10's pause of about 90 s needs L + S of at most about 80 s, or the in-flight beacon |
| A-28 | Clock skew between API and PM pods stays within a configured bound K (proposal 1 s, alarm at 250 ms) under GKE node time synchronisation | Usual GKE node NTP behaviour (UNVERIFIED) | The watermark lag grows; maximum-drift refusals stall writes behind a runaway clock |
| A-29 | Per-study write concurrency is low (at most about 10 concurrent writers on one study at peak), and Study documents of canonical projects stay far below 16 MB with the summary, claims and capture log bounded | FEAT-024's synthetic benchmark cells; canonical studies hold no embedded evidence; production rates UNVERIFIED | The same-study cell exhausts; the storage ADR splits the summary into per-form sub-documents or moves it beside Study |
| A-30 | Project's four embedded job records (search import, bulk study update, bulk PDF upload, risk of bias) stay embedded; their extraction into their own aggregates is not in scope before R7. The contention they cause with grant changes is measured at M0 (AC-M0-02 Project-contention line) rather than designed away now. | No programme owns their extraction; the ADR-020 and M5b operations already keep their heavy state outside Project (pmBulkStudyUpdate*, pmRobRun*) |
An extra platform slice before R1c if M0 shows grant changes exhausting retries against running jobs |
| A-31 | The review-eligibility programme stays paused through F3 | Session memory ("paused 25 September until the statistics work finishes"); not recorded in the repository; #3746 had activity on 1 October | If it resumes, X-ELIG slices return to it and R3a's absorbed scope (D3-09) shrinks; if it stays paused, R3a absorbs S6b (and S4-B, S4-C, S6a as needed) and grows |
| A-32 | No legacy untyped slot reservations exist in production, because claims are created only with tracking on, which no deployed environment has enabled | Review RT-23 (code reading); the count is unverified | S4-B must migrate them before eligibility is enabled; an authorised count-only check per environment settles it |
| A-33 | The notification stack owner accepts C15 v2, lands it after the base merges and before the first review-workflow kind, and restacks #3965 onto #3944 (D1-09) | Review NS §4; the owner has not yet been consulted | Each review-workflow kind edits shared notification files; conversations wait for #3947's isolation review |
| A-34 | The architecture-review programme lands #3985 (non-upsert saves; version bump on direct writes) and #3973 (awaited domain events) before F1a | #3961 Phase 0/1; D1-02 | F1a waits, or canonical repositories carry their own isolated-read, non-upsert and awaited-dispatch discipline enforced by an architecture test, and R0's floor also covers the version-less direct writers (StudyRepository.cs:1306-1319, 1620-1650) |
| A-35 | Chris can give the programme about four hours a week: a 30-minute weekly review; one decision sitting per gate (60 to 90 minutes, answering deviations only); one staging walkthrough per release (60 minutes for T1, 30 for T2, a summary read for T3); and about 12 supervised-PR summaries a week at about 5 minutes each | DS-01 and DS improvement 3; delivery operating model §16.2 | With less time, the acceptance limit drops to two releases programme-wide and decision sittings merge, so the calendar stretches; the order is unchanged |
| A-36 | Agent engineering throughput is not a binding constraint: main recorded at least 412 PR merges on 24 of the 31 days from 3 September to 3 October 2026 (mean 17 on a merge day, peak 53), all through Chris's account; the constraints are approver time, CI host capacity and Bramble's exclusive windows |
git log --first-parent --merges on main at de3e98c59; DS-01 |
If engineering binds, raise WIP limits once start delays and review latency stay within budget, and split stream C into reviewer workspace and admin UX; the order is unchanged |
| A-37 | FEAT-023's light cutover does not land before R2a's reviewer UI; new screens are built on Material 3 roles over the current components and verified on the Material 2 bridge plus the static checks (UI-3, UI-9, UI-10) | FEAT-023 README (Waves 0 to 4 open; Wave 5 unscheduled); D3-01 pending | If the cutover lands earlier, the screenshot matrix is re-run on the Material 3 path at cutover; no plan change |
| A-38 | The tester panel (D1-06) and at least two external SyRF users are available for the W0 baseline study and for monthly sessions | D1-06 (decided 3 October 2026; the names are still needed) and the D3-08 recommendation | AC-UX-03 and AC-UX-04 are re-based on R2a's first summative session, which doubles as the baseline; those thresholds stay PROPOSAL until then |
| A-39 | For canonical projects the initial-independent-submission marker can be derived at commit from the commit order and the visibility events already planned (availability messages, VS1 exposure, conversations); for adopted legacy projects it is unknown, and every legacy decision is labelled "basis unknown" in agreement statistics | C3 three-state exposure; EX2 (no fabricated history) | R5c shows no IRR for adopted projects, only percent agreement labelled "basis unknown"; or an explicit marker must be written by every submit path |
| A-40 | The funder mapping in methodology-coverage.md §15 reflects docs/funding/ as of 14 March 2026; neither the NC3Rs contract position nor the SSI RSMF outcome has been confirmed since (D4-18) |
docs/funding/nc3rs.md, docs/funding/ssi-rsmf.md |
Release order could change (for example R4a earlier for NC3Rs); the WCAG audit timing could move |