Skip to content

Rollout plan: from today to legacy-writer retirement

Status on 5 October 2026. This is a temporary planning document. Feature implementation is on hold (Chris, 5 October 2026). G0 is not approved. No brief is approved, no implementation is authorised, no work has started, no gate has passed and nothing is enabled in production. The owner decisions this plan places are planning approval only. Brief approval and implementation authorisation are separate decisions taken per gate (D1-04), and both remain on hold. This plan authorises nothing: no code, migration, production activation, notification delivery, PR closure, message to the design session or new prototype.

What this plan does. It places every change from Chris's owner session of 4 and 5 October 2026 on the existing release structure of the integrated plan and the delivery operating model. For each change it says where it lands, which class it belongs to (baseline, optional, beta, later lane, exploration, deferred) and why. It then sets out the dependency graph, the gates and what each needs, the pilots and conversion waves with their entry and exit evidence, the risks and re-plan triggers, and the actions that never happen without separate approval. The implementation tracker holds one row per brief, specialist input, unapproved policy, gate and implementation slice group named here.

Sources. The owner-session consolidation wins over every older text. The nine specifications carry the detail, each with its own §10 rollout, §11 acceptance evidence and §12 brief items; the specification overview indexes them. The owner-session integration holds the count reconciliation, the superseded wording and the coverage matrix. The archived bundle is indexed in owner-session-2026-10-05/README.md. The plain-English summary for Chris is the product-owner guide. The design-session handoff is specifications/design-prototype-handoff.md.

1. How to read this plan

Phases are an order of dependencies, not a calendar. This plan has no dates. A phase starts when its entry conditions hold; phases overlap; the windows in integrated plan §7 remain an illustration only.

Labels. A decision ID, such as (Q-15) or (OS-A12), marks an owner decision recorded as planning approval. PROPOSAL marks this plan's placement or a specification's recommendation for a brief. Release boundaries, new lane IDs, tiers and flag names introduced here are PROPOSALs until the gate that freezes them. Anything without a decision ID is a proposal.

Numbers. No numeric threshold is approved. Every number in the specifications (limits, budgets, latencies, defaults, parity figures, sample shares) is proposed and waits for its brief and its measurement. This plan quotes none of them as a target.

Two status ladders. Decisions use: Decided, Decided-amended, Replaced, Removed, Deferred (beyond MVP), Brief item, Specialist input, Engineering contract (no owner question), Open owner decision. Work uses: Planning approved, Brief drafted, Brief approved, Implementation authorised, In progress, Merged dark, Gate passed, Production enabled. These are separate steps. One never implies the next. Today every work item is at most Brief drafted.

Classes of scope.

Class Meaning
Baseline (MVP) Part of the canonical engine that GA needs, or inside a lane's MVP boundary
Optional setting Ships with the baseline, off by default, chosen per stage, form or profile
Optional increment Ships after its core release's pilot exit, behind its own flag
Delivery-scope lane Planned and in scope, scheduled after its dependencies, not a GA prerequisite
Opt-in beta Off by default; an authorised project designer opts in; GA promotion is a separate decision
Exploration Feasibility only; any build needs an owner decision on the findings
Deferred (beyond MVP) No delivery commitment until its own brief is approved
Not approved Never built or assumed (T-POL-01 to T-POL-03)

Count scope. Before the session the package had 89 open owner decisions (Batch B 13, Batch C 15, Batch D 61). Of those 89, 63 are now resolved, replaced, removed or deferred, 25 are alignment, brief or validation entries, and 1 is still an open owner decision (D2-09, tracker row T-OI-01). The 74-entry session register sits inside the 89, with 52 entries resolved, replaced, removed or deferred and 22 brief entries. The amendments OS-A01 to OS-A30 are outside both counts. G0 items and the unapproved policies are outside the 89 as well.

Specification prefixes. RD review domain and versioning; DM duplicate merge; SP stage pools, steps and history; RS reconciliation and screening; BC baseline conversion; TI training and inference; RI reporting, imports and AI screening; UX UX, devices and work discovery; ACD access, communications and deletion. Acceptance evidence IDs (RD-AE01 and so on) are in each specification's §11.

2. What changes in the release structure

The existing releases stay (S0, M0, R0, R1a to R1d, R2a to R2d, R3a to R3d, R4a, R4p, R4b, R4c, R5a, R5c, R5b, the lanes, GA, R6 and R7). The condensed packages ask that prior rollout scope is kept unless Chris changes it, and that optional items need not enter the first engine release. The changes below follow from owner decisions; each is a PROPOSAL for its freeze gate.

Change Integrated plan before This plan Why
Standard reviewer target An operational setting outside the requirement version (D2-05 round 2) Inside FormVersion from F1a and the first canonical form in R2a; target-only publications in R2c OS-A12. No settings-only path ever exists for canonical forms, so nothing needs migrating later
Publication evidence Publication writes no evidence F2 and R2c generate attributable session versions D2-01 decided-amended
Cross-stage routing DP6 and DP7 route policies in R3a Stage study filter and steps in R3a; no stage-entry gate Q-15 replaced
Pool records StudyPoolLedger with StudyEnteredPool in R3a HistoryEvent envelope (C20) at F1a, stage-pool and eligibility types at F3, writes from R3a; WorkFirstReleased replaces StudyEnteredPool OS-A07, OS-A10, OS-A11; the envelope must exist before the first canonical writer that records history
Screening ties Extra votes; adjudication in R4p Step kinds (review, system adjudication, training) frozen at F3; tie policy and bound in R3b profile versions; adjudication step and tasks in R4p OS-A13; the step model must know the adjudication step before profiles can route to it
Target-one forms No task and no gold SingleAnnotator or one-candidate human reconciliation in R4a Q-29, D4-03, OS-A28
Duplicate merge One P2 lane with an alias model P2a (consolidation of unreviewed duplicates), P2b (reviewed duplicates), P2c (accepted-result conflicts); C21 at F-P D2-12 replaced; OS-A29. Reviewed duplicates need shared sessions, profiles and history events; result conflicts need R4a and R4p
Training A step kind in R3c, or after GA with a hook only Lane TR1 in delivery scope; step kind slot at F3; not a GA prerequisite D4-04 decided-amended; OS-A18; legacy SyRF has no training, so new canonical projects lose nothing before TR1
Inference C2 tail with no activation rule C2 as a project-designer opt-in beta OS-A19
External and AI-model screening Out of scope Lane XS1 after GA; the profile-version slot reserved at F5 OS-A20; D4-14 decided-amended; the register placed imports after the first review-engine release
Annotation-answer imports A lane awaiting a Batch D decision Lane XA1 after GA D4-14 decided-amended
R6 Reviewed per-project adoption chosen by Chris; projects may stay legacy indefinitely Staging trials per scope, production pilots, then universal baseline conversion waves (R6) OS-A15
R7 Retirement of adapters with separate approval Legacy-writer retirement as its own verified milestone (G-RETIRE) Consolidation §5
Redesign after conversion None Lane RW1 (in-engine redesign wizard) after GA R4 owner direction (OS-A15)
PWA None Exploration PWA1, non-MVP; a feasibility report only OS-A22
Answer-based step branching Not planned Deferred lane BR1, no commitment D4-15 deferred
Lane freezes F-P, F-C, F-O, F-A Adds F-TR (training), F-XS (C22), F-XA (annotation imports) Each new lane fixes its contract before build, as the other lanes do
G-ADOPT Per adoption wave Per conversion pilot and per universal wave BC phase 2 gives each pilot its own approval
Collective Include in a stage Strict mode only if Q-01 approves A decided stage setting, shipped in R3c after pilot validation Q-01 decided; SP-AMB-11
Reviewer study pool browsing None R3c opt-in slice, off by default OS-A27; D4-19
Whole-project deletion ADR-014 physical removal with a tombstone Reversible deletion through the amended deletion-lifecycle programme (X-DEL), before R6 D3-12; OS-A25

Tiers for new or split releases (PROPOSAL). P2a T1 and P2b T1 (first writers of Study state and carried evidence); P2c T2; TR1 T2, with the automatic-admission increment in the supervised review tier because it changes membership; XS1 T1 (a new authority over screening outcomes); XA1 T2; RW1 T2; C2 stays T3. R6 waves and R7 stay T1 under their programme gates.

3. Placement of every owner-session change

The tracker's decision index maps every one of the 89 decisions and every amendment to its rows. This table covers the amendments and the decisions whose placement changed.

3.1 Amendments OS-A01 to OS-A30

Amendment Lands in Class Why there Spec Tracker
OS-A01 Collaborative question-management drafts R2a (single-editor drafts with base checks and attributed changes); R2c (presence and live updates) Baseline (MVP) The draft model it needs is canonical from R2a; presence matters once several people prepare one publication (R-AMB-04) RD §3.7, §10; UX §3.8 T-RD-02, T-RD-05, T-UX-06
OS-A02 Reconciliation blinding and unpredictable candidate ordering R4a (forms); R4p (profiles) Baseline (MVP) Ships with the first reconciliation workspace; blinding is not optional behaviour RS §3.5, §5.6 T-RS-03
OS-A03 No cross-Study identity continuity in blinded reconciliation R4a; R4p Baseline (MVP) Same mechanism as OS-A02 RS §5.6 T-RS-03
OS-A04 Reconciled-answer hints, click-to-fill, step hide-only R4a; cross-form hints after R2d Baseline (MVP), own flag per environment Hints need accepted answers (R4a) RS §3.6, §5.7 T-RS-04
OS-A05 Finishing started work after pool departure R3a (default allow); the restriction setting once SP-AMB-01 is confirmed Baseline (MVP) Departure exists only once filters exist SP §3.9 T-SP-04
OS-A06 Results through a stage may change its own pool R3a Baseline (MVP) Filter reevaluation after commit starts with filters SP §4.2 T-SP-04, T-SP-05
OS-A07 Targeted pool-membership history R3a; envelope at F1a Baseline (MVP); history writes not flagged Switching history off would leave unexplainable gaps SP §3.5, §10.1 T-SP-01, T-SP-05
OS-A08 Admin explanation of review activity over time R3a (queries and API); timeline screen behind stageEligibilityTimeline until staging acceptance Baseline (MVP) Reads the history R3a starts writing SP §3.14; UX §3.7 T-SP-05, T-UX-06
OS-A09 Historical pool coverage; review through the stage first Recording in R3a; reporting in R5b after T-SI-05 Baseline (MVP) Recording cannot wait; box mapping needs specialist input SP §3.13; RI §3.3 T-SP-05, T-RI-05, T-SI-05
OS-A10 Explicit entry justification R3a Baseline (MVP) Part of every StagePoolEntered event SP §3.5.3 T-SP-05
OS-A11 Structured, queryable history events C20 envelope at F1a; stage-pool and eligibility types at F3; writes from R3a Baseline (MVP) Other specifications (DM, AC, BC, RI) add event types only through C20 SP §3.12, §3.13 T-SP-01, T-SP-03, T-SP-05
OS-A12 The standard reviewer target versions the form F1a shape; R2a first canonical form; R2c target-only publications and overrides; R4a additional-review requests Baseline (MVP) The first canonical form must already carry its target RD §3.5, §4.9 to §4.11 T-RD-01, T-RD-02, T-RD-05, T-RD-08
OS-A13 Tie adjudication and member or group adjudicators Step kind at F3; tie policy in R3b; adjudication step and tasks in R4p Baseline (MVP) Before R4p, Studies routed to adjudication stay visibly pending (RS §10) RS §5.11; SP §3.4 T-SP-03, T-RS-06, T-RS-07
OS-A14 R4 legacy activity mapping and adoption guidance Conversion wizard per scope, from the first staging trial Baseline for conversion The wizard grows with each completed scope BC §3.3, §10.3 T-BC-03, T-BC-04
OS-A15 Universal faithful baseline conversion, then optional redesign Staging trials, production pilots, R6 waves, R7; RW1 after GA Baseline for conversion; RW1 later lane One writable engine; nothing stays legacy for good BC §1, §10 T-BC-07 to T-BC-10
OS-A16 Bounded Unsure handling with adjudication fallback R3b (profile fields, extra-review path); R4p (adjudication fallback) Baseline (MVP) The transition table freezes with profile versions at F5 RS §5.10 T-RS-06, T-RS-07
OS-A17 Exclusion-reason template is guidance R3b (several reason questions); R5b (distinct Studies versus overlapping reasons) Baseline (MVP) Profiles carry reason questions; reports count them RS §5.13; RI §3.2 T-RS-06, T-RI-05
OS-A18 Training with references, scoring, assessment, retries, group admission Lane TR1 Delivery-scope lane Needs steps (R3a), profiles (R3b) and, for automatic admission, configurable groups (R1c) TI §3, §10 T-TI-01 to T-TI-05
OS-A19 Inference behaviour and project-designer opt-in beta Lane C2 Opt-in beta Ordinary annotation stays usable without opting in TI §3.7 to §3.9 T-TI-06 to T-TI-08
OS-A20 External and AI-model screening decisions Lane XS1 after GA; slot reserved at F5 Delivery-scope lane, per-project opt-in Needs profile versions, adjudication, identity matching and merge lineage; not forced into the first engine release (R-AMB-03) RI §3.10 to §3.14, §10 T-RI-09
OS-A21 Draft auto-saved versus Version checkpoint saved Copy deck at F1c; status machine in R2a Baseline (MVP) Ships with versioned sessions UX §3.2 T-UX-02, T-UX-03
OS-A22 PWA exploration beyond MVP PWA1 Exploration Never delays MVP work; no offline writes are authorised UX §3.11 T-UX-09
OS-A23 Compatible improvements on legacy screens Restyle by GA; compatible features as each ships Baseline (MVP) Unconverted projects keep their workflow semantics UX §3.4 T-UX-07
OS-A24 Admin-controlled contribution exclusion Form scope R2a; stage scope R3a; profile scope R3b; project scope after both; dependent-result flags R4a and R4p Baseline (MVP), flag contributionExclusion Each scope needs its provenance and readers ACD §3.2, §10 T-AC-02
OS-A25 Reversible project deletion and restoration X-DEL amended; canonical parts with R2a and R3a; before R6 Baseline (MVP) Deleted projects convert in their deleted state ACD §3.3, §10 T-AC-03
OS-A26 Informative, permission-aware emails Notification programme, before any production email Baseline before any production email Sent email cannot be recalled ACD §3.5 T-AC-05
OS-A27 Optional, dynamic, blinded reviewer study pool browsing R3c opt-in slice, flag reviewerPoolBrowsing Optional setting Reads the reviewer pool R3a defines SP §3.6 T-SP-07
OS-A28 One candidate plus human reconciliation instead of a verification engine R4a Baseline (MVP) Uses the ordinary reconciliation machinery RS §5.1 T-RS-01, T-RS-02
OS-A29 Consolidated, atomic, reversible duplicate merge C21 at F-P; P2a, P2b, P2c Baseline for the P2 lane Split by what each part needs (§2) DM §10 T-DM-01 to T-DM-04
OS-A30 Design-prototype handoff specification Drafted now; sent only on Chris's instruction Process deliverable An early design input to the W0 prototypes and F1c Handoff T-DH-00 to T-DH-04

3.2 Decisions whose placement changed

Decision Status Lands in Class Why
Q-35 Removed No legacy-authority backfill lane; the dry run counts legacy reconciliation records Not built The owner says no such records are expected; unexpected records stop that project's case (BC-AE11)
D2-16 Replaced Engine limits proven from R2a; the largest project is an acceptance case in R2a, phone annotation and conversion Baseline (MVP) No size-based exclusion (RD-AE23, BC-AE16)
D2-13 Brief item Rehearsal before R2a's ship gate (AC-R2a-29) and before any production conversion pilot Baseline for safety Production recovery execution keeps its own authorisation
D4-16 Decided-amended Production conversion pilots for complete scopes only, reversible until the first canonical write Baseline for conversion Lets pilots precede GA where a scope is complete (R-AMB-06)
Q-11 Decided Optional increment after R4a's pilot exit Optional increment Q-11 places it after the core workflow; explicit confirmation always
D4-02 Decided R4p, behind its own flag Optional increment Not forced into the first engine release
Q-01 Decided R3c stage setting after pilot validation Optional setting SP-AMB-11 recommendation
Q-02 Decided R3c Baseline (MVP) Lifecycle release
D4-15 Deferred (beyond MVP) BR1, no commitment Deferred Reconciled-answer clauses in stage filters stay in scope (R-AMB-02)
D4-08 Brief item Prepared multi-source links in P1; grouping distinct reports deferred Baseline plus deferred part Consolidation §1
D4-10 Decided Graph-estimated provenance in O1; digitisation decided after O1 pilots Baseline plus deferred part E3
D4-11 Decided Previous-review counts in R5b; full updated-review workflow deferred Baseline plus deferred part E1
D3-07 Decided Badge and banner in R3c; full My work in R4a; global landing page after GA Baseline plus deferred part U3
D2-15 Decided-amended Application-wide catalogue in R1a (questions, forms), R3b (profiles), C1, O1 Baseline (MVP) Curated templates wait for T-SI-03
D3-14, D3-15 Decided S0 (seeds S0-4; browsers and touch S0-7) Baseline (MVP) They answer G0-D2 and G0-D3; D3-08 answers G0-D11
D3-21, D3-22, D3-24 Brief item; Decided-amended; Decided Before any notification enablement (G-NOTIF) Baseline before production email Notifications are never a release dependency

4. Phases

Every phase below needs T-HOLD lifted and T-G0 approved before any of its slices start. A gate passed while the hold stands authorises nothing.

Phase 0. Planning and hold (now)

  • State. The hold is in force (T-HOLD). G0 is pending (T-G0). Its dossier carries the owner-session update, in review on PR #4045: G0-D2, G0-D3 and G0-D11 are answered, G0-X13 is met (#4013 merged on 4 October 2026), and exceptions G0-X14 to G0-X19 record what the session changes in the ask. G0-D1 is open, and the PR dispositions G0-D4 to G0-D10 are not authorised. D2-09 is open (T-OI-01). The nine briefs T-RD-00 to T-AC-00 are drafted as specifications. The design handoff T-DH-00 is drafted and not sent. No specialist input is requested yet (T-SI-01 to T-SI-05). The three policies T-POL-01 to T-POL-03 are not approved.
  • Allowed work. Planning documents in this package; Chris's decisions; brief review.
  • Exit. Chris lifts the hold and approves G0. They may come together.

Phase 1. G0 and foundations

  • Entry. T-HOLD lifted; T-G0 approved. Before the first claim, the stream briefs exist and cite the nine specifications (G0-X8, G0-X15), and M0-3's brief replaces the draft lease with the diff-based draft change log and one shared session (G0-X16).
  • What lands. S0 as planned, with S0-4's additive seeds (D3-14) and S0-7's Firefox, WebKit and touch harness (D3-15) now decided. M0 as planned; its writer and reader inventory feeds conversion (T-BC-01). M0 also executes the QM v2 harvest: M0-5 writes the harvest-and-avoid record from the harvest map into the M0 report (AC-M0-04, T-RD-10), and closing the stack waits for G0-D4 (T-RD-13). R1b, with the named-attribution display and joining-terms text (D2-14) once legal review of the wording is recorded. R1a's audit, browse and preview, structured for the application-wide catalogue (D2-15); curated templates wait for T-SI-03. The W0 prototypes, using the iterated prototype where Chris has sent the handoff (T-DH-01 to T-DH-03). ADR drafts for F1a (now including the C20 envelope and the owner-session naming registry), F1b and F1c, and the C15 v2 draft with the email content policy (OS-A26).
  • Exit. S0 merged dark; M0's go or no-go recorded.

Phase 2. Engine contracts and compatibility floor

  • Entry. M0 go. The F1a parts of T-RD-00, T-SP-00, T-BC-00, T-RS-00 and T-TI-00 approved; the F1b parts of T-AC-00, T-TI-00 and T-RI-00 approved; the F1c part of T-UX-00 approved.
  • What lands.
  • F1a freezes the form version with standardTarget and an inert ReconciliationPolicy (OS-A12), StudyVersion with Study state and currentVersionId, the draft change log, the form-keyed claim contract with form-owned timeout and in-progress limit (D2-07, D2-08, D3-18), the C20 envelope (OS-A11) and the conversion record shapes with the legacy-gap states.
  • F1b freezes the new capabilities (exclude contributions, the Deleted projects view and restore, the catalogue administrator role, training assessment and promotion, AI-model metadata view, external decision acceptance) and C15 v2 with the content policy and per-project mute.
  • F1c freezes the copy deck that keeps draft, checkpoint and completion distinct (OS-A21), the step selector with one form area (Q-12) and the outcome of the prototype iteration (T-DH-04).
  • R0 ships the floor. Its floor steps repeat before R2b, R3a, P1, P2 (adding the tombstone predicate for consolidated merges) and C1 or O1 if they add embedded fields.
  • Exit. R0's staging rehearsal (gates staging canonical writes); R0's production soak (gates the first production canonical write).

Phase 3. Versioned forms and shared sessions (F2; R2a to R2d)

  • R2a. The first canonical form carries its target in the form version (OS-A12). Diff-based drafts with the change log, Save, Complete and whole-form validation (consolidation §1). Single-editor design drafts with base checks and attributed changes (OS-A01, first part). The save-status machine and full annotation on phones, tablets and desktops, with the largest project as an acceptance case (D3-05, D2-16). Contribution exclusion at form scope behind its flag (OS-A24). Reversible deletion covers claims and drafts (OS-A25). The D2-13 recovery rehearsal is part of R2a's ship gate (AC-R2a-29). Consented pilot timing telemetry is available from R2a pilots (D3-08).
  • R2b. One session and one place per reviewer per Study and form across stages, tabs and devices; form-owned timeout and in-progress limit; capacity cap separate from the target (D2-07, D2-08, D3-17, D3-18). Production enforcement still needs X-CLAIMS (D3-16).
  • F2 and R2c. Publication may write attributable generated session versions (D2-01). The publisher declares compatibility at commit (D2-02, Q-34). Target-only publications, Study target overrides and their treatment at publication, collaborative drafts with presence and live updates (OS-A01), one publication per form (D2-11), and publication active-work protection with measured limits (D2-10). The shared active-work impact preview gets its first consumer here (consolidation §6). The statistics boundary rules apply (D3-10).
  • R2d. Fix, FV4 generations and guided correction; outdated-answer mode, warn by default (D4-17). D2-09 stays parameterised until Chris answers (T-OI-01).
  • Conversion. The annotation-only staging trial can run once R2a and R2b ship (R2d for overlapping question sets) (T-BC-03).
  • Pilots. See §8. Target-one forms piloted before R4a keep their single assessment, labelled "single annotator, acceptance not yet available" (RS §10).

Phase 4. Workflow, pools and history (F3, F5; R3a to R3d)

  • F3. C6 is rewritten around the stage study filter, steps, the three step kinds (review, system adjudication, training), exclusion-stop, the saved-work and continuation settings and the browsing setting (Q-15, OS-A13, OS-A18). C20 gains the stage-pool and eligibility event types. The D3-09, D3-13, D3-16, D3-18 and D3-19 treatments are settled.
  • R3a. Stage study filters with profile-outcome clauses and AND or OR groups; steps and dependencies; own-Include progression by default (Q-01); exclusion-stop; Stop or Allow extra screening (Q-24); saved work after exclusion (Q-28); finishing started work after departure, allowed by default (OS-A05); results that move their own Study out of the pool (OS-A06). Pool history with baselines, entries, departures and re-entry, targeted reevaluation and the filter sweep (OS-A07, OS-A10); ReviewStartEligibility and the completion basis; WorkFirstReleased for unbatched stages; the required event queries and the explanation API (OS-A08, OS-A11). The step selector with one form area (Q-12). Contribution exclusion at stage scope; reversible deletion covers pools.
  • F5 and R3b. Profile versions with Unsure (D4-01, OS-A16), the tie policy and its bound (OS-A13), discussion and rationale settings, profile-owned blinding, several reason questions (Q-22, D4-13, OS-A17), and the reserved ScreeningSourcePolicy slot for XS1. Profile publication with mismatch detection (Q-26). The protocol amendment rule for eligibility-changing publication (D4-05). Contribution exclusion at profile scope. Profiles that route ties to adjudication leave Studies visibly pending until R4p.
  • R3c. Automatic and static completion with reopening (Q-02). The collective-Include stage setting after pilot validation (Q-01). Reviewer study pool browsing as an opt-in slice (OS-A27, D4-19). Batched WorkFirstReleased with X-BATCH. The My work badge and admin banner (D3-07). Notice resolution for approvals (D3-23).
  • R3d. Guided setup using the application-wide catalogue.
  • Conversion. The screening and combined staging trial can run once R3a and R3b ship (T-BC-04).
  • Capacity. The shared-form capacity pilot runs on admitted projects only (D3-16, T-SP-09).

Phase 5. Reconciliation and adjudication (F4; R4a, R4p, R4b, R4c)

  • F4. C9 freezes AcceptedResultVersion with its authority values, target-one handling and the conversion-only NoAcceptance value (PROPOSAL), form-owned and profile-owned blinding, hints, optional assignment expiry, and the removal of legacy-authority handling (Q-35). D2-09 is answered or both options are carried (RD-AE25).
  • R4a. SingleAnnotator results or one-candidate human reconciliation (Q-29, D4-03, OS-A28); result versions when the target or policy changes; additional-review requests that raise the effective target (OS-A12); context-local blinding and unpredictable ordering (Q-30, OS-A02, OS-A03); hints with click-to-fill (OS-A04); the self-reconciliation override grant (Q-36); completeness by requiredness (Q-04). The full My work and cross-project tab (D3-07). Dependent results flagged after contribution exclusion. An admin-confirmed operation may create SingleAnnotator results for earlier target-one pilots (PROPOSAL; never a silent backfill).
  • R4a increments. Reconciled-answer clauses in stage filters, behind stageFilterAcceptedAnswerClauses, inside GA scope (R-AMB-02). Bulk acceptance after R4a's pilot exit, with explicit reconciler confirmation (Q-11).
  • R4p. Adjudication tasks with member or group assignment, the individual resolver recorded, optional rationale (Q-32), the system adjudication step in operation (OS-A13), profile blinding and flagged outcomes after corrections. The discussion route behind its own flag (D4-02).
  • R4b and R4c. As planned; R4c still needs O1.
  • Deferred. Answer-based branching between steps (D4-15) waits in BR1 with no commitment.

Phase 6. Lanes alongside the core

These lanes do not hold GA, as in the integrated plan. Each starts when its freeze and predecessors allow.

  • P1. References, source-document links and StudyVersion for new imports; search documentation versions (D4-05); retrieval actions (D4-07); search withdrawal and reinstatement (Q-33); the external-step ledger (Q-37); prepared multi-source links (D4-08).
  • P2a, P2b, P2c. Consolidation and unmerge of unreviewed duplicates with the current evidence view proof (P2a); reviewed duplicates with conflict tasks, delegation and carry-forward (P2b); accepted-result and adjudicated-outcome conflicts (P2c). P2a's ship gate needs T-SI-04.
  • C1 and C2. C1 as planned. C2 as an opt-in beta: candidate inference after C1, collective inference after R4a (OS-A19).
  • O1 and O2. O1 with graph-estimated provenance (D4-10); its event-count schema waits for T-SI-01. O2's build as planned; outcome data now converts inside each project's baseline (Q-05). O2 execution keeps its own approval.
  • AL1. As planned. Enabled allocation blocks a project's conversion until AL1 ships.
  • R5a, R5c, R5b. R5a adds the history watermark rule. R5c needs T-SI-02. R5b needs T-SI-05 and reports actual review through the stage first (OS-A09).
  • X1. As planned (D4-09).
  • R1c and R1d. As planned, behind the authorization programme's gates.
  • TR1. Training references, scoring and feedback; manual assessment and retries; manual then automatic group admission (after R1c and R1d); promotion to live evidence last (OS-A18).
  • X-DEL. Reversible project deletion and restoration in the deletion-lifecycle programme, done before R6 (OS-A25).
  • Notifications. The content policy, per-project mute and enablement controls (D3-21, D3-22, D3-24, OS-A26) precede any production email; G-NOTIF stays per environment and kind family.

Phase 7. GA milestone

  • Entry. AC-GA-01 to AC-GA-10 as amended, plus these owner-session items: reconciled-answer filter clauses shipped (if Chris confirms GA scope, R-AMB-02); the legacy-screen refresh with compatible features (AC-GA-09 with UX-AE10 and UX-AE11); phone, tablet and desktop annotation evidence (UX-AE03, UX-AE04, RD-AE23); a production pilot per release family (D1-07); the production chains in delivery operating model §6.
  • Not needed for GA. TR1, C2, XS1, XA1, RW1, X1, the P and R5 lanes, PWA1 and BR1.
  • Gate. G-GA, Chris.

Phase 8. Later lanes after GA

  • XS1. External and AI-model screening sources (OS-A20, D4-14): the versioned AI screening model configuration, profile source policies, idempotent runs, acceptance and machine-source classes in exports, PRISMA and agreement. Its first pilot uses a synthetic configuration and run only. No production import starts without its own approval.
  • XA1. Annotation-answer imports with provenance, no automatic accepted result and no independence credit (D4-14).
  • RW1. The in-engine redesign wizard for converted projects, through ordinary publication (OS-A15). Conversion never depends on it.
  • PWA1 outcome. Chris decides on the feasibility report (OS-A22). Any build needs its own brief.
  • C2 exit. GA promotion of the inference beta is a separate decision on the evidence in T-TI-08.
  • Deferred list. Answer-based step branching (D4-15); entity-scoped accepted-answer clauses; grouping distinct reports (D4-08); graph digitisation (D4-10); the full updated-review workflow (D4-11); the global landing page (D3-07); hints for repeatable entities; further catalogues; bounds reasoning in inference; retained claim and refusal history.

Phase 9. Universal baseline conversion

  • 9a. Staging trials (from Phase 3). One opt-in trial per completed scope on seeded and synthetic projects: annotation-only after R2a and R2b; screening and combined after R3a and R3b; extraction after O1 and O2; pools and history with R3a; exports with R5a (BC §10.1).
  • 9b. Production pilots. Owner opt-in projects, complete scopes only (D4-16), each through G-ADOPT for that pilot, after the scope's staging trial, the D2-13 rehearsal and R0's production soak. Pilots may precede GA where the scope is complete (R-AMB-06).
  • 9c. Universal waves (R6). Every remaining project, including completed, inactive and deleted ones (OS-A15). Entry needs GA, parity proven on pilots, every capability legacy projects use (AL1, O1 and O2, R2d, R5a, X-DEL, X-CLAIMS), and Chris's approval per wave. A project that cannot convert faithfully is quarantined with a recorded blocker, remedy and review milestone; it is never forced through with data loss.
  • Recovery boundary. Before a converted project's first canonical write, routing can return it to legacy with nothing lost. After it, recovery moves forward in the new engine only.

Phase 10. Legacy-writer retirement (R7)

  • Entry. Every project converted or remediated; an empty consumer inventory; access, export and restore checks passing; retention approved; Chris's approval through G-RETIRE (BC-AE29).
  • What happens. Legacy writers and adapters are removed. Legacy originals and manifests stay, byte-identical (BC-AE28). No physical erasure happens as part of retirement.

5. Dependency graph

Solid arrows are ship or build dependencies. Dashed arrows are inputs, joins or approvals. Every node also depends on T-HOLD and T-G0 through the "Implementation may start" node. The integrated plan's §6.3 graph keeps the full set of external joins; this graph adds the owner-session changes.

graph TD
    HOLD{{"T-HOLD implementation-hold lift"}} --> GO(("Implementation may start"))
    G0{{"T-G0 G0 approval"}} --> GO
    DH["T-DH-00 prototype handoff, sent by Chris"]
    F1c{"F1c IA, copy, AF2 seams"}
    DH -.->|design input| F1c
    GO --> S0["S0 scaffolding, seeds, browsers"]
    GO --> M0["M0 walking skeleton"]
    GO --> R1a["R1a question library and catalogue"]
    GO --> R1b["R1b members, groups, attribution"]
    GO -.->|exploration only| PWA1["PWA1 feasibility report"]
    S0 --> M0
    BRD["T-RD-00 brief"]
    BSP["T-SP-00 brief"]
    BBC["T-BC-00 brief"]
    BRS["T-RS-00 brief"]
    BTI["T-TI-00 brief"]
    BAC["T-AC-00 brief"]
    BUX["T-UX-00 brief"]
    BDM["T-DM-00 brief"]
    BRI["T-RI-00 brief"]
    F1a{"F1a target in form version, C20 envelope, claims v2"}
    F1b{"F1b capabilities, C15 v2 content policy"}
    M0 --> F1a
    BRD -.-> F1a
    BSP -.-> F1a
    BBC -.-> F1a
    BAC -.-> F1b
    BUX -.-> F1c
    F1a --> R0["R0 compatibility floor"]
    R0 --> R2a["R2a versioned forms, drafts, phone annotation"]
    F1b --> R2a
    F1c --> R2a
    R2a --> R2b["R2b shared session and place"]
    F2{"F2 generated versions, overrides"}
    BRD -.-> F2
    F2 --> R2c["R2c publication with impact"]
    R2a --> R2c
    R2c --> R2d["R2d Fix, outdated mode"]
    F3{"F3 filters, steps, step kinds"}
    BSP -.-> F3
    BTI -.-> F3
    BRS -.-> F3
    F3 --> R3a["R3a filters, steps, pool history"]
    R2a --> R3a
    F5{"F5 profiles, Unsure, tie policy"}
    BRS -.-> F5
    F5 --> R3b["R3b screening profiles"]
    R3a --> R3b
    R2c --> R3b
    R3a --> R3c["R3c lifecycle, collective Include, browsing"]
    R3b --> R3d["R3d guided setup"]
    R1a --> R3d
    F4{"F4 accepted results, blinding, hints"}
    OI01["T-OI-01 D2-09"]
    BRS -.-> F4
    OI01 -.-> F4
    F4 --> R4a["R4a single annotator, reconciliation"]
    R2b --> R4a
    R4a --> R4AC["R4a increment: accepted-answer filter clauses"]
    R3a --> R4AC
    R4a --> BULK["R4a increment: bulk acceptance"]
    R4a --> R4p["R4p adjudication step and tasks"]
    R3b --> R4p
    R4a --> R4b["R4b queries"]
    R4a --> R4c["R4c outcome reconciliation"]
    R1b --> R1c["R1c groups and dialog"]
    R1c --> R1d["R1d delegation"]
    FP{"F-P identification, C21"}
    BDM -.-> FP
    BRI -.-> FP
    FP --> P1["P1 identification provenance"]
    R0 --> P1
    XDEL[["X-DEL reversible deletion"]]
    XDEL -.-> P1
    P1 --> P2a["P2a consolidation of unreviewed duplicates"]
    SI04["T-SI-04 ASySD parity method"]
    SI04 -.->|ship gate| P2a
    P2a --> P2b["P2b reviewed duplicates"]
    R2b --> P2b
    R3b --> P2b
    P2b --> P2c["P2c accepted-result conflicts"]
    R4p --> P2c
    FC{"F-C classification"}
    BTI -.-> FC
    FC --> C1["C1 classification"]
    R2a --> C1
    C1 --> C2["C2 inference, opt-in beta"]
    R4a -.->|collective inference| C2
    SI01["T-SI-01 event-count specification"]
    FO{"F-O outcomes"}
    SI01 -.-> FO
    FO --> O1["O1 outcome schemas"]
    R2a --> O1
    O1 --> O2["O2 outcome migration build"]
    P1 --> O2
    O1 --> R4c
    FA{"F-A allocation"}
    FA --> AL1["AL1 shared-form allocation"]
    R2b --> AL1
    F6a{"F6a as-of"}
    F6a --> R5a["R5a as-of export"]
    R4a --> R5a
    SI02["T-SI-02 agreement methods"]
    R4a --> R5c["R5c agreement statistics"]
    SI02 -.-> R5c
    SI05["T-SI-05 PRISMA box mapping"]
    F6b{"F6b reporting"}
    SI05 -.-> F6b
    BRI -.-> F6b
    F6b --> R5b["R5b PRISMA reporting"]
    P2b --> R5b
    R4p --> R5b
    R4c --> X1["X1 analysis-ready exports"]
    R5a --> X1
    SI03["T-SI-03 template curation"]
    SI03 -.->|curated templates| R1a
    FTR{"F-TR training"}
    BTI -.-> FTR
    FTR --> TR1["TR1 training lane"]
    R3a --> TR1
    R3b --> TR1
    R1c -.->|automatic admission| TR1
    LEG["Legacy-screen refresh"]
    R2d --> GA(("GA canonical default"))
    R3c --> GA
    R3d --> GA
    R4p --> GA
    R4AC --> GA
    LEG --> GA
    FXS{"F-XS C22"}
    BRI -.-> FXS
    GA --> XS1["XS1 external and AI-model screening"]
    FXS --> XS1
    P2a --> XS1
    R4p --> XS1
    FXA{"F-XA"}
    GA --> XA1["XA1 annotation-answer imports"]
    FXA --> XA1
    GA --> RW1["RW1 redesign wizard"]
    R4a -.->|deferred, no commitment| BR1["BR1 answer-based branching"]
    R2b --> TRIAL["Conversion staging trials per scope"]
    R3b --> TRIAL
    D213["D2-13 recovery rehearsal"]
    R2a --> D213
    D213 --> PILOT["Conversion production pilots"]
    TRIAL --> PILOT
    GADP{{"G-ADOPT per pilot"}}
    GADP --> PILOT
    PILOT --> R6["R6 universal conversion waves"]
    GA --> R6
    AL1 --> R6
    O2 --> R6
    R5a --> R6
    XDEL --> R6
    XCL[["X-CLAIMS"]]
    XCL -.-> R6
    GADW{{"G-ADOPT per wave"}}
    GADW --> R6
    R6 --> R7["R7 legacy-writer retirement"]
    GRET{{"G-RETIRE"}}
    GRET --> R7

6. Dependency table

Item Depends on Why
Any implementation slice T-HOLD lifted; T-G0 approved; its gate passed (D1-04) The hold stands until Chris lifts it; gate authorisation covers building and merging dark only
Sending the design handoff (T-DH-01) Chris's instruction No design session is messaged without it
F1a M0 go; F1a parts of T-RD-00, T-SP-00, T-BC-00, T-RS-00, T-TI-00 approved The form version shape with its target, the C20 envelope, the claim contract and conversion records freeze here
F1b F1b parts of T-AC-00, T-TI-00, T-RI-00 approved New capabilities and the C15 v2 content policy freeze here
F1c T-UX-00 F1c part approved; T-DH-04 recommended The copy deck and IA should reflect the iterated prototype
R2a R0 staging rehearsal; F1a, F1b, F1c The first canonical form must carry its target in its version (OS-A12)
R2b R2a; claim contract v2 One place across stages needs form-keyed claims (D2-07, D2-08)
R2c F2 (T-RD-00 F2 part); R2a Generated versions, target-only publications and overrides (D2-01, OS-A12)
R2d R2c FV4 and guided correction build on publication generations
R3a F3 (T-SP-00, T-TI-00 step kind, T-RS-00 step mapping); R2a; R0 screening floor step; X-ARCH-d Filters, steps and step kinds freeze together
Pool history and events C20 envelope (F1a); stage-pool types (F3) Events are written in the commit transaction from R3a
R3b F5 (T-RS-00 F5 part, T-RI-00 protocol record and source slot); R3a; R2c Profile versions carry Unsure, ties and the reserved source slot
R3c R3a Lifecycle, collective Include and browsing read R3a's model
R4a F4 (T-RS-00 F4 part); R2b; X-RECLAIM; T-OI-01 or both options carried Accepted results and target-one handling
Reconciled-answer filter clauses R4a; R3a Clauses read accepted results
Bulk acceptance R4a pilot exit Q-11 places it after the core workflow
R4p R3b; R4a Adjudication tasks run inside profiles and reuse reconciliation
Discussion route R4p Falls back to the tie policy when unresolved
P2a P1; F-P (C21, T-DM-00); R0 floor step with the tombstone predicate; C20 Consolidation needs Study state and tombstones that every legacy writer refuses
P2a ship gate T-SI-04 Parity rows stay pending until the method is recorded
P2b P2a; R2b; R3b; R3a events Reviewed duplicates carry shared sessions and profile decisions and write pool events
P2c P2b; R4a; R4p Accepted-result and adjudicated-outcome conflicts need those results
R5c R4a; T-SI-02 Agreement formulas need specialist review
R5b F6b with T-SI-05; P2b; R3b; R4p Stage measures need the box mapping
O1 event-count schema F-O with T-SI-01 The field-level meaning comes from methodologists
Curated catalogue templates T-SI-03 No template is published without the sign-off record (RI-AE39)
TR1 F-TR; R3a; R3b; automatic admission also R1c and R1d Step kind, profile training and group contracts with anti-escalation
C2 beta F-C; C1; Q-18; Q-19; collective inference also R4a Candidate inference reads one reviewer's snapshot; collective reads pinned accepted results
XS1 GA; F-XS (C22); R3b; R4p; P1; P2a; C20 Profile versions, adjudication, identity matching and merge lineage
XA1 GA; F-XA; R2a A later import lane
Contribution exclusion R2a, R3a, R3b by scope; R4a and R4p for dependent flags; C20 Each scope selects by recorded provenance
Reversible project deletion X-DEL amended; R0 composite guard; R2a; R3a Canonical claims, drafts and pools must honour the deletion marker
Any production email Content policy, mute and D3-21 controls; G-NOTIF Sent email cannot be recalled
GA R2d, R3c, R3d, R4p; reconciled-answer clauses (PROPOSAL); legacy-screen refresh; production chains Canonical by default for new projects
Conversion staging trial The scope's releases; T-BC-01; T-BC-06 Only complete scopes convert
Conversion production pilot The scope's staging trial; D2-13 rehearsal; R0 production soak; G-ADOPT for that pilot Owner opt-in, reversible until the first canonical write
R6 universal waves GA; parity on pilots; AL1; O2; R2d; R5a; X-DEL; X-CLAIMS; G-ADOPT per wave Every capability a legacy project uses must exist first
R7 R6 complete; G-RETIRE Retirement is its own verified milestone
RW1 GA; R2c; R3a; R3b Redesign is an ordinary versioned publication
PWA1 build Chris's decision on the feasibility report Exploration only; no offline writes are authorised
BR1 R4a; its own approved brief Deferred beyond MVP

7. Gates and what each needs

7.1 Hold, G0 and brief approvals

T-HOLD and T-G0 are separate owner acts and neither has happened. A brief may be approved in parts, each part before the gate that freezes it.

Brief Part and the gate that needs it
T-RD-00 Definitions, sessions and drafts (F1a); publication, overrides and collaborative drafts (F2); additional-review requests (F4)
T-DM-00 C21 and the P2a to P2c split (F-P)
T-SP-00 C20 envelope and claim contract (F1a); filters, steps, step kinds, history and capacity (F3)
T-RS-00 Inert ReconciliationPolicy slot (F1a); C9 (F4); profile settings (F5)
T-BC-00 Conversion records (F1a); trials (before the first staging trial); pilots and waves (each G-ADOPT); retirement (G-RETIRE)
T-TI-00 Exposure kinds (F1a); capabilities (F1b); step kind (F3); training lane (F-TR); beta (F-C)
T-RI-00 Identification part (F-P); protocol record and source slot (F5); as-of (F6a); reporting (F6b); outcome schemas (F-O); XS1 (F-XS); XA1 (F-XA)
T-UX-00 Copy deck and IA (F1c). D3-14 and D3-15 settle what S0's seeds and browser projects do; S0-4 and S0-7 still need their briefs approved, G0 passed and the hold lifted (G0 dossier, G0-X8)
T-AC-00 Capabilities and C15 v2 (F1b); named attribution (R1b); exclusion (from R2a); deletion (X-DEL); notifications (G-NOTIF)
T-DH-00 Chris decides whether and when to send it (T-DH-01); before the W0 prototypes is preferred

7.2 Gate table

Gate Owner-session additions to its freeze or evidence Specialist inputs Owner inputs Authorises once passed and the hold is lifted
G0 (T-G0) Exceptions G0-X14 to G0-X19: the design handoff as an input (X14), briefs citing the specifications (X15), M0-3 re-scoped (X16), F1a drafts with the owner-session content (X17), R6 and R7 reframed (X18), the R1a catalogue rule (X19) None G0-D1 (D4-18 reading); G0-D4 to G0-D10 (PR dispositions, not authorised); G0-D2, G0-D3 and G0-D11 are answered by D3-14, D3-15 and D3-08 S0, M0, R1b, R1a audit, browse and preview, W0 prototypes, ADR drafts
M0 The writer and reader inventory also serves conversion None None F1a ADRs may be finalised
F1a Target and ReconciliationPolicy in the form version; StudyVersion and Study state; draft change log; form-keyed claims with form-owned limits; C20 envelope; conversion records; registry names None Brief confirmations in RD §12 (draft history retention, statistics wording) R0; R2a backend; R2b backend against fakes
F1b New capabilities; C15 v2 with the content policy, mute and notice resolution None ACD §12 items B4, B5, B6 R2a exports; C15 v2 implementation
F1c Draft, checkpoint and completion copy; step selector; prototype iteration outcome None UX §12 items A1, A2 R2a UI
F2 Generated versions; target-only publications; overrides and their treatment; immutable compatibility declarations; collaborative drafts; measured protection limits None RD §12 override treatment and generation table R2c
F3 Filters, steps, step kinds, exclusion-stop, continuation, browsing; stage-pool and eligibility events; D3-09, D3-13, D3-16, D3-18, D3-19 None SP-AMB-01, SP-AMB-02, SP-AMB-03, SP-AMB-07; own-Unsure progression (RS §12); optional dependency on passed training (TI §12) R3a; R3c design
F4 C9 with result authority, target-one handling, NoAcceptance (PROPOSAL), blinding, hints, optional expiry; Q-35 removed Exposure markers for T-SI-02 come from C3 D2-09 (T-OI-01) or both options; RS §12 items (default handling, converted target-one forms, Q-36 reading, re-acceptance, suspension) R4a
F5 Unsure, tie policy and bound, discussion, rationale, blinding; reserved source slot; protocol amendment rule None Screening-annotation agreement bypass (RS §12) R3b; R4p design
F6a History watermark rule in C11 None None R5a
F6b Stage measures; machine-only breakdown in manifests T-SI-05 None R5b
F-P C21; prepared multi-source links; C12 identification T-SI-04 before P2a's ship gate DM §12 ambiguities 1 and 3 P1; P2a to P2c
F-C Beta opt-in record None Beta scope (TI §12) C1; C2 beta
F-O As planned T-SI-01 None O1; O2 build (execution separately)
F-A As planned None None AL1
F-TR (PROPOSAL) Training contracts None (methodologist guidance on practice items is advisory) Feedback disclosure default; optional training dependency (TI §12) TR1
F-XS (PROPOSAL) C22 T-SI-02 before any mixed agreement metric; T-SI-05 before reporting XS1 outcomes RI §12 items A2 and A3 XS1
F-XA (PROPOSAL) Annotation-import contract None None XA1
G-NOTIF Content policy and per-project mute in place; D3-21 controls None Chris per environment and kind family Enabling that kind family there
G-GA As in Phase 7 None Chris Canonical default for new projects
G-ADOPT per pilot Approved manifest; scope staging trial; D2-13 rehearsal; R0 production soak None Chris; the project owner's opt-in; BC §12 item A2 That pilot's conversion
G-ADOPT per wave Parity on pilots; every needed capability shipped; wave manifest scope None Chris; BC §12 items A3 and A4 That wave
G-RETIRE Retirement readiness record (BC-AE29) None Chris Removing legacy writers

Production enablement per release (delivery operating model §8.6) is unchanged and needs Chris's approval each time.

7.3 Specialist inputs

Row Input Needed before What waits Until recorded
T-SI-01 Q-17 event-count fields and the meaning of "variation" F-O O1's event-count schema The event-count part of F-O stays open; the F-O dossier may split it from O1's other schema work (PROPOSAL)
T-SI-02 Q-16 and D4-12 agreement methods R5c ship gate; any XS1 mixed metric; TR1's training agreement report Agreement figures R5c cannot pass; machine and human classes are never combined
T-SI-03 D4-06 template curation Catalogue publication of curated templates SYRCLE, CAMARADES checklist and ARRIVE templates The catalogue ships without them
T-SI-04 D4-21 ASySD parity method and thresholds P2a ship gate Parity rows AC-P2-01r and AC-P2-13 P2 cannot pass its ship gate
T-SI-05 PRISMA box mapping for pool history versus review through the stage F6b R5b; DM-AE22; XS1 box placement (RI A1); converted-history coverage in diagrams History is still recorded from R3a; only its reporting waits

7.4 Design-prototype handoff

T-DH-00 is an early design input. The handoff in specifications/design-prototype-handoff.md points at SyRF Prototype v10 and asks for an iteration; it invents no new prototype. Chris decides whether and when to send it (T-DH-01); agents never message the design session. The iteration (T-DH-02) and its review against the specifications (T-DH-03) should come before the W0 prototype validations, so that F1c's copy deck and IA (T-DH-04) reflect the owner session. If the handoff is not sent, F1c proceeds from v10 with the owner ledger overlay and the specifications, and its dossier records the gap (PROPOSAL).

7.5 Owner decisions and brief confirmations

  • Open owner decision. D2-09 only (T-OI-01). Recommendation unchanged: the second form's reconciler may revise with a new snapshot. F4 can freeze with both options carried (RD-AE25).
  • Owner-visible brief confirmations. These are not new questionnaires. Each specification's §12 lists them with a recommendation; the gate table names the gate each belongs to. Only genuine scientific or product choices go back to Chris.

7.6 Rollout-level ambiguities

Each is stated once, with options and a recommendation. None is answered here.

ID Question Options Recommendation
R-AMB-01 Is training (TR1) a GA prerequisite? (a) A delivery-scope lane that does not gate GA. (b) A GA prerequisite (a). The condensed packages say calibration need not enter the first engine release, and legacy SyRF has no training to lose
R-AMB-02 When do reconciled-answer clauses in stage filters ship? SP leaves the timing to the owner (a) An R4a increment inside GA scope. (b) After GA (a). The consolidation keeps them in scope while deferring branching
R-AMB-03 What does "after the first engine release" mean for XS1? (a) After GA. (b) As soon as R3b, R4p, P1 and P2a ship (a). F5 reserves the profile slot, so (b) stays possible without a breaking change if Chris wants it earlier
R-AMB-04 Where does presence on question-design pages land? RD says R2c; UX ties it to R1a and R2a (a) Single-editor drafts with base checks in R2a, presence and live updates in R2c. (b) Presence from R1a on the legacy editor (a). The draft model presence needs is canonical, and R1a runs on the legacy API
R-AMB-05 Does ReviewStartEligibility start in R2a or R3a? SP leaves it to this plan (a) R3a. (b) R2a, for pilot coverage (a). Eligibility event types freeze at F3; R2a pilot starts stay reconstructable from session versions with route provenance, and R3a's tracking start labels the earlier period
R-AMB-06 May production conversion pilots precede GA? (a) Yes, for complete scopes, each through G-ADOPT. (b) Only after GA (a). D4-16 allows limited complete-scope adoption and BC gives each pilot its own approval

7.7 Harvest of existing work and dormant PRs

The harvest map places 131 entries from 13 open PRs: the QM v2 stack (#2461 and

2572 to #2575), #2224, #3934, #2781, #2387, #2986, #2987, #2629 and #2812. It holds 6 Reuse, 41

Adapt, 35 Reference only and 49 Avoid entries. Nothing is ported, rebased or closed while the hold lasts.

  • Sequencing. Each port is a fresh PR in the slice of the release that uses it, under that release's approved brief and after its freeze gate:
  • M0 writes the QM v2 harvest-and-avoid record (T-RD-10);
  • F1a takes the contract inputs (T-RD-01), and F-O the response metadata units (T-RI-11);
  • R1a takes the import pipeline and the editor hardening (T-RD-11, T-RD-12);
  • R1b and R1c take #2224's pieces (T-AC-11, T-AC-10);
  • R2a, F2 and R2c take the domain, publication and impact pieces (T-RD-02, T-RD-04, T-RD-05, T-UX-06);
  • the conversion rows take PR-C's adapters before any pilot (T-BC-01, T-BC-03, T-BC-05, T-BC-06);
  • R5a and X1 take the export pieces (T-RI-12, T-RI-08).
  • Closure gates. A PR closes only when its harvest slice has merged, G0 has passed, the hold is lifted and Chris has answered its disposition item. The QM v2 stack needs G0-D4, after T-RD-10 (T-RD-13). #2224 needs G0-D5, after T-AC-10 (T-AC-12). #2986 needs G0-D6 (T-RD-14). #2987, #2629 and #2812 need G0-D7, after the F1a C4 draft (T-RD-15). #3934, #2781 and #2387 have no disposition item yet (T-RD-16; harvest map §10).
  • Never carried. PR-C's migration erases the embedded legacy data from pmStudy, and its rollback is a lossy hand-back to the legacy model. Both contradict BC-R27, BC-R29, C16 and AC-M0-04 (harvest map §6).

8. Pilots and conversion waves

Pilots start on synthetic projects in the e2e stack, then on seeded preview and staging projects (Q-07, D3-14), with the agreed tester panel (D3-08). Production pilots need their own approval. No pilot uses production data for UX work.

Pilot or wave Where Entry evidence Exit evidence Approval
R2a canonical forms with the target in the version Synthetic, then seeded staging projects RD-AE01 to RD-AE05, RD-AE24, UX-AE07 on the release candidate RD-AE27; RD-AE23 measured; pilot exit criteria with zero lost work Ship gate; production pilots on new projects per D1-07 after R0's soak
Phone annotation of large forms Synthetic large-form seed, then tester projects in staging UX-AE03, UX-AE04 UX-AE06 against a budget set at the R2a freeze; UX-AE30 Ship gate
Target-one forms before R4a Staging Labelled "single annotator, acceptance not yet available" RS-AE06 when R4a is enabled through an admin-confirmed operation (PROPOSAL) R4a enablement per project
R2c publication with generated versions Staging under X-STATS-a, then named production pilots under Q-31(b) RD-AE06 to RD-AE08, RD-AE14 to RD-AE20 RD-AE26 measured; UX-AE22 Ship gate; production approval
R3a filters, steps and pool history A "stage pools" seed project SP-AE01 to SP-AE27 SP-AE38 (three admins read no fixture as a platform error); SP-AE17 and SP-AE42 measured Ship gate; X-ELIG for production
Shared-form capacity Admitted pilot projects only AC-T-03 to AC-T-07; SP-AE31 to SP-AE33 Pilot review before wider opt-in X-CLAIMS; production approval
Collective Include setting Staging, after R3a SP-AE23 Pilot validation recorded (SP-AMB-11) R3c ship gate
R4a reconciliation Seeded staging projects RS-AE01 to RS-AE17 RS-AE30; bulk acceptance only after this exit Ship gate
R4p adjudication Seeded staging projects RS-AE19 to RS-AE25, RS-AE33 RS-AE32 Ship gate
Deduplication P2a and P2b Seeds with duplicate pairs for every scenario DM-AE01 to DM-AE21 RI-AE33 once T-SI-04 is recorded Ship gate; a production pilot needs its own approval
Training TR1 Staging; manual admission first TI-AE01 to TI-AE06 TI-AE15; automatic admission only after the manual pilot Ship gate; automatic admission flag per environment
Inference C2 beta Seeded preview and staging projects TI-AE16 to TI-AE24 TI-AE25 before any wider enablement GA promotion is a separate decision
External and AI-model screening XS1 A seed with a synthetic model configuration and run, no real model output RI-AE20 to RI-AE32 RI-AE36, RI-AE37 No production import without its own approval
Conversion staging trial, per scope Seeded and synthetic legacy fixtures BC-AE01 to BC-AE05 and the scope's mapping evidence (BC-AE06 to BC-AE12, SP-AE40) BC-AE13, BC-AE14, BC-AE16 on the fixture, BC-AE17 to BC-AE20 The release's own gate
Conversion production pilot An owner opt-in project with a complete scope The scope's trial passed; BC-AE27 rehearsal; approved manifest; R0 production soak BC-AE13, BC-AE14, BC-AE17 to BC-AE20 on the pilot; monitoring; BC-AE16 for the largest project only on an authorised copy G-ADOPT for that pilot
Universal wave Every remaining project Parity proven on pilots; every needed capability shipped; manifest approval scope settled (BC A3) BC-AE21, BC-AE24, BC-AE25; AC-R6 rows as amended G-ADOPT for that wave
Retirement The platform Every project converted or remediated BC-AE28, BC-AE29; AC-R7-01 to AC-R7-03 G-RETIRE

9. Flag decisions for new items

The repository requires an explicit flag decision for every new feature. Names are PROPOSALs from the specifications.

Item Flag Default Reason
Target in form version; generated versions No new environment flag; per-project enrolment governs; withdrawing publication scope through enrolment is the kill switch Off until enrolled Part of the publication contract (RD §10)
Pool history and events Not flagged inside canonical scopes On with the scope Switching history off would create unexplainable gaps (SP §10.1)
Eligibility timeline screen stageEligibilityTimeline Off until staging acceptance UI risk only
Reviewer study pool browsing reviewerPoolBrowsing plus a per-stage setting Off Optional behaviour
Reconciled-answer filter clauses stageFilterAcceptedAnswerClauses Off Changes pool membership
Hints and click-to-fill Own flag per environment Off; the form default is Shown once enabled Lets pilots stage it (RS §10)
Bulk acceptance; discussion route Own flags; per-form or per-profile settings off Off Optional increments
Duplicate merge Per-project enrolment; a project switch that stops new merges and keeps unmerge Off Kill switch for data-changing operations (DM §10)
Contribution exclusion contributionExclusion Off Changes current use of evidence
Reversible project deletion Existing deletionLifecycle Off Deletion-lifecycle programme
Emails, inbox, conversations notificationEmail, notificationInbox, reconciliationConversations Off G-NOTIF per environment and kind family
Pilot timing telemetry pilotTimingTelemetry Off Personal data; needs a kill switch
Training Training kill switch; own flags for automatic admission and promotion Off Admission changes membership
Inference beta Per-project opt-in record plus an environment kill switch Off Opt-in beta (OS-A19)
External and AI-model screening externalScreeningSources Off Changes authoritative outcomes; spans API and PM
Annotation-answer imports New flag Off Later lane
Conversion wizard and wave tooling Default-off flags; per-project enrolment and ownership markers govern conversion Off Data-changing operations
PWA None Not applicable Exploration only; nothing is built

10. Risks and re-plan triggers

Every gate stays a re-plan point, and the triggers in delivery operating model §5.6 still apply. These are the risks the owner-session changes add.

Risk Where it bites Mitigation Re-plan trigger
Target-only publications make publication more frequent and heavier R2c Publication protection measured under D2-10; generation table chosen at F2 RD-AE16, RD-AE23 or RD-AE26 fails at the largest-project tier
Generated session versions cost too much at scale R2c The F2 generation table may keep autoUpdate derived instead of generated Phase 2 generation misses its measured budget
The current evidence view cannot be kept consistent or fast P2a Its design is proven before freeze (DM-AE11); a reference-in-place alternative is measured DM-AE11 parity or read budget fails
Pool history adds write and sweep load R3a Targeted reevaluation only; no page-query logging SP-AE17 or SP-AE42 budgets missed on Bramble
The C20 envelope needs a breaking change after F1a F3 and every event writer Other specifications extend only through C20 A later freeze proposes an envelope change
Specialist inputs arrive late R5b, R5c, O1, P2a, catalogue Requests drafted early; recording never waits for reporting Any T-SI row unrecorded when its gate's dossier is ready
Owner-visible confirmations queue on one approver Every gate Confirmations batched into the sitting before each gate A confirmation waits longer than the existing re-plan trigger allows
Legacy reconciliation records exist after all Conversion Every dry run counts them; the case stops (BC-AE11) Any dry run reports one; Chris decides (BC §10.3)
Projects cannot convert faithfully R6 Quarantine with a recorded remedy; trials and pilots first A pilot is quarantined with no remedy in any planned lane
The largest project misses performance budgets R2a, phone UX, conversion Acceptance case from R2a RD-AE23, UX-AE06 or BC-AE16 fails
Authorization gates slip TR1 automatic admission, R1c Manual admission ships first R1c remains blocked when TR1's admission increment is ready
Machine-assisted outcomes are misreported XS1, R5b Machine-only breakdown always stored; box placement through T-SI-05 RI A1 unresolved when XS1's F-XS dossier is ready
The prototype iteration diverges from the specifications F1c, W0 T-DH-03 records every deviation A deviation contradicts an owner decision
An owner decision changes after a brief is approved The affected brief The brief returns to Brief drafted Any later explicit owner decision that conflicts with an approved brief
The hold stays in place after G0 Everything Planning continues; nothing builds The hold is lifted, which itself is a re-plan point

11. What never happens without separate approval

  • Production activation. Production enablement of any release, production flag values, GitOps production values, production admission of pilot projects, production pilots, telemetry collection and the inference beta's GA promotion.
  • Migration execution. Production inventories and dry runs against production data, any conversion pilot or wave, O2 execution, production index builds, D2-13 recovery execution in production, and legacy-writer retirement.
  • Notification delivery. Any notice or email outside the e2e stack and Mailpit before G-NOTIF for that environment and kind family.
  • PR closure. Closing dormant or unrelated PRs, including those in G0-D4 to G0-D10.
  • Physical erasure. Permanent physical erasure of project data (T-POL-01) and any identity-erasure process (T-POL-02).
  • Automatic acceptance of agreeing candidates. Agreement between several candidates never creates an accepted result by itself (T-POL-03).
  • Design session and prototypes. Messaging the design session or building a new prototype.
  • Automatic membership changes. Training's automatic group admission in any environment before its flag is approved there.
  • Imports. Any production import of external, AI-model or annotation answers.
  • Numeric thresholds. Treating any proposed number as approved.