Acceptance criteria for every release

Temporary planning document; planning only. Chris asked on 3 October 2026 for well-defined acceptance criteria in the plan (AC1). This page is the authoritative list. This revision answers the round-2 reviews; the resolution record maps every finding to its outcome. The release sections of the integrated plan summarise these criteria. A release ships only when every row that applies to it has passed with recorded evidence on its release candidate, and no row whose status is pending, PROPOSAL or conditional has been counted as passed (§1.2).

Companion documents this page relies on: contracts (C1–C17; C18 and C19 are new), versioning model, consistency model, domain model, programme integration, delivery operating model, UX strategy, methodology coverage, PRISMA amendments and open questions. Questions for Chris use the Batch D IDs (D1-01 to D4-21) recorded with the round-2 resolution. Chris decided D1-01 on 3 October (keep

3964 over #3969); no criterion changes as a result. On the evening of 3 October he approved

D1-02 to D1-09 as recommended (decision register §1.13), so no D1 question is open: rows that waited only on a D1 answer are now confirmed. Late that evening he gave the G0 inputs (decision register §1.14): the tester names (D1-06; no external SyRF users named yet), the date for activating #3987's families (D1-03: from 5 October 2026, staging first, production the following week as a target), Q-03 as recommended, so rows that waited only on Q-03 are now confirmed, and D4-18 ("independent of funders"), whose recorded reading stays PROPOSAL until Chris confirms it in the G0 dossier, so AC-GA-08 stays pending until then. One part is still to come and is marked where it applies: F1a's confirmation of the D1-08 start thresholds from M0 evidence (an inline PROPOSAL until F1a).

1. How to read this document

1.1 Identifiers

Pattern	Meaning
AC-<release>-<nn>	A criterion for one release (AC-R2a-03). An r suffix (AC-R5a-02r) marks a replacement a reviewer proposed; the replaced ID is retired (§4.37) and never reused.
AC-<release>-CONF	The release's conformance row: the contract tests (§7.5) that must pass in full on its release candidate.
AC-ALL-<nn>	A criterion every release meets (§2), marked merge (M) or activation (A).
AC-UX-<nn>	A UX metric (§2.3). The UX strategy owns the research plan and may refine wording; IDs stay.
AC-T-<nn>	A claims and tracking prerequisite (§4.35).
UI-<n>	The UI standard (§3).
PE-<nn>, PI-<release>-<nn>	Pilot exit and pilot entry (§5).
FX-…, INV-<nn>, C<n>-T<nn>, RV-DS-<nn>	Fixture data (§7.2–§7.3), invariant checks (§7.4), contract conformance tests (§7.5), benchmark datasets (§6.1).
Review IDs	Round-2 finding IDs (review AC-nn, V2-nn, DC-nn, VA-nn, VB-nn, RT-nn, NS-nn, MS-nn, AP-nn, SR-nn, UX-nn, PH-nn, DS-nn) appear mainly in Source columns and the resolution record. "Review AC-nn" means a finding of the acceptance-criteria review, never a criterion; reviewer-proposed IDs that were renumbered (such as the DC review's AC-DC-nn) are listed as aliases there.

1.2 Columns and statuses

Every criterion row has a Source and a Status.

Source is one or more of: a ledger ID (SF1, RE2, …); a decision-register §1.11 ID (UI1, QD1, SEC1, Q-10, …); RECOVERED (an earlier design the ledger says not to reopen); RULE (a repository rule in CLAUDE.md that binds every PR); an approved specification (FEAT-011 or FEAT-012, DOC-APPROVED); a Q-xx or A-xx item; a Batch D ID; a research acceptance case (A1–A28 in the screening research); a contract, plan section or companion document of this package (for example "consistency model"); or a review finding.

Status	Meaning	Can it pass at a ship gate?
confirmed	The behaviour is what a confirmed owner decision, recovered baseline, repository rule or approved specification requires.	Yes
pending-Q-xx, pending-Dn-nn	Written as the concrete recommended answer, so a test can fail it. At the release's freeze gate the row is re-confirmed from Chris's answer, rewritten, or the behaviour is descoped.	No, until answered
assumption-A-xx	Follows a provisional assumption. If the assumption changes, the row is rewritten.	Yes, while the assumption stands
PROPOSAL	A design choice or threshold of this plan. Confirmed at the release's freeze gate and recorded in its acceptance record. Inline PROPOSAL values inside any row follow the same rule.	Only after confirmation
conditional-<join>	Applies only once the named external join has landed. Recorded as N/A before that.	Only after the join

A row with several statuses (comma-separated) passes only when all of them clear. A row whose verification method needs tooling that doesn't exist yet (§10) can't be marked passed.

1.3 Merge criteria, activation criteria and tiers

• Merge criteria (M) apply to every PR in the programme, on its exact head, before merge (§2.1 and the M rows of §3).
• Activation criteria (A) apply once per release, on a recorded release-candidate commit and image SHAs deployed to staging (or to a pinned preview where §8.3 allows it). Results go into the release's acceptance record (§9). When later merges touch the release's paths before activation, the affected automated rows run again.
• Release criteria (§4) are activation criteria unless a row says M. Their tests are written and merged in the PRs that build the behaviour; activation re-runs them on the candidate.
• Tiers (T1 heavy, T2 standard, T3 light; §8.3) decide which activation evidence a release needs: rehearsal, testers, benchmarks and review depth.

1.4 Verification methods

Code	Method	Evidence
U	Unit test, architecture test or guard spec	Test names in the PR; CI green on the exact head
I	Integration test (API, MongoDB through Testcontainers; the replica-set fixture for transactions)	As U
C	Contract or conformance suite (shared JSON corpus, table-driven, run by xUnit and Vitest)	Suite results on the exact head and on the release candidate
H	Mixed-version harness: the recorded minimum image runs against canonical data written by the current image (new)	Harness report with both image SHAs
E	End-to-end journey in the hermetic local e2e stack, never against staging	Per-spec run output tagged with criterion IDs
X	Cross-browser smoke journey (Firefox and WebKit Playwright projects) (new)	Per-project run output
B	Benchmark on Bramble in a booked window (backend), or on the host where an AF2 client budget was measured	Report with commit, dataset, host and main baseline
R	Rehearsal on staging or an authorised non-production copy (rollback, floor step, restore, migration)	Rehearsal record in the release ADR
M	Monitor or telemetry evidence on a running environment (invariant monitor, dashboard) (new)	Monitor and dashboard exports for the period
S	Staging acceptance by humans on seeded or tester-created projects	Signed acceptance note naming the candidate SHA
UT	User-testing session against the tasks and rubrics in §5.3	Session notes and scores
V	Visual and design review (screenshots, staging walkthrough)	Screenshot set; Chris's acceptance
A	Accessibility check (axe inside journeys, manual keyboard and screen reader)	axe report; checklist
D	Documentation review	Changed /docs/ and /user-guide/ files
G	Governance (approval, sign-off, recorded decision)	Link to the record

Rules that make the methods able to fail:

• Every row about persisted state has an I or C test; E is for behaviour seen in the UI (review AC-26).
• Every concurrency row forces its interleaving with the barrier harness (§10, L17-05) and asserts that the interleaving happened: the losing command saw the typed conflict and kept its draft (review AC-12). Fixed seeded schedules make runs repeatable.
• A negative assertion first proves the operation ran.
• Each release's first PR lands its criteria as skipped tests tagged with their IDs, plus its fixture files, so progress is rows turning green (review AC §3.4).

1.5 What changed in this revision

The previous version (227 IDs) is revised in place. In summary: a Source and Status on every row; merge criteria separated from activation criteria; release tiers; a conformance row per release with contract test IDs; fixtures as versioned data with per-release assertions; invariant checks; a traceability file with generated views; the acceptance tooling as dated deliverables; a new S0 scaffolding release; and the criteria the reviews found missing. Placeholder rows ("as Q-xx decides") are now concrete provisional assertions that can't pass until Chris answers. Counts are in the resolution record.

2. Criteria every release meets

2.1 Merge criteria (every PR)

ID	Criterion	Verified by	Source	Status
AC-ALL-01	With every flag the release introduces turned off, the release's flags-off spec set (named in its brief, with the tracking mode each spec runs in) passes unchanged, and nothing new is reachable: new endpoints return the typed "feature unavailable" result or 404, and new routes are absent or redirect.	E, I	RULE (flag decision); review AC-03; RT-04	confirmed
AC-ALL-02	Legacy (non-admitted) projects behave as before. For the five existing seed projects and FX-LEGACY, export data files equal main's (generation metadata aside), except for changes the PR lists as deliberate, each behind a flag.	I, E	Q-07; A-04	confirmed
AC-ALL-03	Every new endpoint, view, SignalR message and notification kind has tests for an authorised user (allowed), an unauthorised user (refused, no data), a revoked user (canonical commands refused on the next request; page reads within the C18-T06 bound) and blinding (no hidden identity or answer). SyrfAdmin is used only for application-admin paths, and each blinded surface has one SyrfAdmin negative test. Every endpoint is in the permission catalogue and the catalogue coverage test passes.	I	PM1; C10; review AC-10; DC-12	confirmed
AC-ALL-05	New code has unit or integration tests; CI is green on the exact head; the conformance suites of every touched contract run and pass; there are no new lint suppressions or test exclusions; the web repository guard specs pass (src/services/web/src/global-styles/syrf-theme.spec.ts, src/services/web/src/app/shared/utils/hot-hook-zoneless-discipline.spec.ts, src/services/web/src/app/shared/pipes/user-guide-url/no-hardcoded-help-urls.spec.ts), and pnpm run check:theme-migration and pnpm run check:contrast pass when styles change.	U, I, C	RULE (all code changes need tests); review AC §3.2	confirmed
AC-ALL-06	/docs/ and /user-guide/ change in the same PR as the behaviour; the PR states its flag decision; user-guide pages for unreleased behaviour sit under target markers and are published at enablement.	D	RULE; delivery operating model	confirmed
AC-ALL-10	New commands log structured events with actor, real actor, on-behalf-of identity, project and command ID. Expected conflicts return the C18 typed outcomes (stale base, retryable conflict, locked, fenced, outcome unknown, refused, publication in progress, size limit exceeded, conflicted legacy answer, command digest mismatch), never a 500.	I	C18 (consistency model); DC-11; VB improvement 6	PROPOSAL
AC-ALL-14	Every PR keeps AC-ALL-01 and AC-ALL-02 true. Unit and integration suites always run; when the PR touches a flow listed in the release brief, the release's flags-off e2e spec set runs (run:e2e-smoke for flows mapped to smoke specs, run:e2e-full otherwise).	U, I, E	review AC-03, AC-26	PROPOSAL
AC-ALL-15	No spec for a changed component, route or service is excluded from the web test run. A script checks the PR's changed paths against both exclusion lists: src/services/web/angular.json (45 entries on main at de3e98c59, including project-options/**, the Members & groups dialogs and data-export/screening) and src/services/web/vitest.config.ts (which also excludes the whole question-management/** folder).	U	RULE; review AC-15	confirmed
AC-ALL-16	Tests that evidence a criterion carry its ID ([Trait("AC", "AC-R2a-03")] in xUnit, an @AC-R2a-03 tag in Playwright, a describe('AC-R2a-03 …') prefix in Vitest); the PR body lists the IDs it advances; the traceability check (§9) passes.	U, G	AC1; review AC-01	PROPOSAL
AC-ALL-28	No debug component (app-debugger-group or equivalent) renders on a route a reviewer or reconciler can reach unless the debug flag is on (guard spec).	U	UX-20	PROPOSAL

2.2 Activation criteria (once per release, by tier)

ID	Criterion	Applies to	Verified by	Source	Status
AC-ALL-04	Rollback by tier. (a) T1, and any T2 release that persists new data: the mixed-version harness runs the recorded minimum rollback image against canonical fixture data (reads, legacy flows, an unrelated-field replace round trip): nothing throws, no field is stripped, legacy writers still refuse canonical scopes. (b) T1 releases and every floor step: a staging image rollback in an agreed promotion-pause window, with canonical data present, passes (a). © If the release changed a FEAT-024 writer, family or protocol, the rehearsal follows FEAT-024's rollback order (fold disable and wait for Disabled, project gate, fleet gate, flags off through GitOps on both hosts, allowlist guard, then images) and records fold mode and stamp before and after. (d) If it added a notification kind, the rehearsal includes the delivery halt and an older binary running with the new kinds present.	T1; T2 (a) only	H, R	C16; amendment I (Q-06a); review AC-23; DS-11; MS-16; NS-26	PROPOSAL
AC-ALL-07	Accessibility: axe checks inside the release's journey specs report no serious or critical violation on new or changed screens; the main tasks complete by keyboard alone with visible focus; controls have accessible names; polite live regions announce autosave state, conflicts and status changes; focus moves to error and conflict summaries; dialogs trap and return focus; forced colours work; layouts reflow at 200% zoom, at 400% (320 CSS px) and in short windows (600 px tall); touch targets are at least 44 px below 600 px wide; reduced motion is respected; a named person runs the screen-reader matrix (NVDA with Firefox and Chrome, VoiceOver with Safari) on the release's key surfaces at staging acceptance.	Releases with UI	A, E	UI1; FEAT-023 validation matrix (docs/features/material-3-migration/technical-plan.md); review AC-19; UX-06, UX-15	PROPOSAL
AC-ALL-08	Every new or updated screen meets UI-1 to UI-11 (§3), with evidence on the release candidate.	Releases with UI	V, A, U	UI1	confirmed
AC-ALL-09	Performance: the release's named hot paths (from the fixed suite: Save, Complete, autosave, publication phase 1, Next and pool selection, reconcile load, export start, plus any endpoint the brief adds) meet their budgets on the RV-DS tiers, with 20 warm-up and 200 recorded iterations, against a baseline run of main on the same host for the same candidate. Backend runs use Bramble in a booked window; AF2 client budgets use the host where they were measured. With no stated budget, p95 regresses by at most 10%.	T1; T2 when a hot path changes	B	review AC-18; DS-12; PH-32	PROPOSAL
AC-ALL-11	The release's pilot entry rows (§5.2) held at pilot start, and PE-01 to PE-08 (§5.1) are met for its pilot projects with monitor and telemetry evidence.	User-facing releases	S, UT, M	Q-07; review AC-16	PROPOSAL
AC-ALL-12	Before any production pilot, every external join the release depends on (plan §5.11 and programme integration, including X-CLAIMS, X-STATS-b1 to b7, X-AUTH-RESOLVER and G-NOTIF where they apply) has recorded go/no-go evidence. Production opt-in pilots before GA were approved under D1-07 (3 October).	Production pilots	G	Q-25; D1-07; RT-02, RT-03; MS-01; AP-02; NS-04	confirmed
AC-ALL-13	Ship-gate verification: a fresh-context verifier maps every criterion ID that applies to the release (its own rows, its CONF row and the applicable AC-ALL, AC-UX and UI rows) to evidence on the candidate, checks invariants 1 to 12 across the release's PRs, and confirms that no pending, PROPOSAL or conditional row was counted as passed. Every PR in the release passed review on its exact head under its review tier with no unresolved thread. Chris's go/no-go is recorded in the acceptance record.	All	G	DS-13; review AC-02, AC-03; D1-04	PROPOSAL
AC-ALL-17	Flag combinations fail closed: an admitted canonical project opened through any surface that can't write canonical data (AF1, the legacy grid or editor, AF2 not admitted, a release or prerequisite flag off) shows the typed "not available here" state before accepting input, and no legacy write is attempted. The release brief lists its supported-flag matrix (release flags × admission × annotationFormV2, stageReviewRedesign, stageReviewDockview, reviewEligibilityPolicy, activeReviewerTrackingEnabled, notification and FEAT-024 flags) and the cells its I and E tests cover.	T1, T2	I, E	Contracts stance 6; Q-25; review AC-22	PROPOSAL
AC-ALL-18	Read-only containment: with the release flag off or admission removed after canonical writes, every surface the release added is read-only with the copy-deck explanation; no edit control is enabled; owners can still open their drafts and versions and copy their content; canonical exports work; legacy writers still refuse.	T1, and T2 that persist data	E, R	Migration §5; U28; review AC-23	PROPOSAL
AC-ALL-19	Disclosure probes: a table-driven suite over the F1b disclosure matrix (persona × surface × element) passes for every new endpoint, export column, SignalR message, notification channel (inbox, email, digest) and impersonation path, including SyrfAdmin, support edit mode and forged foreign IDs, which are refused before any mutation with the database unchanged.	All	C, I	C10; research A5, A10, A26; review AC-24; RT-14	PROPOSAL
AC-ALL-20	Telemetry: pilot-exit signals (draft-save failures, stale conflicts by type, refused legacy writes, typed errors by code, projection mismatches, monitor findings, notification capture failures) are on a staging dashboard before pilot entry, with thresholds agreed at the freeze gate; events carry opaque IDs only and no content.	User-facing releases	M, G	review AC-16	PROPOSAL
AC-ALL-21	Invariant monitor: the read-only checker (INV-01 to INV-12, §7.4) reports zero violations on every admitted project in the candidate environment, nightly and after every restore or adoption step; every finding is typed.	From R2a	I, M	review AC-16, AC-30; DC §5; VB-11	PROPOSAL
AC-ALL-22	Notifications on: C15-T01 to C15-T09 pass (the NS review's AC-C15-01 to 09). With the kind's flag on there is one item per recipient per event occurrence, a second lifecycle event is captured, payloads are generic, detail is reshaped under fresh authority ("Related item unavailable" and no email after revocation), and email goes only to Mailpit outside production.	Releases adding or changing a notification kind	I, E	C15; NS-01, NS-03, NS-11, NS-12; review AC-32	PROPOSAL
AC-ALL-23	Both tracking modes: the release's review-flow journeys pass with activeReviewerTrackingEnabled on and off, as a Playwright project matrix on one stack.	R2a, R2b, R3a, R4a and any release touching claims, admission or the reviewer workspace	E	RT-04	PROPOSAL
AC-ALL-24	On every form host the release changes, input latency under autosave has p95 under 50 ms (AF2's edit-to-settle p95 under 16 ms stays its own gate), autosave never blocks input, and a visible "N required missing" count with jump-to-next exists.	Releases changing a form host	B, E	UX-02; AC-UX-04	PROPOSAL
AC-ALL-25	Efficiency: on the pilot project, median time per title/abstract decision and per annotation form, and actions per decision, are no worse than the baseline study (AC-UX-03, AC-UX-04), measured in moderated sessions, or from privacy-safe timing events if D3-08 approves them.	Releases changing a reviewer surface	UT, S	UX-01, UX-02; D3-08	PROPOSAL
AC-ALL-26	Canonical write gate: zero engine-caused exhausted submissions at 1, 2, 5 and 10 concurrent reviewers, same-study and different-study, with the fold worker (where enabled), claims and one background sweep running; absolute p95 budgets per RV-DS tier (start, applying now under D1-08: Save ≤ 150 ms and Complete ≤ 300 ms on a 200-question form; F1a confirms them and sets the per-tier budgets from M0 evidence, PROPOSAL until F1a); the commit shape pinned by a CanonicalCommitCommandBudgetTests suite.	Releases adding or changing a canonical command	B	Consistency model; DC-16; PH-01; review AC-18; D1-08	confirmed
AC-ALL-27	Each reviewer-visible release ships a dismissible, per-user "What changed" entry keyed by release (the component lands in R2a), and every new screen links to its user-guide page through the userGuideUrl pipe.	Reviewer-visible releases	E, D	UX-09	PROPOSAL
AC-ALL-29	Notification enablement (G-NOTIF): capture happens only for projects admitted for notifications; staging and preview flag overrides need Chris's recorded approval per release; email outside production goes to Mailpit; an operator delivery halt pauses dispatch within one worker cycle and resumes without loss or duplicates; no notice or email reaches a user outside the admitted pilot projects (checked against the inbox and Mailpit).	Any environment enabling notifications	I, R, G	NS-04; C15-T07; D3-21	pending-D3-21
AC-ALL-30	Notification emails and digests carry at most a title, the project name and a link: never study titles, aliases, answers or free text.	Releases adding email categories	I	NS (question N2); D3-22	pending-D3-22
AC-ALL-31	A per-project email mute exists before production email: a muted project sends no email while the inbox still records.	Before production email	I, E	NS (question N4); D3-24	pending-D3-24

2.3 UX metrics

The baseline study (6–8 reviewers on today's screening and annotation, before R2a) and the research plan are in the UX strategy, which owns the measurement protocol; these rows use its wording and compare against the baseline.

ID	Criterion	Applies to	Verified by	Source	Status
AC-UX-01	Task success: at least 80% of testers complete each user-testing task for the release (§5.3) without help.	Every user-facing release	UT	UX-01; UX strategy	PROPOSAL
AC-UX-02	Comprehension: at least 80% of testers answer each explain question correctly against its model answer and rubric (§5.3): which version counts; why a study is offered or locked; what an accepted answer rests on; what a publication will do; and the release's own questions.	R2a, R2c, R3a, R3b, R4a, R5a, R5b and every release with an explain task	UT	UX-01; UX strategy	PROPOSAL
AC-UX-03	Screening throughput: median time per title and abstract decision and median actions per decision on the realistic-content project are no worse than the baseline study; a keyboard-only path exists with at most two actions per decision beyond answering eligibility questions.	R3a, R3b, then every release touching the screening card	UT, E; telemetry if D3-08 approves	UX-02	PROPOSAL
AC-UX-04	Annotation: time to complete the baseline 30-question form is at most the baseline plus 10%; keystroke-to-paint p95 is under 50 ms with autosave on at 200 and 1,000 questions.	R2a, then every release touching the form	UT, B	UX-02, UX-04	PROPOSAL
AC-UX-05	Reconciliation: median time per three-candidate study is at most 1.5 × the two-candidate task on the same build.	R4a, R4p, R4c	UT	UX-01	PROPOSAL
AC-UX-06	Error recovery: every tester recovers from a two-tab take-over, a stale base and a 60-second offline interval without losing an edit made before the event.	R2a, R4a	UT, E (network throttling)	UX-04, UX-17	PROPOSAL
AC-UX-07	Setup: a new administrator reaches a screenable stage from templates in at most 20 minutes without help.	R3d	UT	UX-19	PROPOSAL
AC-UX-08	Satisfaction: SEQ of at least 5.5 per task, or SUS of at least 70 per role per release.	Every user-facing release	UT	UX-01	PROPOSAL
AC-UX-09	Accessibility: zero serious or critical axe findings on the release's routes and journey states; the main tasks complete by keyboard alone; the screen-reader checklist passes; forced colours and 400% reflow pass on the five key surfaces (evidence shared with AC-ALL-07).	Every release with UI	A, E	UX-06; review AC-19	PROPOSAL

3. UI standard for new and updated screens (Material 3)

Chris, 3 October 2026: UI design must be consistent and modern, and every new and updated UI screen uses Material 3 (UI1). SyRF's Material 3 programme (FEAT-023, docs/features/material-3-migration/) moves the whole application to Material 3 component themes in one atomic cutover (its Wave 5) and forbids mixing component generations in a session. Until that cutover, the application emits Material 2 component themes with Material 3 system tokens alongside (src/services/web/src/global-styles/syrf-theme.scss). So UI1 means, for now, Material 3 roles and public component APIs over today's components, with no Material 3 component islands, and every new route registered for the cutover baselines. That reading is put to Chris as D3-01. themeToggle is off by default (src/charts/syrf-common/env-mapping.yaml) but on in staging (cluster-gitops/syrf/environments/staging/web/values.yaml, themeToggle: true), so dark-mode evidence is gathered on staging once per release. The UX strategy may refine the wording of these rows; their IDs stay.

ID	Criterion	Gate	Verified by	Source	Status
UI-1	Colour, typography and shape come only from Material 3 system roles emitted by mat.theme() (--mat-sys-*) or documented --syrf-* brand or domain roles. No Material 2 Sass APIs, Bootstrap classes or private Angular Material internals; pnpm run check:theme-migration, pnpm run check:contrast and the theme guard spec pass.	M	U	UI1	confirmed
UI-2	Screens use Angular Material components and SyRF's shared components through their supported theming: app-page-shell and app-page-state on every new admin page, StatusView chips for statuses, the section shell, navigation patterns and overlay scroll. A new pattern is specified once in the pattern inventory (states, tokens, keyboard model, narrow behaviour, copy keys) and built as a shared component; a new shared token goes through FEAT-023's serial theme-contract change.	A	V, U	UI1; review AC-28; UX-07, UX-16	PROPOSAL
UI-3	New screens use only --mat-sys-* and --syrf-* roles and public component APIs and add no Material 3 component theme or component island, so a session never mixes component generations; check:theme-migration passes. Evidence is the path the preview environment renders plus the token checks, not a second rendering path.	M	U	UI1; review AC-17; UX-12; D3-01	pending-D3-01
UI-4	Correct in light and dark: check:contrast passes for both compiled themes (WCAG AA text, 3:1 for meaningful control and graph boundaries); status is never shown by colour alone; dark screenshots of new screens are captured once per release on staging, where themeToggle is on.	M (token checks); A (dark screenshots)	U, V, A	UI1; review AC-27; UX-12	PROPOSAL
UI-5	Consistent with the SyRF design system: the navigation drawer handoff (docs/features/material-3-migration/handoffs/project-navigation-drawer/README.md) and its Material 3 Expressive patterns, FEAT-023's adaptive section hierarchy, typography, density and spacing scale and its long-running-job visual language; one button and type language (Material 3 sentence case).	A	V	UI1; review AC-28; UX-07; D3-04	pending-D3-04
UI-6	Works without page-level horizontal scrolling at every viewport in the width matrix (§3.1); wide tables and candidate comparisons use labelled contained scrolling or cards; touch targets are at least 44 px below 600 px; title and abstract screening works on a 390 px phone with the on-screen keyboard hidden (the phone clause is pending D3-05).	A	E, V	UI1; review AC-19; V2-22; UX-15; D3-05	PROPOSAL, pending-D3-05
UI-7	Every new component has designed hover, focus-visible, pressed, selected, disabled, error, loading and empty states, listed in its pattern spec. The PR includes the screenshot matrix for each new or changed screen: light theme at the §3.1 widths and named states, captured by the L17 screenshot tool; dark follows UI-4 (token checks per PR, a staging dark set per release).	M	V	UI1; UX-12; UX strategy	PROPOSAL
UI-8	A prototype or UI validation passes its pass bar (§5.4) before the build. A screen is "materially changed" when it gains a new route, a new shared pattern, a changed layout or primary action, or changed copy for a core verb. Chris accepts once per release in a staging walkthrough; per-PR preview acceptance applies only to new shared patterns and five high-risk surfaces (the publication dialog, the reconciliation workspace, the stage designer, Members & groups, guided setup).	A	V, G	UI1; A-24; review AC-28; UX-13; D3-02	pending-D3-02
UI-9	New and changed routes are added to FEAT-023's route matrix (one owner per route group) and to its visual baselines.	M	G, V	UI1; review AC-17	PROPOSAL
UI-10	No literal colours and no var(--role, #fallback) in new feature styles or templates, enforced by a guard spec over the programme's folders modelled on the existing repository guard specs.	M	U	UI1; review AC-27	PROPOSAL
UI-11	Copy comes from the copy deck as typed message constants per feature (guard spec), and the user-guide glossary changes in the same PR. Confirmed terms (Q-13): "Design", "question templates", "Library" only for Study Management. Recommended verbs (D3-03): "Save progress", "Complete", autosave "Changes kept, not yet saved", "Needs updating", "Outdated answers", "Fix", "Accepted answers (gold standard)", "Screening result".	M	U, D	Q-13; C17; UX-05; D3-03	pending-D3-03

3.1 Width matrix

Widths come from src/services/web/src/app/shared/layout/break-points.ts (edges at 599.98, 904.98, 1239.98 and 1439.98 px), the smallest supported phone, the v10 reviewer-workspace check and FEAT-023's zoom rows. UI-6 and UI-7 use this list; the UX strategy owns it.

Viewport (CSS px)	Why
320	Smallest supported width; the 400% reflow equivalent
390	Phone; title and abstract screening (pending D3-05)
599 and 600	lt_sm and sm edge (table-to-card threshold)
768	Tablet portrait
904 and 905	sm and md edge
925	The v10 and Review Prototype v4 narrow annotation-panel check
1239 and 1240	lt_lg and lg edge (rail compact threshold)
1439 and 1440	lg and xl edge; the design reference width
1280 at 200% and 400% zoom	WCAG reflow (640 and 320 CSS px)
1280 × 600	Short height: action bars and summaries stay reachable

The reviewer and reconciler workspaces are also checked with the rail collapsed and with the source panel open, because their content threshold (980 px of remaining width) is content-driven.

4. Release criteria

Each section gives the release's tier (§8.3), its freeze gates, fixtures and seeds, then its criteria, its conformance row and a one-line change log against the previous version. Release names follow the integrated plan; S0 is new, and X1 (§4.36) applies only if Chris approves D4-09. Rows are activation criteria unless they say M. "C1-T01" style IDs are the conformance tests in §7.5; a CONF row also requires every earlier release's conformance tests to keep passing.

4.1 S0 Programme scaffolding (new release)

Tier T3 · no runtime behaviour, everything behind default-off programme flags · needed by M0, R0 and R1b · source: DS-08, DS-09, delivery operating model.

ID	Criterion	Verified by	Source	Status
AC-S0-01	Programme flags are registered once in env-mapping.yaml (default off) and the canonical module skeleton (new controllers, services and an explicit DI module, all in new files) builds; with the flags off the existing flags-off spec set passes unchanged.	U, I, E	DS-08, DS-09	PROPOSAL
AC-S0-02	The fixture corpus exists as versioned JSON under src/libs/testing/SyRF.Testing.Common/ with a schema check (§7.1); xUnit theories and Vitest describe.each read the same files; FX-PRISMA-01 to 08 inputs and their per-release assertion files exist (assertions for releases not yet built may be empty and are reported as empty).	U, C	review AC-04, AC-31; DS-08; E99	PROPOSAL
AC-S0-03	A baseline benchmark arm on FEAT-024's environment-gated pattern (src/libs/project-management/SyRF.ProjectManagement.Mongo.Data.Tests/ProjectStatistics/BenchmarkEnvironment.cs) measures today's session submit and screening save on RV-DS-01 to 03 on Bramble and stores the report with commit, dataset and host.	B	DS-08, DS-12; MS-12; review AC-18; E98	PROPOSAL
AC-S0-04	The traceability file and check (§9) run in docs CI: the check fails when a non-meta ledger or §1.11 ID has no criterion, a criterion row lacks a Source or Status, or a test tag names an unknown ID.	U, G	AC1; review AC-01; E94	PROPOSAL
AC-S0-05	The L17 tooling needed by M0, R0 and R1b passes its self-tests: the persona set (§6.2) in e2e/setup/auth.setup.ts and the seed constants; axe and screenshot helpers usable inside journey specs; the barrier-injection harness on MongoDbReplicaSetTestFixture; the mixed-version harness skeleton; the excluded-spec check script (AC-ALL-15).	U, I, E	review AC-09, AC-10, AC-12; UX-06; E95, E96	PROPOSAL
AC-S0-06	The seed-if-absent job is additive and idempotent, keyed by fixed GUIDs, and runs on preview (/reseed-db) and staging separately from ownership reconciliation; it never drops or edits an existing document, and a second run creates nothing.	I, R	review AC-11; V2-09; E97; D3-14	pending-D3-14
AC-S0-07	The STATUS ledger, the release-brief and slice-brief templates and a programme section in the PR template exist.	D, G	DS-07; delivery operating model	PROPOSAL
AC-S0-CONF	Not applicable: S0 has no contract code. The harness self-tests in AC-S0-02 and AC-S0-05 stand in.	U	review AC-01	PROPOSAL

Changes: new release; AC-S0-01 to 07 are new.

4.2 M0 Engine proof walking skeleton

Milestone, not a release; T1 evidence rules (supervised review, Bramble runs) with a go/no-go record instead of activation · gates F1a · fixtures FX-APPLIC, FX-DRAFT, RV-DS-01 to 03 and the max-form case.

ID	Criterion	Verified by	Source	Status
AC-M0-01	Research cases A1, A3, A7, A8, A11, A13, A14 and A20 to A23 pass on synthetic fixtures for both OrdinaryAnswer and ScreeningDecision, through one logical repository and commit engine (C1-T01 to T11); A13 and A14 run on synthetic claims here and again as journeys in R2a and R2b.	C	Research §7.4; DC-16; review AC-35; consistency model	PROPOSAL
AC-M0-02	The storage ADR records measured document size, transaction duration, write conflicts and command counts on RV-DS-01 to 03 and the max-form case, and the go/no-go thresholds hold: the C18-T02 write gate (zero engine-caused exhausted submissions at 1, 2, 5 and 10 reviewers, same and different study); p95 per tier against the S0 baseline; transaction duration p99 ≤ 2 s and maximum ≤ 10 s (PROPOSAL); the Study document at most 50% of 16 MiB at the max tier (PROPOSAL). A Project-document contention arm (a grant change racing a running embedded bulk job) records conflicts and retries.	B, G	DC-16; PH-01; VB-12; DS-08; DD-16; D1-08	confirmed
AC-M0-03	The writer and reader inventory lists every path in migration §1 with a route, refuse or adapt decision reviewed by its owning programme, including tracking writers and readers, the #3945 and #3947 Study writers, every UpdateMany on pmStudy, and the bulk PDF, ADR-020 bulk-update and M5b risk-of-bias stores.	G	Research A27; RT-08; NS-08; VB-07; V2-15	PROPOSAL
AC-M0-04	The FEAT-024, presence and allocation owners' checklists pass for the C7 identity amendments, the membership-facts projection first (each run by a fresh-context agent; Chris rules on exceptions); the C10 catalogue audit is complete; the QM v2 harvest is executed with a harvest-and-avoid table that excludes destructive rollback, hand-back to legacy and unbounded embedded version arrays. Only the Q-08 decision (harvest the dormant QM v2 stack rather than revive it) is confirmed; the rest of this row is a PROPOSAL.	G	Q-08; AP-01; VB-17; delivery operating model §2.5	PROPOSAL
AC-M0-05	Walking skeleton: one form travels engine → CAS → Study.CanonicalSummary through FEAT-024's source-write seam (projection-only shape; the engine writes no statistics or pending entries) → draft → dark AF2 adapter → current and previous-version export, on synthetic data. The spike code may be discarded; its conformance suite, fakes and ADRs merge.	C, I	DS-08; MS-06; programme integration	PROPOSAL
AC-M0-06	On the skeleton, C18-T01, T03 and T04 pass: fault injection at every write step leaves no readable partial state and a retry returns the original result; the command ledger resolves duplicates; a forced UnknownTransactionCommitResult and a primary failover produce no duplicate version or notice.	I	DC-16 (AC-DC-01, 03, 04)	PROPOSAL
AC-M0-07	The F1a ADRs record, from M0 evidence: no per-project document in interactive commits, with ordering by Study version within a study and by hybrid logical clock across a project (E25); the transaction-admission rules (C18); and the choice between Study.CanonicalSummary and legacy-shaped stub sessions.	G	Consistency model; DC-01; MS-12	PROPOSAL
AC-M0-08	Architecture fitness tests run in the F1a conformance suite and fail the build on a violation: a reflection-based dependency test asserts the context map's allowed dependencies, no internal type used across bounded contexts, and the hosting rule (canonical command handlers only in ProjectManagement.Application; no policy service with a repository dependency); the source-scanning ownership test (AC-R0-08) and the append-only repository test (C1-T16) belong to the same suite.	U	DD-22; E58; domain model	PROPOSAL
AC-M0-CONF	C1-T01 to T14; C18-T01 to T04 and C18-T11.	C	review AC-01	PROPOSAL

Changes: AC-M0-01 to 04 rewritten; AC-M0-05 to 08 new.

4.3 R0 Compatibility floor and project admission

Tier T1 (staging rehearsal) · freeze F1a · fixtures FX-FLOOR, FX-LEGACY, FX-ELIG · seeds: none new.

ID	Criterion	Verified by	Source	Status
AC-R0-01	Given documents with canonical fields at Study, Project and SystematicSearch top level and on every embedded type the R0 ADR enumerates, when the recorded minimum rollback image (R0 or later) reads, updates and writes them through its normal paths, then nothing throws and no field is dropped; extended types capture unknown elements and never only ignore them.	I, H, R	VB-02; DC-18; review AC-13; V2-21	PROPOSAL
AC-R0-02	Given a CanonicalScopes marker for a scope on a Study or Project, every legacy writer in the inventory refuses writes to that scope with a typed conflict and leaves the document unchanged, with one test per writer. The writers include tracking writers (hub join, leave, dirty, disconnect and prior-study release; the PM idle, suspension and liveness consumers; claim pipelines; typed admission; the direct-navigation claim; screened-reservation release; "Apply anyway" revocation; reservation restore), #3944 conversations, the #3945 bibliographic and #3947 PDF writers, the inclusion recalculation, bulk PDF finalisation, preview seeding and import-failure compensation.	I	DC-04; VB-07; DS-10; RT-08; NS-08; consistency model	PROPOSAL
AC-R0-03	Removing a project from admission, or reverting configuration, changes neither its CanonicalScopes markers nor its pmCanonicalOwnership record; legacy writers still refuse; the registry reconciliation check reports agreement.	I	C16; A-22	assumption-A-22
AC-R0-04	The admission service gives the API and the web the same answer for the same project; an audited admin action admits or removes a project; new projects follow the configured rule (creator opt-in in production until GA).	I, E	C16; A-23	assumption-A-23
AC-R0-05	A staging image rollback to the recorded minimum image, in a promotion-pause window with canonical fixture data present, passes AC-R0-01, 02, 03, 06 and 09.	R	C16; DS-11	PROPOSAL
AC-R0-06	The minimum rollback image loads a Study, Project or SystematicSearch carrying unknown elements on each type the ADR enumerates, including schema-conditional branches (ADR-011's RandomId and GraphId), edits an unrelated field, writes through its normal replace path, and every unknown element survives.	I, H	review AC-13; VB-02	PROPOSAL
AC-R0-07	Floor steps before R2b (form claims counted per bound stage), R3a (screening aggregates), P1 (Study root fields) and C1 or O1 (if they add embedded fields) rerun AC-R0-01, 05, 06 and 09 for their newly extended types; each release ADR records its floor step and minimum image.	I, H, R	review AC-13; DC-02	PROPOSAL
AC-R0-08	Writer census: an architecture test extending StudyWriteLockArchitectureTests fails the build when any path writes pmStudy or pmProject without the registered ownership guard in its write filter, and every UpdateMany on pmStudy is in the inventory with a decision.	U, I	Research A27; review AC-13; DC-04; VB-07; DS-10	PROPOSAL
AC-R0-09	Behavioural floor: with R0 and R2a binaries alternating writes on one Study (legacy screening saves, claim writes, fold removals, canonical commits), every persisted computed field (ExtractionInfo.SessionTallies, the SessionTally totals, the ScreeningInfo inclusion and agreement fields) equals an authoritative recount that includes Study.CanonicalSummary; with no summary present, R0 behaves exactly as before.	I, H, R	DC-02; VB-01; RT-06, RT-07; AP-01; consistency model	PROPOSAL
AC-R0-10	Through the IReviewMembershipFacts seam's embedded-data provider, every row of the eligibility truth table gives the same admission, pool, allocation-exemption and D8 slot answer as today's predicates.	C	AP-01; consistency model	PROPOSAL
AC-R0-11	A legacy writer, transactional or not, racing a marker sweep or cutover never commits after the marker; the barrier harness forces the interleaving and the loser gets the typed conflict.	I	DC-04 (AC-DC-07)	PROPOSAL
AC-R0-12	The admission service refuses to admit a project that runs FEAT-024 in transactional point mode, and refuses that mode for an admitted project.	I	DC-21; programme integration	PROPOSAL
AC-R0-13	Project admission and FEAT-024's statistics allowlist stay independent: changing one never changes the other.	I	MS-24	PROPOSAL
AC-R0-14	No new pmStudy index is built at service start-up; each is built through the operator route with commit quorum and recorded per environment.	I, G	VB-18; consistency model (C18)	PROPOSAL
AC-R0-15	Canonical commands refuse, before any write and with a typed read-only notice, while any registered API or PM instance runs an image below the canonical writer floor; the floor reuses the existing service version floor (src/libs/mongo/SyRF.Mongo.Common/ServiceVersionFloor.cs, which fails closed unless every instance is at the minimum) and ADR-019's storage-version tripwire; once every instance is at or above the floor, commands proceed without a restart.	I, H	PH-29; DS-10; consistency model	PROPOSAL
AC-R0-16	PM can capture notification occurrences inline: an operation, sweep or time-driven transition hosted in PM that commits a notice-producing change captures the occurrence in the same transaction, reading the same notification flags or admission record as the API.	I	DD-04; E59; NS-01; domain model	PROPOSAL
AC-R0-CONF	C16-T01 to T08; C7-T01 (embedded provider).	C	review AC-01	PROPOSAL

Changes: AC-R0-01, 02, 03 and 05 rewritten; AC-R0-06 to 16 new.

4.4 R1a Question templates and import

Tier T2 · freeze G0 · fixtures FX-SETUP-02 to 04 · seeds: existing.

ID	Criterion	Verified by	Source	Status
AC-R1a-01	An import preview lists every question, parent remap and lookup remap exactly as the apply then produces them (preview and apply are equal on fixtures).	I	Plan R1a; FX-SETUP-03	PROPOSAL
AC-R1a-02	Cross-project references in a template are refused with a message naming them, and nothing is created.	I	Plan R1a; FX-SETUP-04	PROPOSAL
AC-R1a-03	A failure during apply leaves no partial questions.	I	Plan R1a	PROPOSAL
AC-R1a-04	The import flow never deletes or edits existing questions.	I	Plan R1a	PROPOSAL
AC-R1a-05	Question templates can be browsed, previewed and copied into a project; copies don't change when the template changes.	I, E	SET1; FX-SETUP-02	confirmed
AC-R1a-06	Filtered-options authoring in the new editor gives the same stored result as the legacy editor on fixtures.	I, E	Plan R1a	PROPOSAL
AC-R1a-07	The 17 question-management specs excluded in angular.json and the question-management/** exclusion in vitest.config.ts are both removed; the specs run in CI and pass; the "Focused question" debug text is gone.	U	RULE; review AC-15	confirmed
AC-R1a-08	Template copies record their source template and version where older binaries keep it (a DefinitionTemplate record, or a Project top-level field preserved by Entity extra elements); an older binary that replaces the Project keeps it.	I, H	V2-16	PROPOSAL
AC-R1a-09	If approved, the template catalogue includes SYRCLE risk-of-bias, CAMARADES checklist and ARRIVE templates with per-outcome items, curated by CAMARADES methodologists; their copies stay independent.	I, E	SR (templates); D4-06	pending-D4-06
AC-R1a-10	Template ownership: a CAMARADES-curated system catalogue (application role) plus copying from projects the user administers; copies only, never links.	I	V2-16; D2-15	pending-D2-15
AC-R1a-11	If approved, the SYRCLE template binds items 6 to 8 to the outcome-assessment entity so they are answered per outcome, and the export gives a domain × study (and domain × outcome) judgement matrix.	I, C	SR-05; methodology coverage	pending-D4-06
AC-R1a-12	Reordering in the question tree and editor uses pointer-based CDK drag with a keyboard alternative (no native HTML5 drag events, enforced by a guard spec); it works with touch on iPad Safari and passes the Firefox and WebKit smoke journeys.	X, E, U	PH-13; review AC-19; UX strategy (E85); D3-15	pending-D3-15
AC-R1a-CONF	C4-T04 (question templates).	C	review AC-01	PROPOSAL

Changes: AC-R1a-07 rewritten; AC-R1a-08 to 12 new.

4.5 R1b Members and groups visibility and owner-only enforcement

Tier T2 (authorization: supervised review) · entry: the security fix (#3964, merged on 3 October 2026, merge commit 85e6facf7; kept under D1-01) · fixtures FX-PERM · seeds: personas owner and admin-not-owner.

ID	Criterion	Verified by	Source	Status
AC-R1b-01	A project administrator who isn't the owner gets 403 when trying to change the owner, and no field of that request is applied.	I	SEC1; PM1; D1-01 (decided: keep #3964)	confirmed
AC-R1b-02	The current owner can still transfer ownership to another project member.	I, E	PM1	confirmed
AC-R1b-03	Project and stage permission updates that include ChangeOwner, AssignPermissions or Delete are refused with an error naming the activity, and nothing changes.	I	SEC1	confirmed
AC-R1b-04	The Members & groups page shows every group, member and project or stage grant exactly as the server enforces them (contract test against the active decision path).	I, E	PM1	confirmed
AC-R1b-05	Only the owner sees the transfer control; owner-reserved activities never appear as grantable; the component specs run (AC-ALL-15).	U, E	PM1; SEC1	confirmed
AC-R1b-06	The members route guard uses the correct permission key: a user without EditMemberships can't reach the editor route, and one with it can.	U	Plan R1b (authorization WP1d)	PROPOSAL
AC-R1b-07	UI copy and the user guide describe ownership transfer as owner-only.	D	SEC1	confirmed
AC-R1b-08	Each "why can or can't I" explanation equals the enforcement decision.	I	PM1; X-AUTH-WP9; review AC-34	conditional-X-AUTH-WP9
AC-R1b-09	Transferring ownership to a non-member is refused, and the former owner loses owner-reserved activities on their next request.	I	SEC1; PM1; D1-01	confirmed
AC-R1b-CONF	C10-T01, C10-T04, C10-T07.	C	review AC-01	PROPOSAL

Changes: AC-R1b-08 made conditional; AC-R1b-09 new.

4.6 R1c Configurable groups and the permissions dialog

Tier T2 (authorization: supervised) · entry: X-AUTH-SCHEMA, X-AUTH-ENFORCE or parity tests, X-AUTH-WP9, Q-03a, Q-09 · fixtures FX-PERM.

ID	Criterion	Verified by	Source	Status
AC-R1c-01	A user with EditMemberships can create, rename and delete a group and assign members; others are refused.	I, E	PM1; Q-03a	confirmed
AC-R1c-02	An editor can't add themselves or anyone else to a group whose grants exceed what the editor may administer (matrix of editor and group grants in FX-PERM).	I	Q-03a	confirmed
AC-R1c-03	ChangeOwner is never grantable to a group; AssignPermissions is grantable only through R1d's envelope.	I	Q-03a; PM1; PM2	confirmed
AC-R1c-04	Group edits that change effective Review or Reconcile grants produce access notices through the existing capture, reading grants through the active decision path (parity test), within bulk fan-out limits, and through no other path.	I	C15; NS-09	conditional-X-NOTIF
AC-R1c-05	Group grants decide identically in the legacy and evaluator paths (parity tests), or the enforced evaluator is active in that environment.	I	A-17	assumption-A-17
AC-R1c-06	Every change is audited in authorizationAudit with actor and before and after values.	I	C10	PROPOSAL
AC-R1c-07	The generalised dialog covers every project and stage activity except owner-reserved ones; the mock stage-permissions page and stagePermissionsConfigurable are gone.	E	Plan R1c (WP11)	PROPOSAL
AC-R1c-08	Delete stays owner-only: it is never grantable to a group.	I	Q-03a ("Delete follows Q-03"); permission-matrix proposal; Q-03 (approved as recommended, 3 October)	confirmed
AC-R1c-09	Holding a grant never lets a user assign it: across the FX-PERM matrix, a grant holder without AssignPermissions is refused when assigning that grant.	I	PM1 (invariant 10); V2-24	confirmed
AC-R1c-10	Revoking a reviewer's Review grant, directly or by a group change, releases their temporary claims through the claim-revocation outbox within one dispatcher cycle; drafts and saved work stay.	I	RT-20	PROPOSAL
AC-R1c-11	Study-issue and PDF-correction recipients and deciders are expanded by capability ("receive and resolve study issues", "approve PDF corrections"), so a custom group holding them receives reports.	I	NS-20	PROPOSAL
AC-R1c-12	#2224's API shape and tests are harvested into R1c, and #2224 is closed with a harvest note.	G, I	Q-09	confirmed
AC-R1c-CONF	C10-T02, C10-T07, C10-T09.	C	review AC-01	PROPOSAL

Changes: AC-R1c-03 and 04 rewritten (Delete moved to AC-R1c-08); AC-R1c-08 to 12 new.

4.7 R1d Delegated permission administration

Tier T2 (supervised) · entry: R1c, Q-03 · fixtures FX-PERM.

ID	Criterion	Verified by	Source	Status
AC-R1d-01	The owner can grant permission administration to a group within an envelope listing the activities it may assign.	I, E	PM2	confirmed
AC-R1d-02	A delegated administrator can assign only activities inside the envelope, and never ChangeOwner.	I	PM1; PM2	confirmed
AC-R1d-03	Revoking the delegation stops further assignments at once; assignments already made remain and are listed for review.	I	PM2	PROPOSAL
AC-R1d-04	Every delegated assignment is audited with the delegating owner and the delegate.	I	PM2; C10	PROPOSAL
AC-R1d-05	Delegation is non-recursive: a delegate can't grant the delegation itself.	I	PM2 (recommendation); Q-03 (approved as recommended, 3 October); V2-05	confirmed
AC-R1d-CONF	C10-T03.	C	review AC-01	PROPOSAL

Changes: AC-R1d-02 rewritten (non-recursion moved to AC-R1d-05); AC-R1d-05 new.

4.8 R2a Versioned forms and immutable sessions (one stage per form)

Tier T1 (staging rehearsal) · freezes F1a (engine), F1b (export disclosure), F1c (UI seams, copy, Dockview) · entry: R0's staging rehearsal passed (production pilots need R0's production soak); #3985 and #3973 merged (D1-02) · fixtures FX-PRISMA-02a, FX-PRISMA-04a, FX-APPLIC, FX-DRAFT-01 to 08, FX-CLAIMS, FX-LEGACY, FX-FLOOR, RV-DS-01 to 03 · seeds: Versioned forms, one stage; Realistic content.

ID	Criterion	Verified by	Source	Status
AC-R2a-01	Autosave keeps a draft and leaves the session's status, current explicit version and qualification unchanged.	I	SL1; SL3	confirmed
AC-R2a-02	Save creates an immutable incomplete version that becomes current; a Save after Complete removes the completed qualification.	I, C	SL2; SL3	confirmed
AC-R2a-03	Complete checks required applicable answers on the server and creates an immutable completed version that counts once; the shared applicability corpus FX-APPLIC passes in both the .NET validator and AF2.	C, U	SL2; UA1; E23	confirmed
AC-R2a-04	A question hidden by a condition is never required; a missing required applicable answer is refused with a typed error naming the question and its context.	C, E	UA1; SL2	confirmed
AC-R2a-05	Every earlier version stays readable in the history panel and in previous-version exports, with version identifiers.	I, E	SL2; EX1	confirmed
AC-R2a-06	Two tabs or devices on one session: the second is read-only with "Take over editing"; taking over moves the lease; the other tab's unsaved edits are kept as a bounded conflict copy the reviewer can open, copy or discard (discard audited); the lease uses a stable client tab ID and works with tracking off.	I, E	DC-07; VA-12; RT-10; V2-18; review AC-14; consistency model; D2-08	pending-D2-08
AC-R2a-07	Each canonical command writes exactly one command-bearing record with a unique (ProjectId, CommandId) and a request digest. A retry with the same ID and digest returns the original result and writes nothing, including with the fold on before the fold runs; a different digest returns the typed digest-mismatch 409; a stale base returns a typed conflict that keeps the draft; an indeterminate commit returns the typed "outcome unknown", the draft is kept, and a retry with the same ID resolves through the ledger.	C, I	Consistency model; DC-03; VB-04; MS-05	PROPOSAL
AC-R2a-08	Drafts are never shown to reconcilers or included in exports.	I	SL1; SF4	confirmed
AC-R2a-09	A canonical session can't be hard-deleted. "Remove all annotations" on a session with an explicit version creates a versioned clear (an incomplete version with no answers, history kept); on a draft-only session it discards the draft (audited). Withdrawal is append-only: the session stops counting and its revisions stay readable.	I, E	C5; review AC-34	PROPOSAL
AC-R2a-10	A question referenced by any published form or profile version can never be permanently deleted by any path, including the legacy delete cascade; it can be retired or left out of a later form version.	I	QD1; VA-15; VB-11	confirmed
AC-R2a-11	Legacy reconciliation, reconciled-answer writes, session removal and question deletion refuse canonical scopes and change nothing.	I	C16; GS1	PROPOSAL
AC-R2a-12	Legacy readers (pool filters, capacity guards, reconciliation readiness, statistics, exports) return correct values for canonical sessions through Study.CanonicalSummary (per-form membership facts with per-reviewer markers, per-bound-stage tallies); every study-scoped canonical command writes that Study in the same transaction (version bump and summary) and conflicts with a concurrent bulk-update lock.	I	Consistency model; DC-02; AP-01; RT-06; MS-13	PROPOSAL
AC-R2a-13	A support edit-mode write records the real actor, is flagged, and is excluded from independence statistics.	I	C1	PROPOSAL
AC-R2a-14	A form requirement version in use can't change. "In use" means referenced by any FormSession (including draft-only), any ReconciliationTask, or an Active stage settings version's binding; a draft-only session created against a version that is then edited gets a typed stale-definition conflict (research A16). A draft form can be edited until first use.	I	FV1; A-14; VA-07, VA-13	assumption-A-14
AC-R2a-15	Canonical forms refuse quantitative extraction until O1, with an explanation.	I	Plan R2a	PROPOSAL
AC-R2a-16	Unmasking in exports follows the export disclosure contract: only authorised users can unmask, every unmasking is audited, and candidates and gold stay separate for exporters who aren't reconcilers.	I, E	C10; U26	PROPOSAL
AC-R2a-17	Legacy screening writes in admitted projects are captured inside the aggregate (a bounded capture entry on the Study in the same document write, moved idempotently to pmLegacyWriteLedger by a leased worker), with one test per writer: interactive submit (both paths), administrative screening, reference-file screening columns (both parsers), the bulk-update planner and seeding. Each committed change produces exactly one entry; overflow is recorded as a coverage gap.	I	E26; DC-14; VB-14	PROPOSAL
AC-R2a-18	FX-PRISMA-02a and FX-PRISMA-04a assertions pass: one qualifying contribution per reviewer per study per form; a Save after Complete removes it; autosave alone does not.	C	SF2; SL3; review AC-04; V2-07	confirmed
AC-R2a-19	The canonical write gate (AC-ALL-26) holds for Save and Complete at the typical, p99 and max tiers (50, 340 and 2,023 questions), with E28 expressed in pins and bytes.	B	D1-08; DC-16; PH-01; VB-12; review AC-18	confirmed
AC-R2a-20	Every canonical record carries a hybrid logical clock stamp and its per-aggregate version; within a study, commit order equals Study version order; no interactive commit writes a per-project document (architecture test).	C, U	Consistency model; DC-01, DC-13; MS-12; PH-01	PROPOSAL
AC-R2a-21	Natural-key aggregates get deterministic name-based IDs (FormSession, AnnotationHead through its key hash, ScreeningOutcome, StudyGold, ReconciliationTask, CanonicalOwnership); client-proposed IDs for revisions and entity instances are validated (unused, same project); a client ID that belongs to another scope is refused before any mutation.	I	E27; research A5; VB-16	PROPOSAL
AC-R2a-22	Publishing a form version or committing a session version above the E28 ceiling (pins per session version, changed revisions per commit, BSON bytes per commit) is refused before any write with the typed "size limit exceeded"; the ceiling starts below the largest project's 2,023 questions until benchmarks prove larger forms safe.	I, B	E28; VB-12; D2-16	pending-D2-16
AC-R2a-23	System questions are stored as versioned data with (GUID, SystemQuestionVersion) identity: a later code change doesn't alter a published form version's pinned snapshot (form, validation, export); the v0 and v1 structural variants pin different identities; deploying a new system version changes no published form and prompts no admin.	C	E24; VA-09; VB-11; D2-06	pending-D2-06
AC-R2a-24	Composed form versions include every ancestor automatically; removing an ancestor while a descendant remains is refused; composing a version whose pinned child has a condition or parent filter on an option absent from the pinned parent version is refused, naming the question.	U, I	QM-09; C4; VA-06	PROPOSAL
AC-R2a-25	Binding a form version to a second stage is refused with an explanation until R2b.	I	A-21	assumption-A-21
AC-R2a-26	Each revision records source stage, step, stage-settings version, question version and real actor, unchanged on reuse; each session version records route stage, form version and the revisions submitted together (C5-T09 checks that this is the full pin map).	C	PV1; VA-22	confirmed
AC-R2a-27	Presentation state such as entity order lives outside immutable versions: an order-only change creates no version, doesn't remove Complete, doesn't compare-and-set the session head and doesn't appear in exports.	C	C5; VB-08	PROPOSAL
AC-R2a-28	A draft edit persists within the debounce window (PROPOSAL 2 s) and survives reload, tab close and a second device; a draft-changes indicator over the current explicit version is shown and announced.	E, A	SL1; SL3; review AC-14	confirmed
AC-R2a-29	A point-in-time restore of the whole database into an isolated database passes the consistency checker (versions, drafts, ledger records, summaries agree), writes a history-discontinuity record for each affected project, and reconciles scheduled MassTransit and Quartz state from MongoDB state.	R	E31; DC-17; VB-20; D2-13	pending-D2-13
AC-R2a-30	Deleting a reviewer's account anonymises the Investigator record; revisions, drafts, exposure events, ledger records, presence and connection records and inbox items hold only opaque GUIDs (schema check); AC-ALL-21 still passes.	I	E32; VB-19; RT-21; NS-21; D2-14	pending-D2-14
AC-R2a-31	Canonical sufficiency uses the form target; the per-stage override (#3732) has no effect on canonical forms.	I	SF2	confirmed
AC-R2a-32	A committed question version that no published form or profile version references, and a never-published draft question, may be deleted; retiring a published question blocks new use.	I	VA-15; QD1	PROPOSAL
AC-R2a-33	Operational form settings (target, compare settings, gold completeness, guidance) change with audit history and never start a publication or impact flow.	I	VA-07; D2-05	pending-D2-05
AC-R2a-34	Two forms can't both use one entity category until R2d; the refusal explains why.	I	A-19	assumption-A-19
AC-R2a-35	A reviewer whose only session is canonical (a draft with a claim, saved incomplete, or completed) is always admitted to it by Next, direct access and join, even at target with enforcement on; another reviewer is refused AtCapacity. Runs in both tracking modes.	I	RT-05	PROPOSAL
AC-R2a-36	The first explicit Save or Complete releases the claim and replaces presence exactly once inside the canonical transaction; twelve concurrent first saves from two tabs leave one session, no claim and one post-save presence; autosave never writes Study (pinned command counts).	I, C	RT-05, RT-15	PROPOSAL
AC-R2a-37	A draft keeps the reviewer's place while they are active, under today's idle and disconnect timers counting draft activity; when the timers lapse the place is released and the draft kept; the reviewer can still Complete it as an extra contribution unless an optional capacity cap applies, in which case they are told so and may keep or discard the draft.	I, E	RT-09; PH-03; consistency model; D2-07	pending-D2-07
AC-R2a-38	Every published canonical form version passes AF2's structural guards at publication (server-side, shared fixtures); a version AF2 can't render is refused; canonical routes never fall back to AF1 and show a typed error visible to admins.	C, E	VB-08	PROPOSAL
AC-R2a-39	Entity instances: deleting a unit is a set of withdrawal revisions on its label head and descendants in one commit; renaming keeps its identity; duplicating mints new instance IDs with copiedFrom provenance.	C	VB-09	PROPOSAL
AC-R2a-40	#3944 conversations refuse canonical scopes through the ownership marker until R4a binds them to the task; existing legacy threads are unaffected.	I	NS-18; NS-05	PROPOSAL
AC-R2a-41	Enabling proportional allocation on a canonical stage is refused with an explanation, until AL1.	I	AP-06; D3-13	pending-D3-13
AC-R2a-42	AF2 and the redesigned stage-review shell can be admitted per project through R0's admission service: an admitted project gets them whatever the environment flag says, a non-admitted project follows the environment flag, and the web reads the same admission answer as the API.	I, E	Q-25; DS-04	confirmed
AC-R2a-43	Exports carry, per answer, the question ID, question version and option ID (values are display), and the compatibility class once D2-02 is answered; previous-version exports are generated per form version.	I	VA-17	PROPOSAL
AC-R2a-44	The integrity checker reports zero findings on the R2a seeds and fixtures and detects an injected dangling reference in a test.	I	VB-11	PROPOSAL
AC-R2a-45	Completed work of members who are later disabled keeps counting; an audited admin action can exclude it.	I	D4-20	pending-D4-20
AC-R2a-46	A network loss during a session loses no edit made before the loss (journey with network throttling); the save-status indicator follows the copy-deck state machine (Saving, Kept, Retrying, Offline (kept on this device), Failed) and never overwrites the server draft silently from a local copy.	E	UX-04; consistency model	PROPOSAL
AC-R2a-CONF	C1-T06 (claim release on first explicit save), C1-T13, T15, T16, T17, T19; C2-T01, T08; C3-T04; C4-T05, T09, T10, T12, T16, T17, T18; C5-T01, T02, T03, T05, T07, T08, T09, T12; C7-T01 (canonical provider), T07, T12; C8-T07; C10-T05, T06; C11-T06; C17-T01, T03, T04, T05; C18-T06, T09, T10; C19-T01, T03, T04.	C	review AC-01	PROPOSAL

Changes: AC-R2a-01, 03, 06, 07, 09, 10, 12, 14, 15, 17, 18 and 19 rewritten; AC-R2a-20 to 46 new (AC-R2a-20 replaces the reviewers' per-project commit sequence with the consistency model's ordering).

4.9 R2b Shared sessions across stages

Tier T2, with a staging rehearsal for its floor step (form claims counted per bound stage) · freeze F1a (claim contract v2, C7 identity) · entry: R2a shipped; target-aware classification (AC-R2b-13) · fixtures FX-PRISMA-02b, FX-CLAIMS, FX-ELIG · seeds: Shared forms, two stages · also applies: AC-T-08.

ID	Criterion	Verified by	Source	Status
AC-R2b-01	With form F (target 2) bound to stages A and B, a reviewer reaches one session from both stages and counts once in each stage's progress.	E	SF1; SF2	confirmed
AC-R2b-02	A session saved through stage A appears in stage B with no double counting in tallies, progress lists, statistics or exports.	I, E	SF1; SF2; OPS1	confirmed
AC-R2b-03	Two tabs through stages A and B hold one claim; closing either keeps it; closing both releases it once; a third reviewer is admitted only then; pool predicates and the D8 slot rule read form-keyed claims.	I	SF1; RT-16; AP §5	PROPOSAL
AC-R2b-04	Proportional shares are refused, with an explanation, for stages whose form is shared.	I	A-09	assumption-A-09
AC-R2b-05	My studies, incomplete studies and the no-work page agree across the bound stages.	E	SF1	confirmed
AC-R2b-06	FX-PRISMA-02b assertions pass: one form in two stages gives one qualifying contribution per reviewer, counted once in both stages' progress; repeated pool evaluations and personal batch grants add no screened units.	C	SF2; V2-07	confirmed
AC-R2b-07	Concurrent Complete through stages A and B on one session yields one completed version and one contribution; the loser gets a typed conflict and keeps its draft.	C	SF2; research A22	confirmed
AC-R2b-08	My studies, incomplete studies and the no-work page return identical counts through the API for the bound stages.	I	SF1	confirmed
AC-R2b-09	Twelve concurrent first joins through stages A and B create one claim, and the tallies both stages read are equal.	C	RT-11	PROPOSAL
AC-R2b-10	For a form bound to stages with different tracking settings: 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 incomplete session once; the form is tracked if any bound stage is.	I	RT-12; D3-18	pending-D3-18
AC-R2b-11	Concurrent admissions through two bound stages never exceed the form's capacity cap, or its target when enforcement is on.	I	DC (AC-DC-06)	PROPOSAL
AC-R2b-12	Claims follow the claim contract v2: typed {kind, scope ID, route stage, route step, reserved at, allocation regime}, unique per (study, kind, scope, reviewer) and keyed by form identity, not form version; new hub methods are added instead of new parameters until MinUiVersion moves; old command handlers stay for at least the suspension grace plus the idle timeout; the presence index migrates by create, read both, drop.	I, R	RT-11; programme integration	PROPOSAL
AC-R2b-13	FEAT-024's target-aware annotation classification has landed with its reconciliation plan: the classifier and StudyStats use the form's effective target; after the change, a backfill republishes every family of the pilot project with zero stale scopes and the parity audit matches.	I, R	MS-07; AP-14; MS §7©; programme integration	PROPOSAL
AC-R2b-14	Before any production pilot relies on R2b claim behaviour, X-CLAIMS evidence is recorded: #3876 reshaped into a binding-scope tracking setting enabled per admitted pilot project (or the route Chris chooses), API and PM switched together in one static configuration change, and AC-T-01 to AC-T-07 passed.	G, R	RT-02, RT-03; D3-16	pending-D3-16
AC-R2b-15	A stage binds the form and records which version it bound and when; the live route from any bound stage presents the session's resolved form version; a Completed stage's frozen binding governs only its historical display and readiness.	I, E	PV2; VA-08; D2-04	pending-D2-04
AC-R2b-16	An optional capacity cap, off by default and separate from the form's minimum target: when on it defaults to the target, never limits requested extra reviews and never evicts existing work; with it off, extra completed contributions keep counting.	I	RT-13; SF4; D3-17	pending-D3-17
AC-R2b-CONF	C1-T06, T07; C3-T01; C5-T04; C7-T02, T03, T04, T05, T06, T08, T10.	C	review AC-01	PROPOSAL

Changes: AC-R2b-03 and 06 rewritten; AC-R2b-07 to 16 new.

4.10 R2c Publication with impact

Tier T1 (staging rehearsal) · freeze F2 · entry: R2a shipped; Q-31; FEAT-024's new-family onboarding contract (MS-14) · fixtures FX-PUB, FX-PUB-10K, FX-PRISMA-04b, RV-DS-02 and 03 · seeds: Shared forms, two stages; Versioned forms, one stage.

ID	Criterion	Verified by	Source	Status
AC-R2c-01	Publishing F v2 lists completed, saved-incomplete and draft-only sessions under every prior version and every bound stage, with counts that match authoritative records (draft-only sessions counted from pmSessionDraft at the fence).	I, E	FV2; MS-03	confirmed
AC-R2c-02	The admin's choices are recorded as a policy record. Publication writes no session version and no answer revision (only Q-34 option mapping, if approved, writes policy-derived revisions with provenance, excluded from outdated flags). Each session's effective state (qualifying, needs updating, pinned under an older version, not applicable) is derived on read from its latest explicit version, its pin map, the current published version, the recorded policies and per-answer validity: requireReanswer marks affected answers Needs updating; autoUpdate lets a pinned compatible valid answer satisfy the new requirement; doNothing leaves the session pinned, counting as the admin chose.	I, C	FV2; FV3; RECOVERED transitions; VA-03; versioning model; D2-01	pending-D2-01
AC-R2c-03	Needs updating stays visible beside its question with any reason and guidance and blocks Complete until a valid answer exists; a missing reason warns but doesn't block.	E	VU1–VU3	confirmed
AC-R2c-04	Publication requires current usage evidence at the protected boundary. "Current" means a FEAT-024 read at the fence whose result is Materialized-Fresh or pinned-Authoritative, with its identity (projection revision, source revision, digest) recorded on the operation; missing or stale evidence is never treated as zero; named pilots use Q-31(b) authoritative counting while FEAT-024 is dark.	I	PS1–PS3; Q-31; MS-04; D3-10	pending-D3-10
AC-R2c-05	Every session pinned to a prior version ends in the recorded policy's state: phase 2 is a predicate-driven sweep (pinned version below current, policy not yet applied) repeated until it matches nothing; a Save racing phase 1 (barrier-forced) and a late session whose ID sorts below the sweep cursor are both covered; a Save based on a superseded version is accepted pinned to the version its client declared and is never rebased.	I, C	PS3; DC-06; VB-06; VA-10; consistency model	PROPOSAL
AC-R2c-06	Phase 1 is constant work: fence the form, drain (at least the transaction lifetime plus the sweep interval plus a margin), compare-and-set the AnnotationForm head and write the policy and operation records in one short transaction. Phase-1 time is flat across 1,000, 10,000 and 100,000 sessions; the preview digest is re-checked before phase 1 and the admin re-confirms if it changed; the drain pauses only the form being published (about 90 s at most) and keeps drafts.	B, I	DC-06; VB-06; D2-10	pending-D2-10
AC-R2c-07	Recipients are the affected owners derived from the publication under the chosen policy, with no notice for doNothing; there is one item per recipient per publication through recorded fan-out, with the SourceId derived from the publish operation; the publishing admin gets a completion or stall notice; with every notification flag off, reviewers still see Needs updating in the form.	I, E	C15; NS-01, NS-15; VU1	PROPOSAL
AC-R2c-08	Production publication happens only when X-STATS-b1 to b7 evidence is recorded (R2c production publication waits for FEAT-024 production readiness); for named pilot projects only, authoritative counting under the same protected boundary if gate (b) isn't reached when R2c is otherwise ready (Q-31(b)). Staging pilots need X-STATS-a (PROPOSAL, MS-10).	G	Q-31; MS-01, MS-10	confirmed, PROPOSAL
AC-R2c-09	FX-PRISMA-04b assertions pass: after a publication with sessions in all three categories, qualifying counts per version follow the recorded policy (the snapshot part waits for R5b).	C	FV3; V2-07	confirmed
AC-R2c-10	Killing phase 2 mid-run and resuming it (lease, generation, crash takeover) applies each transition exactly once; qualification follows the recorded policy throughout.	I	E22; VB-06; DC-06; review AC-34	PROPOSAL
AC-R2c-11	Qualifying-contribution counts per version match FX-PUB's expected table for every policy combination; a missing required answer is never declared answered by policy.	C	FV3; RECOVERED transitions	confirmed
AC-R2c-12	"Why it changed" and "What reviewers need to do differently" are stored per version, shown beside affected questions and kept in history; missing guidance never blocks.	I, E	VU2	confirmed
AC-R2c-13	FX-PUB-10K (10,000 sessions across v1 to v3 and two stages, split 60/30/10 completed, saved-incomplete and draft-only, 5% with drafts over explicit versions): phase 1 enumerates nothing, the audit manifest is built after commit and paged, and with the fold on no family is left stale or quarantined after the fold drains (overflow is reported).	B	E22; VB-03; review AC-18	PROPOSAL
AC-R2c-14	One active publication per form (unique partial index): a second publish attempt returns the typed "publication in progress"; policy revisions compare-and-set the policy generation and every sweep batch asserts it.	I	VB-06; D2-11	pending-D2-11
AC-R2c-15	While phase 2 runs, new admissions and reconciliation-readiness transitions for that form pause; reviewers keep saving; the admin sees progress; past a limit (PROPOSAL 30 min) it stops and shows as pending; admission fails closed on a stale projection.	I, E	VB-06; DC-08; D2-10	pending-D2-10
AC-R2c-16	A session pinned to v1 renders v1 after v2 publishes, through the pinned data source; the Needs-updating presenter shows the prior value with v1's options and labels.	E, C	VB-08	PROPOSAL
AC-R2c-17	Preview pilots are exempt from PS1: on preview, publication uses authoritative counting at the protected boundary and the operation records that basis.	I	MS-10; D3-10	pending-D3-10
AC-R2c-18	Added and removed questions appear in the dialog with their own treatments: an added required question offers "count earlier Completes" or "require an answer before counting"; a removed question leaves the requirement while its answers stay in history.	I, E	VA-14; FV1–FV3	PROPOSAL
AC-R2c-19	Lowering a form's target, or switching capacity enforcement on, goes through D6's conflict flow: surplus claims are revoked most recent first through the outbox, and drafts stay.	I	RT-19	PROPOSAL
AC-R2c-20	A Save on a v1-pinned session after v2 is published pins the version its client declared; Upgrade is explicit (from the Needs-updating banner, from Fix, or offered on the next explicit Save), creates a new incomplete version pinned to the current version with the same revision pins, and shows the Needs-updating marks.	I, E	VA-10	PROPOSAL
AC-R2c-21	Compatibility is declared when a question version is committed (system-suggested, admin-confirmed) and is immutable once any answer pins that version; compatibility classes are transitive (three-version chain fixture); a policy revision never changes compatibility.	C	VA-01; versioning model; D2-02	pending-D2-02
AC-R2c-22	Renaming an option's label keeps answers valid; retiring an option, or giving a changed meaning a new option ID, makes affected answers invalid under the new version; conditions and parent filters reference option IDs.	C	VA-05	PROPOSAL
AC-R2c-23	Option mapping is allowed only as an explicit per-option mapping recorded in the policy, applied as policy-derived revisions with provenance (old revisions untouched), and only where an option's meaning is unchanged.	I	Q-34	pending-Q-34
AC-R2c-24	A Save or Complete during an open definition-rewrite or inclusion-recalculation fence is refused or deferred exactly as legacy saves are (typed 503); a publication under the fence never commits a Study write before the fence admits it.	I	MS §7(b)	PROPOSAL
AC-R2c-25	The draft-only count at the fence equals the pmSessionDraft enumeration at the same snapshot, never a materialised row.	I	MS-03; MS §7(f)	PROPOSAL
AC-R2c-26	Changing a question's data type or multiplicity creates an incompatible version of the same question identity; parent and owner scope stay part of identity; lineage and history survive.	C	VA-16; D2-03	pending-D2-03
AC-R2c-27	In the designer, an administrator can view a question's version history with a diff between any two versions, and each question card shows its current version number.	E	QM v2 QM-11, QM-14 (retained)	PROPOSAL
AC-R2c-28	autoUpdate is offered only within a compatibility class and satisfies only answers valid under the new version; a many-to-one option mapping or a changed free-text meaning forces requireReanswer; the publication record stores the administrator's rationale; exports carry qualificationPolicy and answeredUnderVersion per answer.	I, E	SR-16; versioning model	PROPOSAL, pending-D2-02
AC-R2c-CONF	C4-T01, T02, T03, T06, T07, T08, T11, T13, T14, T19; C5-T10; C8-T01 to T06; C18-T05 (publication); C19-T05.	C	review AC-01	PROPOSAL

Changes: AC-R2c-01 to 09 rewritten except 03; AC-R2c-10 to 28 new.

4.11 R2d Overlapping forms, outdated flags, Fix and requirement revision

Tier T2 · freezes F1a (C2), F2 (policy revision) · entry: R2a, R2c · fixtures FX-SF5, FX-DRAFT · seeds: Shared forms, two stages.

ID	Criterion	Verified by	Source	Status
AC-R2d-01	The ledger's cross-form reuse list (FX-SF5) passes: compatible same-context answers are shared across forms, and each form keeps its own completion.	C, E	SF3; SF5	confirmed
AC-R2d-02	A reviewer sees their own prior answers and ancestor answers across forms, in the exact entity or branch context.	E	SF5	confirmed
AC-R2d-03	Changing a shared answer flags other sessions "contains outdated annotations" (derived on read, limited to the same reviewer's sessions on the same study); nothing adopts the new revision automatically.	I	SF5; consistency model (C19)	confirmed
AC-R2d-04	Fix creates a current incomplete version and opens that session's form.	E	SF5	confirmed
AC-R2d-05	A warning alone keeps a current Complete counting; a reviewer's Fix (an explicit incomplete version) removes qualification until a valid Complete.	C	SF6	confirmed
AC-R2d-06	An admin revises an unnecessary update requirement as a superseding policy record (compare-and-set on the policy generation) that restores qualification by derivation; no version, transition history or work is rewritten or deleted.	I	FV4; VA-03	confirmed
AC-R2d-07	Two forms under one entity category share its label answer, with lineage shown.	E	SF3	confirmed
AC-R2d-08	Outdated annotations are flagged in-app on the session. Self-caused flags send no notice; when someone else caused the change (a support on-behalf-of write, an adoption remap, a shared-gold revision), each affected owner gets one in-app notice per cause, off by default.	E, I	SF5; NS-14; Q-20	pending-Q-20
AC-R2d-09	Before changing a shared answer, the reviewer is told that a new version will be created and which sessions will show "contains outdated annotations"; the same QuestionId under another entity or branch stays separate; conflicting legacy duplicates show a conflict marker.	I, E	SF5	confirmed
AC-R2d-10	Saving form G with a draft based on an older revision of a head changed through form F returns a typed stale-base conflict that shows both values and keeps G's draft.	I	VB-15	PROPOSAL
AC-R2d-11	Two forms pinning incompatible versions of one shared question never flag each other; a v2-only option never appears in a v1 session; Fix shows the current revision within the compatibility class.	C	VA-02; D2-02	pending-D2-02
AC-R2d-12	A recorded publication treatment removes qualification only by changing the session's derived effective status, without writing a version (SF6 read as the versioning model proposes).	C	SF6; VA-03; D2-01	pending-D2-01
AC-R2d-13	The six per-answer states (current; outdated own answer; needs updating for a new version; needs updating for an invalid value; pinned to an older version; not applicable) render with copy-deck text, and testers can explain them.	E, UT	VA-27	PROPOSAL
AC-R2d-14	Withdrawing an entity instance flags the same reviewer's sessions of other forms on that study as outdated.	C	VB-09	PROPOSAL
AC-R2d-15	No acknowledgement is needed to Complete with outdated answers: the non-blocking warning replaces FEAT-001's acknowledgement and enforcement levels.	E	D4-17	pending-D4-17
AC-R2d-CONF	C2-T02, T03, T07; C4-T15; C5-T06, T11; C19-T02.	C	review AC-01	PROPOSAL

Changes: AC-R2d-03, 05, 06 and 08 rewritten; AC-R2d-09 to 15 new.

4.12 R3a Steps, routing and canonical screening decisions

Tier T1 (staging rehearsal, with the screening floor step) · freeze F3 · entry: R2a shipped; R0 screening floor step; AC-R2b-13; X-ELIG for production · fixtures FX-PRISMA-03a, FX-PRISMA-03b, FX-ACCESS-01 to 10, FX-ELIG, FX-LEGACY (thresholds), RV-DS-05 · seeds: Workflow routing; Realistic content.

ID	Criterion	Verified by	Source	Status
AC-R3a-01	The handoff's worked scenes, as corrected by DP6 and DP7, pass as journeys: title/abstract to combined full text; an independent decision that doesn't stop another form; facts → screening → outcomes; collective Exclude during extraction with EW1; a personal Exclude blocking that reviewer; two forms with targets 2 and 1; an extraction-only step that offers annotation or Skip.	E	DP6; DP7; EW1; review AC §5.7	confirmed
AC-R3a-02	The C6 evaluation table gives identical results for selection, reservation, direct access and submit (table-driven, shared corpus).	C	C6; DP6; DP7	PROPOSAL
AC-R3a-03	The browser follows the server's eligibility decision (the eligibility programme's S6b consumption is absorbed into R3a); #3551's universal screening-complete veto is gone.	E	Q-24; AP-09; D3-09	pending-D3-09
AC-R3a-04	Autosave never votes, and screening decisions are never overwritten: each submit is a new revision.	I	DP3; SL1	confirmed
AC-R3a-05	FX-PRISMA-03a assertions pass: own Include with collective Pending opens permitted within-stage dependent work and records no collective Included; cross-stage work stays blocked under the Collective Include default and opens under the advanced option; collective Exclude blocks new dependent work while EW1 governs saved work; a collective Excluded stays Excluded despite completed extraction (PR1); one current ScreeningOutcome per profile; StudyEnteredPool entries carry filter and profile versions.	C	DP6; DP7; PR1; EW1	confirmed
AC-R3a-06	Statistics count per profile and per form without double counting; the hard-coded "enough = 2" is replaced by targets through FEAT-024's target-aware classification (AC-R2b-13).	I	SF2; OPS1; MS-07; AP-14	PROPOSAL
AC-R3a-07	Migrated combined stages keep their Allow/Stop value, and a missing value migrates as Allow (eligibility D1); new combined steps default to Stop; newly unavailable activity is refused while drafts are kept (eligibility D4).	I	Q-24; A-16; review AC-34	pending-Q-24
AC-R3a-08	The stage designer rejects dependency cycles; display order never creates a dependency; the effective-policy preview matches real admission decisions.	U, E	C6	PROPOSAL
AC-R3a-09	"Who is offered what" needs the Monitor capability; holders may see personal votes, while reviewer-facing warnings and route messages never reveal votes; until X-AUTH-RESOLVER lands it shows pool-level counts by refusal reason, with no per-reviewer rows.	I	RECOVERED (OD5); C10; V2-08; AP-02; D3-13	pending-D3-13
AC-R3a-10	Pool-entry events are recorded, with filter and profile versions, by every writer that changes availability (decision submit, batch opening, personal grant, import into an available stage, binding and lifecycle changes, dedup reversal); pool entry is the first release to anyone; shared openings and personal grants are recorded separately.	I	Amendment A (Q-06a); DC-14; AP-05; D3-13	pending-D3-13
AC-R3a-11	Complete-and-Include commit together: an injected failure commits neither; a retry after an unknown commit returns the original result; navigation waits for acknowledgement.	C, E	Research A8	PROPOSAL
AC-R3a-12	The default profile's outcome equals the characterised legacy result for single, manual dual, automated dual and custom thresholds across missing, insufficient, conflict, included, excluded and corrected cases.	C	Research A2	PROPOSAL
AC-R3a-13	Skip records no decision, completion or PRISMA event.	C, E	Amendment A (Q-06a); RC6	confirmed
AC-R3a-14	The advanced own-Include option admits an own-Include reviewer while the collective decision is Pending and blocks them after a collective or personal Exclude; a self-cycle is rejected; a changed published policy is rechecked at transactional admission (FX-ACCESS-03, 07, 10).	C, E	DP7; access-policy fixtures	confirmed
AC-R3a-15	VS1 is a step-level policy with a stage default, and BL1 is stage-owned; both are versioned with the stage settings and shown in the designer (display behaviour is AC-R4a-42).	I	VS1; BL1	confirmed
AC-R3a-16	The eligibility test-plan layers pass for legacy and migrated combined stages, or each changed expectation cites Q-24's answer.	C, I, E	Q-24	pending-Q-24
AC-R3a-17	Decisions captured since admission appear as canonical history with original times, authors and "captured legacy" provenance; none is lost or duplicated.	I	E26	PROPOSAL
AC-R3a-18	One current outcome per study and profile, with route provenance, an authority from the approved set (candidate agreement, reconciled, Admin with override audit, legacy-compatible or unknown) and a structured reason with coverage status; no single Study screening status; no free-text-only reason.	C	Amendment H (Q-06a); FEAT-011 phases 13 and 15	confirmed
AC-R3a-19	Pool entry for early-stopped and batched reviews matches FX-PRISMA-03b; re-evaluating the recorded filter and profile versions reproduces membership; pool membership is derivable from filter rules.	C	Amendment A (Q-06a); FEAT-011 phase 14	confirmed
AC-R3a-20	Partial combined-step reservations behave as the C7 contract says.	C	E5	PROPOSAL
AC-R3a-21	An unvoted reviewer proceeds once a study is collectively Included, with no vote invented; a personal Exclude blocks that reviewer across stages; the advanced option relaxes the default (own Include or collective Included admits).	C	A-06; A-18; Q-15	pending-Q-15
AC-R3a-22	AND/OR dependency groups follow their truth table; terminal-on-Exclude ends only its scope; a compulsory step blocks dependent work.	C, E	C6; plan R3a	PROPOSAL
AC-R3a-23	VS1 and BL1 ship with provisional defaults, visibly marked: VS1 off; BL1 blinded with stable aliases.	E	Q-30	pending-Q-30
AC-R3a-24	Screening capacity follows the profile's collective rule, not the annotation target (eligibility D6).	C	RT-23; Q-24	pending-Q-24
AC-R3a-25	Opening a study claims only steps that are currently available; an own Include tries the dependent form claim atomically; if it is refused, that step shows the typed "enough reviewers" state and the screening decision stands.	I	RT §5.2; D3-19	pending-D3-19
AC-R3a-26	Next and pool selection have p95 ≤ 400 ms at 100,000 studies (RV-DS-05).	B	AP-17; PH-23	PROPOSAL
AC-R3a-27	Canonical admission writes no per-project document per save: it checks the bound StageSettings version in the Study filter; AC-ALL-26 passes with eligibility on.	I, B	DC-05; MS-19	PROPOSAL
AC-R3a-28	A keyboard screening path exists (decide Include or Exclude, next, skip) with at most two actions per decision.	E, A	UX-02	PROPOSAL
AC-R3a-29	On title/abstract steps, a tester screens 20 studies on a 390 px phone with the on-screen keyboard hidden; annotation stays tablet and desktop.	E, X	UX-15; D3-05	pending-D3-05
AC-R3a-30	Screening decisions imported from CSV columns mapped to members are recorded with authority Imported, independence unknown, source system and import job; they count toward sufficiency only if the importing admin records that they were independent; they are left out of the default inter-rater view and count as "screened in SyRF (imported record)", so amendment K's external counts are refused for those records.	I	SR-03; methodology coverage	PROPOSAL
AC-R3a-31	Derived records carry the definition-version vector they were evaluated under: a decision racing a profile publication, and a threshold change racing a decision, leave no stale outcome undetected; admission fails closed on a stale ScreeningOutcome; predicate-driven sweeps repeat until nothing is stale.	I	DC-08; domain model	PROPOSAL
AC-R3a-32	ScreeningOutcome has the facets candidate result, vote counts, rule version, final result, final source, adjudication reference and freshness; its only writer is the collective-outcome policy, invoked by submit and adjudication commands; it is rebuildable, and a parity fixture matches recomputation.	C	Domain model; VA-20	PROPOSAL
AC-R3a-33	X-ELIG evidence before production admission: S4-B, S4-C, S6a, S6b and the fixed-two correction each merged or extracted; reviewEligibilityPolicy and proportionalStudyAllocation delivered to API and PM with a cross-host agreement check.	G, I	AP-08, AP-09; D3-09	pending-D3-09
AC-R3a-34	The default profile's decisions are projected into legacy ScreeningInfo and InclusionInfo, so the ProjectScreening, MembershipScreening and ReviewerScreening families stay exact (parity audit).	I	MS-08	PROPOSAL
AC-R3a-35	EW1: the stage default Allow lets a reviewer finish previously saved work after collective exclusion; a step override to preserve-only keeps drafts but refuses completion; neither admits new work nor invents votes.	I, E	EW1; FX-ACCESS-09	confirmed
AC-R3a-36	Historical work pins the stage-settings version it was done under; publishing new stage settings never rewrites prior work; live access is re-evaluated under current settings.	I	PV2	confirmed
AC-R3a-37	Every existing per-stage setting (target enforcement, in-progress limit, hide excluded, excluded-progress grouping, self-reconciliation, search and partition filters, #3876 tracking) behaves as the F3 placement table says when stages bound to one form differ (table-driven fixture).	C	Domain model; PH-05	PROPOSAL
AC-R3a-38	Each reviewer's initial independent submission per profile context is marked: their first effective decision made before any collective outcome for that study and profile was visible to them.	C	SR-01; methodology coverage	PROPOSAL
AC-R3a-39	An incomplete Save recomputes shared sufficiency and dependent-step applicability, shows affected steps as needing reassessment, preserves dependent work, and never changes gold or screening decisions as a side effect.	I	Q-27	pending-Q-27
AC-R3a-40	When stages reaching one session differ, EW1 and VS1 are evaluated for the route in use and never change the shared target.	I	Q-28	pending-Q-28
AC-R3a-41	Random serving is the default; explicit assignment is an audited exception.	I	D4-19	pending-D4-19
AC-R3a-CONF	C1-T04 (journey part); C3-T06, T08; C6-T01 to T03 and T05 to T22; C10-T08; C12-T01 to T03; C17-T02.	C	review AC-01	PROPOSAL

Changes: AC-R3a-01, 03, 05, 06, 07, 09 and 10 rewritten; AC-R3a-11 to 41 new.

4.13 R3b Screening profiles

Tier T2 · freeze F5 · entry: R3a, R2c; U17 and U18 passed · fixtures FX-DP4, FX-PRISMA-02c, FX-PRISMA-04c · seeds: Workflow routing.

ID	Criterion	Verified by	Source	Status
AC-R3b-01	Eligibility questions are authored in the shared editor; templates are copied and stay independent of later template changes.	I, E	DP4; SET1	confirmed
AC-R3b-02	The same profile in two stages gives one decision per reviewer; different profiles never share answers.	C	DP4; research A4	confirmed
AC-R3b-03	A derived decision is shown with its reasoning (the triggering criteria and the reviewer's own answers, never other candidates' answers) and counts only after explicit submission; field changes and autosave never vote.	E	DP3	confirmed
AC-R3b-04	With DP5 on, applicable exclusion reasons need reconciliation under the profile's rules; with DP5 off there is no reason-reconciliation requirement, and recorded reasons and their history are kept.	I, E	DP5	confirmed
AC-R3b-05	Profile publication: a publish-time check finds decisions cast under prior criteria versions; the admin chooses keep pinned, require a new decision, or compatible carry-forward; collective outcomes are recomputed only under that choice; past PRISMA snapshots don't change. DP5, resolution routes and rationale settings are profile settings with audit history and no publication flow.	I	Q-26; VA-19; D2-05	pending-Q-26, pending-D2-05
AC-R3b-06	Each profile's PRISMA phase mapping is set and versioned.	I	C12	PROPOSAL
AC-R3b-07	Screening steps render eligibility questions through the screening renderer agreed at F5.	E	A-02	assumption-A-02
AC-R3b-08	FX-PRISMA-02c and FX-PRISMA-04c assertions pass: one effective decision per profile per reviewer across stages; profile publication applies each treatment; no snapshot changes.	C	DP4; V2-07	confirmed
AC-R3b-09	An ordinary study-fact question and a profile question with identical wording never share answers; two profiles copied from one template never share answers or history (FX-DP4).	C	DP4	confirmed
AC-R3b-10	With reason collection off and reason reconciliation on, no reason is invented and nothing blocks.	C	DP5; E11	confirmed
AC-R3b-11	A reviewer's deliberate correction of their own Exclude from history, while review is possible, creates a new revision, keeps the Exclude in history, re-evaluates eligibility and creates no invitation; a closed or restricted stage refuses it.	I	DP2	confirmed
AC-R3b-12	Multi-profile screening statistics are served live for R3b pilots; FEAT-024's screening families are declared unsupported for multi-profile projects until its profile-grain families land; the UI labels the basis.	I	MS-08; D3-10	pending-D3-10
AC-R3b-13	The primary exclusion reason is the first failing criterion in the configured order (on by default, overridable per profile).	I	D4-13	pending-D4-13
AC-R3b-14	A profile can offer Unsure (Maybe) at title/abstract, on by default in the title/abstract template.	I, E	D4-01	pending-D4-01
AC-R3b-15	Re-publishing a profile whose eligibility changed needs an amendment entry in the protocol record.	I	D4-05	pending-D4-05
AC-R3b-16	A new administrator sets up a title/abstract → full-text route with two profiles from templates in under 5 minutes without help.	UT	PH-23 (FEAT-007 metric)	PROPOSAL
AC-R3b-17	A DP2 correction made after the collective outcome became visible to the reviewer is labelled "informed (collective)" and never changes the initial-observation set.	C	SR-01; methodology coverage	PROPOSAL
AC-R3b-18	When the profile requires exclusion reasons, a missing reason blocks an effective Exclude; cancel or error keeps the draft and the previous vote; a valid Exclude commits its reason tree and the outcome together.	C, I	Research A6; DP5	PROPOSAL
AC-R3b-19	Screening-decision exports include each decision's exclusion reasons and the screening profile and version it was cast under.	I	QM v2 EXP-04 (retained)	PROPOSAL
AC-R3b-20	With the profile's bibliographic-blinding option on (off by default), authors, journal and year are not shown during screening, and the decision's exposure provenance records that they were hidden.	E, I	SR-25; methodology coverage	PROPOSAL
AC-R3b-CONF	C2-T04; C3-T07; C4-T04 (profiles), C4-T20; C8-T08.	C	review AC-01	PROPOSAL

Changes: AC-R3b-03, 04, 05 and 08 rewritten (the DP2 part of 04 moved to AC-R3b-11); AC-R3b-09 to 20 new.

4.14 R3c Stage lifecycle and optional strict mode

Tier T2 · freeze F3 (lifecycle subset) · entry: R3a; X-BATCH if batches are used · fixtures FX-LIFE-01 to 10, FX-PRISMA-04d · seeds: Workflow routing.

ID	Criterion	Verified by	Source	Status
AC-R3c-01	In automatic mode a stage completes only when no unresolved applicable work remains, drafts and corrections included.	I	LC1	confirmed
AC-R3c-02	A change that would reopen a Completed stage isn't admitted until a project admin confirms it; until then the stage stays Completed and the change is held in "changes awaiting approval".	E, I	LC1	confirmed
AC-R3c-03	New arrivals to a Completed stage go through the same gate; manual mode needs an explicit Reopen.	I	LC1; RX2	confirmed
AC-R3c-04	Fix or a correction on a session pinned to a Completed stage creates a pending request, never a silent reopen.	E	LC1	confirmed
AC-R3c-05	Readiness uses the same completion-definition seam as #3939 and the shared fixtures; results differ only where SF2 or R3b semantics differ, and those cases are listed.	C	AP-04	PROPOSAL
AC-R3c-06	Everything above works with every notification flag off; status history records every transition with actor and reason.	E, I	RX2; A-07	confirmed
AC-R3c-07	Strict within-stage mode is an advanced stage setting, off by default, with a tighten-only step override; enabling it never admits anyone the default refuses.	C	DP7 (proposal only); Q-01	pending-Q-01
AC-R3c-08	A change affecting a shared form bound to two Completed stages needs approval for each and commits to both or neither; changed inputs (permission, approval expiry, source hashes, stage state) invalidate the approval; approval never grants the requester authority; approvals expire.	I	LC1; FX-LIFE; Q-02	pending-Q-02
AC-R3c-09	A Completed stage's bindings can't be edited outside the reopen flow.	I	RX2 (RECOVERED)	confirmed
AC-R3c-10	A reviewer having no available work never marks a stage complete.	I	Research A14	PROPOSAL
AC-R3c-11	With every notification flag off, an admin with a pending request sees it in the global badge and the project-overview banner, and reaches it in one step from the project index.	E	NS-07; UX-08; D3-07	pending-D3-07
AC-R3c-12	With notification flags on, each approving admin gets one notice; once one admin decides, the others' notices show "decided" and leave the unread count, staying in history.	I, E	NS §5.3; D3-23	pending-D3-23
AC-R3c-13	Completion runs in two steps (Completing fence, drain, readiness verified from authoritative records in a pinned snapshot, then Completed or back to Active); at least 1,000 randomised interleavings of commits against completion never violate LC1; under Completing a readiness-relevant command is refused as retryable; under Completed it becomes a change request.	I	DC-09 (AC-DC-09); D2-10	pending-D2-10
AC-R3c-14	Completion withdraws that stage's claim references through the outbox; a claim survives if another bound stage still uses it; the client keeps unsaved changes.	I	RT-18	PROPOSAL
AC-R3c-15	FX-PRISMA-04d assertions pass: unresolved applicable work blocks automatic readiness; a protected correction or new arrival needs confirmation, then the automatic or manual transition follows.	C	LC1; V2-07	confirmed
AC-R3c-16	Drafts never expire: stale drafts are listed to admins because they block automatic completion, and are removed only by an audited discard.	I, E	VB-15; consistency model	PROPOSAL
AC-R3c-17	Where batches are used, a shared batch opening and a personal grant are durable compare-and-set transitions that write a StudyEnteredPool ledger entry (FEAT-011's pool-entry event) in the same transaction; reading batch status never changes plan state; activation needs X-ELIG in the same environment and a Next p95 gate at 100,000 studies and 2,500 batches.	I, B	AP-05, AP-19; D3-13	PROPOSAL
AC-R3c-18	Calibration rounds run as a step kind that never votes, never qualifies and never counts for PRISMA.	I, E	D4-04	pending-D4-04
AC-R3c-19	Sufficiently excluded studies stay in a batch's denominator and count as finished; restored scope returns to its original membership.	I	AP-12; D3-13	pending-D3-13
AC-R3c-CONF	C1-T07 (stage-completion part); C6-T04; C18-T05 (completion).	C	review AC-01	PROPOSAL

Changes: AC-R3c-02, 05 and 07 rewritten; AC-R3c-08 to 19 new.

4.15 R3d Guided setup and templates

Tier T2 with five testers (AC-UX-07) · entry: R3b, R2c, R1a · fixtures FX-SETUP-01 to 13 · seeds: none (testers create projects).

ID	Criterion	Verified by	Source	Status
AC-R3d-01	Every field and validation of today's CreateProjectWizard and ProjectSetup is available; the setup lane writes the parity checklist and Chris signs it.	E, G	SET2; review AC-34	confirmed
AC-R3d-02	The guided route creates profiles from templates, an initial form from question templates, a stage and step route with DP7 defaults and (once R1c exists) team and groups; preview and publish go through the impact gates.	E	SET1; DP7	confirmed
AC-R3d-03	A setup draft can be resumed, and manual routes stay available.	E	SET2; FX-SETUP-07, 11	PROPOSAL
AC-R3d-04	New projects are admitted by R0's rule.	I	A-23	assumption-A-23
AC-R3d-05	The Project setup checklist stays in the navigation footer, with readiness-based tasks.	E	RECOVERED (navigation decision, 21 September)	confirmed
AC-R3d-06	With extraction off, setup adds no cohort, outcome or experiment types; templates use verified legacy identities (E14).	I, E	TC1	confirmed
AC-R3d-07	An empty project creates no PRISMA records; a double submit creates one project; the old create entry point uses the new flow without creating a duplicate; living-search and ML stay disabled.	I, E	FX-SETUP-06, 08, 09	PROPOSAL
AC-R3d-08	A new administrator reaches a screenable stage from templates in at most 20 minutes without help (AC-UX-07).	UT	UX-19	PROPOSAL
AC-R3d-09	The screening and form templates carry the methodology defaults: title/abstract with two independent screeners, unanimity and a blinded third screener on conflict; full text with two independent screeners, unanimity, adjudication, and reasons required under the primary-reason hierarchy; extraction with two reviewers plus reconciliation (or one plus verification if D4-03 is approved); a single-screener option that sets the methods caveat (AC-R5b-24). CAMARADES methodologists author the template content through the R1a template mechanism, and a project may change any default.	I, E	SR-21; SR improvement 9; methodology coverage	PROPOSAL
AC-R3d-CONF	C4-T04.	C	review AC-01	PROPOSAL

Changes: AC-R3d-01 rewritten; AC-R3d-06 to 09 new.

4.16 R4a Form reconciliation and gold

Tier T1 (staging rehearsal) · freeze F4 · entry: R2b shipped; Q-10, Q-29, Q-35, Q-36 and the Q-03 reconciliation subset answered; the editable reconcile host; the task editor claim (X-RECLAIM) in every environment · fixtures FX-SF4, FX-RE5, FX-CLAIMS, FX-ALLOC · seeds: Reconciliation, four candidates.

ID	Criterion	Verified by	Source	Status
AC-R4a-01	Three candidates are shown everywhere (answers, matching, comparisons); a fourth appears without truncation; a candidate selector never hides a disagreeing candidate (FX-SF4).	E	SF4/RE3	confirmed
AC-R4a-02	Match suggestions span all candidates; the reconciler confirms or adjusts them; original candidate entries and answers are preserved; a suggestion never establishes an authoritative match or publishes gold by itself.	E, I	MG1	confirmed
AC-R4a-03	Prefill happens only for choice agreement or an exact text match in the same question, version, entity and branch context.	C, E	RE2; RE5	confirmed
AC-R4a-04	Gold is an immutable snapshot; a new snapshot keeps unchanged references; concurrent publications are serialised by compare-and-set on the current-snapshot pointer (race forced by the barrier harness).	I	GS1	confirmed
AC-R4a-05	By default a reconciler is never offered a study × form task on which they hold a candidate session; QY4's audited self-review applies only to query review.	I	QY4 (boundary); RA1	confirmed
AC-R4a-06	A requested extra reviewer sees no candidate answers or identities; their result returns to the reconciler and never sets gold or changes the target.	I, E	RA5	confirmed
AC-R4a-07	Expiry applies only to explicit, unstarted assignments; started assignments never expire; every expiry, override and release is audited.	I	RA3	confirmed
AC-R4a-08	Aliases and blinding are consistent across candidate cards, conversations, history and exports.	E	BL1	confirmed
AC-R4a-09	The target is a minimum: every qualifying candidate takes part in the task.	I	SF4/RE3	confirmed
AC-R4a-10	Assigned work and requested reviews appear in their feature-owned queues with every notification flag off.	E	A-07; RA2–RA5	assumption-A-07
AC-R4a-11	Drag-pairing has a keyboard alternative.	A, E	U1	PROPOSAL
AC-R4a-12	A legacy reconciled answer exports as "legacy reconciled (authority unknown)", can't be queried, and R4a readiness treats its study as still needing canonical reconciliation; a canonical task supersedes it with explicit provenance.	I	Q-35; review AC-02	pending-Q-35
AC-R4a-13	The workspace with four candidates on a 200-question form meets AF2's performance gate extended with N-candidate fixtures (host to first interactive under 1,500 ms; edit-to-settle p95 under 16 ms; category switch under 250 ms; mounting caps per candidate column PROPOSAL), measured on the AF2 performance host.	B	PH-32; review AC-18; e2e/tests/perf/annotation-form-perf.spec.ts	PROPOSAL
AC-R4a-14	Incompatible, saved-incomplete-current, withdrawn and ineligible sessions are never candidates and never count; agreeing candidates produce no gold until the reconciler completes.	C	SF4 delivery list; RE2	confirmed
AC-R4a-15	A study × form task is listed once, whether reached from stage A or B, and completing it satisfies only that form's reconciliation requirement in each stage.	I, E	RE4	confirmed
AC-R4a-16	Complete succeeds with no explanation even when gold differs from every candidate; a non-blocking reminder may show.	I, E	RE1	confirmed
AC-R4a-17	Candidate notes are unchanged by reconciliation; a copied note keeps its author and source.	I, E	NT1	confirmed
AC-R4a-18	Texts differing only in case or whitespace don't prefill; gold and the reconciler's saved draft survive changed candidate inputs (FX-RE5).	C	RE5	confirmed
AC-R4a-19	Rendering an accepted revision records one exposure per session version and revision, carried in the draft, Save and Complete payloads (never in hub calls), with late events keyed by draft etag accepted; a lost report leaves the contribution "informed or unknown", never independent; the class is derived on read.	C, E	VS2; C3; DC-20; RT-26	confirmed
AC-R4a-20	A new candidate, a Save after Complete or a Fix after gold puts the task into "inputs changed · re-check" and never retracts gold.	I	GS1; RE4	confirmed
AC-R4a-21	With conversations enabled on their own flag: threads are one-to-one; only completed sessions can be questioned, so a requested extra reviewer is excluded until they return their review; a reconciler with any session on that study × form can't start one; context links are read-only; threads bind to the task identity and stable stage-owned aliases; conversations refuse canonical scopes until rebound.	I, E	Q-10; NS-05; NS §5.3	confirmed
AC-R4a-22	Assigning to an ineligible reconciler is refused; an expiry and a first start racing have exactly one outcome (compare-and-set on assignment.started); changed defaults affect only new assignments; two reconcilers never hold one task.	C, I	RA1; RA2; E6; DC-15	confirmed
AC-R4a-23	Re-pairing keeps earlier pairings in history and re-evaluates only dependent answers.	I	Plan R4a (COMPARISON F7)	PROPOSAL
AC-R4a-24	Autofilled answers are clearly marked and distinguished from entered ones, with candidate and source provenance kept.	E	RE2	confirmed
AC-R4a-25	Final Complete accepts the displayed valid answers, including prefill, with no per-field confirmation.	I, E	RE2	confirmed
AC-R4a-26	Before Complete, unseen relevant controls (exposure of the actual controls, not tab visits) produce a warning listing them with jump links; Complete anyway works; answer validity and affected-child requirements stay enforced.	E, I	RE2	confirmed
AC-R4a-27	Complete carries the base snapshot ID and the task input-set etag the reconciler saw; a transparent retry happens only when the recomputed snapshot equals what was displayed; otherwise the typed "gold changed" or "inputs changed" conflict returns, with Complete anyway still available.	I	DC-15 (AC-DC-14)	PROPOSAL
AC-R4a-28	No project setting permits self-reconciliation; adjudication overrides need explicit grants; a gate never uses stale authority for new admissions (it shows "needs revalidation"); saved work stays.	I	Q-36	pending-Q-36
AC-R4a-29	An admin release of a started assignment keeps saved work, and the original reconciler must reacquire it before submitting again.	I	RA4	confirmed
AC-R4a-30	A task uses the most restrictive blinding of the stages that can reach it.	I, E	Q-28	pending-Q-28
AC-R4a-31	Target-1 forms create no task and no automatic gold; exports label the single assessment "single reviewer, unreconciled"; an optional, attributed "accept as gold" action creates a snapshot.	I	Q-29	pending-Q-29
AC-R4a-32	Drag-pairing uses CDK pointer-based drag that works with touch; the reviewer and reconciler smoke journeys pass in Firefox and WebKit.	X, E	review AC-19; D3-15	pending-D3-15
AC-R4a-33	When candidates' pinned revisions for a question fall in different compatibility classes, that question is held on its own; a held question blocks only itself (prefill, agreement), and the rest of the task reconciles.	C	VA-04; D2-02	pending-D2-02
AC-R4a-34	A publication that makes a gold answer's compatibility class differ from the form's current pin flags that answer "needs re-reconciliation", while gold stays effective and is labelled with its version in exports and PRISMA manifests; a publication that de-qualifies a pinned candidate is a drift trigger.	I	VA-11	PROPOSAL
AC-R4a-35	A session questioned in a reconciliation conversation gets the exposure kind "questioned in reconciliation", which makes that reviewer's later versions on that study × form informed; R5c, C11 manifests and R6 read it.	C	NS-06	PROPOSAL
AC-R4a-36	When two reconcilers open the same study × form task through any stage, exactly one holds the editor claim and the other is refused with a typed reason, with tracking on and off.	I	RA1; RT-01	confirmed
AC-R4a-37	With several reconcilers pressing "Start reconciling" at once, no task goes to two of them.	I	RA1; RT-01	confirmed
AC-R4a-38	A requested extra reviewer is admitted past pool, bucket and capacity filters by a single-use, expiring, audited admission, even with allocation enabled and the target met; nobody else is.	I	RA5; AP-03; RT-13; D3-13	pending-D3-13
AC-R4a-39	Only the assignee can claim an assigned task; an admin release revokes the editor claim through the outbox; editor-lease expiry never expires a started assignment.	I	RA2–RA4; RT §5.2	confirmed
AC-R4a-40	Assignment timers use absolute UTC timestamps (ADR-008) with Quartz integration tests; the expiry warning is a scheduler marker on the assignment that survives scheduler restarts without repeating.	I	PH-30; NS-01	PROPOSAL
AC-R4a-41	Each assignment transition (created, expiry warning, expired, released) produces exactly one notice.	I	NS §5.3; C15	conditional-X-NOTIF
AC-R4a-42	With the step's VS1 policy off, candidates never receive accepted answers (API or UI); with it on they see the current snapshot, and the view tells them their contribution will be recorded as informed; own previous answers are always visible; other candidates' answers never are.	I, E	VS1; VS2; UX-14	confirmed
AC-R4a-43	For shared-question gold across overlapping forms, the second task sees the existing gold prefilled as accepted and may revise it in its final submission, creating a new snapshot with provenance.	I	VA-11; D2-09	pending-D2-09
AC-R4a-44	Required applicable questions can't be blank in completed candidates; the reconciler decides optional blanks; a blank is never treated as Not applicable.	I, C	UA1	confirmed
AC-R4a-45	The reconciler journey (pool, task, screening part, matching, form, Complete, next) passes as one journey; the narrow layout uses a candidate selector and a single column and never hides a disagreeing candidate.	E	UX-14	PROPOSAL
AC-R4a-46	"Next" offers assigned work first, then a random eligible task.	I, E	Plan R4a (v10 r2)	PROPOSAL
AC-R4a-47	A project-level "My work" surface lists the user's actionable reconciliation items; with every notification flag off, a user reaches assigned work in an unopened project in one step from the project index.	E	UX-08; NS-07; D3-07	pending-D3-07
AC-R4a-48	Candidates are always blinded in reconciliation; the stage chooses only the alias scheme.	I, E	D4-19	pending-D4-19
AC-R4a-49	An extract-and-verify step produces gold with authority Verified.	I	D4-03	pending-D4-03
AC-R4a-CONF	C2-T05; C3-T02, T03, T05, T09; C7-T09; C9-T01 to T09, T13 to T16, T18; C17-T06; C18-T08.	C	review AC-01	PROPOSAL

Changes: AC-R4a-02, 03, 05, 07, 08, 09, 12 and 13 rewritten (the bundled AC-R4a-03 and 07 were split into 03, 24, 25, 26 and 07, 29; the Q-28 and Q-29 parts of 08 and 09 moved to 30 and 31); AC-R4a-14 to 49 new.

4.17 R4p Profile reconciliation

Tier T2 · freezes F4 and F5 · entry: R3b and R4a shipped · fixtures FX-RX1, FX-PRISMA-03c · seeds: Reconciliation, four candidates; Workflow routing.

ID	Criterion	Verified by	Source	Status
AC-R4p-01	Decision adjudication resolves profile conflicts; the outcome is written by the versioned ProfileAdjudication aggregate through the collective-outcome policy, never by a reconciliation session writing screeningOutcomes.	I	FEAT-011 (MUST NOT); RX1; V2-18; domain model	confirmed
AC-R4p-02	Must-agree supporting answers and reason reconciliation work when DP5 is on; with DP5 off, recorded reasons are kept.	E, I	DP5; RX1	confirmed
AC-R4p-03	A collective Excluded stays Excluded (PR1), and adjudication unblocks a cross-stage route that was waiting on a conflict.	C, E	PR1; DP7	confirmed
AC-R4p-04	Who reconciles each part follows stage grants.	I	C10; RX1 (presentation, 3 October)	PROPOSAL
AC-R4p-05	Two Excludes with differing must-agree reasons: the collective Exclude vetoes dependent work while reason reconciliation is pending; extra votes never resolve reasons; adjudication adds no vote; a submitted decision replacement retires the old adjudication from current applicability and re-evaluates profile rules, while drafts don't (FX-RX1).	C	RX1 (RECOVERED); research A25	confirmed
AC-R4p-06	A profile may require a rationale for an adjudicated screening decision (a setting, off by default); RE1 still makes explanations optional for ordinary reconciled answers.	I, E	Q-32; RE1	pending-Q-32
AC-R4p-07	FX-PRISMA-03c assertions pass: pending reason coverage becomes adjudicated coverage; the collective Exclude veto holds while reasons are pending; adjudication adds no vote.	C	PR1; RX1; V2-07	confirmed
AC-R4p-08	A profile can offer a discussion resolution route, off by default.	I, E	D4-02	pending-D4-02
AC-R4p-09	The adjudication view shows each candidate's full set of failing criteria, not only the primary reason; reason reconciliation compares the full sets while PRISMA receives the primary reason.	E	SR improvement 4; D4-13	pending-D4-13
AC-R4p-CONF	C9-T17; C12-T01 (adjudicated authority).	C	review AC-01	PROPOSAL

Changes: AC-R4p-01 rewritten; AC-R4p-05 to 09 new.

4.18 R4b Queries

Tier T2 · entry: R4a · fixtures FX-QY · seeds: Reconciliation, four candidates (query raiser and query reviewer personas).

ID	Criterion	Verified by	Source	Status
AC-R4b-01	Anyone who can view an accepted answer can raise a query, and gold stays effective with a pending flag.	I, E	QY1; QY7	confirmed
AC-R4b-02	There is one work item per accepted-answer version (the reconciled revision ID), with per-concern outcomes, and invalidated children are resolved before a replacement snapshot.	I	QY2; QY3; VA-23	confirmed
AC-R4b-03	Each raiser sees their own outcome in "my concerns and outcomes" with every notification flag off; private notices are added when the notification stack is available.	E, I	QY6; A-07	confirmed
AC-R4b-04	A replacement that satisfies a concern closes it as "addressed by update"; unsatisfied concerns stay open against their original target and are flagged for current-applicability review.	I	QY8; QY9	confirmed
AC-R4b-05	After a correction, candidate agreement never confirms annotation gold automatically, while screening decisions re-run profile rules.	C	RECOVERED (RC10 split); RE2; AG2	confirmed
AC-R4b-06	Self-review by a query reviewer is audited.	I	QY4	confirmed
AC-R4b-07	Rejecting a concern with an empty explanation succeeds.	I	QY5	confirmed
AC-R4b-08	In a two-raiser fixture each raiser sees only their own concern, in the UI, the API and the inbox.	I, E	QY6; NS §5.3	confirmed
AC-R4b-09	Query review uses the same editor claim as reconciliation: one reviewer at a time per work item.	I	E4; RT §5.2	PROPOSAL
AC-R4b-10	Raising a query carries the answer version the raiser saw, never "current"; concurrent replacement and resolution keep each concern's original target.	I	DC-15; QY9	PROPOSAL
AC-R4b-11	Approving or rejecting a concern needs the query-review capability; a raiser without it can't resolve concerns.	I	QY4; V2-24	confirmed
AC-R4b-12	In canonical projects the study-issue form routes answer disputes to "Raise a query"; study issues never carry answer concerns after R4b.	E	NS-24	PROPOSAL
AC-R4b-13	A correction re-evaluates the smallest supported dependency closure.	I	Plan R4b (COMPARISON F3)	PROPOSAL
AC-R4b-CONF	C9-T10, T11, T12.	C	review AC-01	PROPOSAL

Changes: AC-R4b-02 rewritten (target defined); AC-R4b-07 to 13 new.

4.19 R4c Outcome reconciliation

Tier T2 · entry: O1 shipped, R4a, X-AF2-PR9 · fixtures FX-OUTCOME, FX-SF4 (series part) · seeds: Classification and outcomes.

ID	Criterion	Verified by	Source	Status
AC-R4c-01	Outcome series from every candidate are compared and reconciled into gold series.	E	SF4/RE3	confirmed
AC-R4c-02	Direction is reconciled once per outcome measure, never per series.	I	ODIR1	confirmed
AC-R4c-03	An extraction stage's outcome reconciliation opens in the editable reconcile host and saves gold series; before X-AF2-PR9 merges, the route shows the typed "not available" state.	E, I	Plan R4c; V2-23	PROPOSAL
AC-R4c-04	Every candidate's series stays reachable with provenance, including a fourth candidate, without truncation.	C, E	SF4	confirmed
AC-R4c-CONF	C9-T02 (series part); C14-T02.	C	review AC-01	PROPOSAL

Changes: AC-R4c-03 rewritten as an observable outcome; AC-R4c-04 new.

4.20 R5a History and as-of export

Tier T3 · freeze F6a · entry: R4a · fixtures FX-ASOF, FX-PRISMA-05a · seeds: Reconciliation, four candidates.

ID	Criterion	Verified by	Source	Status
AC-R5a-01	An as-of export reproduces a recorded state where history exists and labels gaps where it doesn't.	I	EX1; EX2	confirmed
AC-R5a-02r	Two exports at one watermark have identical data files and checksums for versioned datasets and the same requester authority; manifests differ only in generation metadata; current-only datasets are labelled "as at export time".	I	EX1; DC-13; review AC-34	PROPOSAL
AC-R5a-03	Dates before a project's adoption return "not observed", never the adoption snapshot.	I	EX2	confirmed
AC-R5a-04	The manifest records the basis, definitions, versions, per-dataset coverage (versioned, current-only or not observed) and content digests.	I	C11; DC-13; VB improvement 7	PROPOSAL
AC-R5a-05	Previous gold versions can be exported, and candidates and gold stay separate under the disclosure contract.	I	EX1; C10	confirmed
AC-R5a-06	The "completed sessions only" option works when its flag is on.	I	Plan R5a	PROPOSAL
AC-R5a-07	Exports carry per-question reconciliation status and version references (question version, compatibility class and option ID per cell).	I	QM v2 EXP-01, EXP-02; VA-17	PROPOSAL
AC-R5a-08	With injected clock skew and a long transaction committing near the watermark, exports at the same watermark are identical and causally closed; as-of(T) is offered only for T ≤ now − (transaction lifetime + sweep interval + skew bound).	I	DC-13 (AC-DC-12); consistency model	PROPOSAL
AC-R5a-09	As-of exports at earlier watermarks are identical except for erased identities, and the manifest records the erasure event.	I	D2-14	pending-D2-14
AC-R5a-10	Extraction exports default to studies whose required profiles are collectively Included; an explicit option includes the others, with per-row collective outcome, surplus-assessment and profile-version columns.	I	SR-17; methodology coverage	PROPOSAL
AC-R5a-11	After a restore, manifests and as-of requests for affected projects report the history-discontinuity record.	I	DC-17; D2-13	pending-D2-13
AC-R5a-12	Reconciliation conversations are exportable only behind an audit or export capability, with aliases, and never appear in candidate-answer exports or agreement figures except as exposure markers.	I	D3-25	pending-D3-25
AC-R5a-CONF	C11-T01 to T05 and T07 to T09; C18-T07.	C	review AC-01	PROPOSAL

Changes: AC-R5a-02 retired and replaced by AC-R5a-02r; AC-R5a-04 rewritten; AC-R5a-07 to 12 new.

4.21 R5c Agreement statistics

Tier T3 · entry: R4a (exposure records); Q-04 and Q-16 answered; the method contract (E9); U29 · fixtures FX-AGREE · seeds: Reconciliation, four candidates.

ID	Criterion	Verified by	Source	Status
AC-R5c-01	Agreement figures match hand-computed fixtures: multi-selects agree only on identical selection sets, with option overlap shown separately; N/A with N/A agrees and Applicable with N/A disagrees; compatible differing versions are compared with a flag, and incompatible versions never are.	C	AG2; AG3	confirmed
AC-R5c-02	Informed contributions are never counted as independent.	C	VS2	confirmed
AC-R5c-03	A missing answer is reported as "comparison not assessed", separately from agreement; Unknown or Not reported is a recorded state.	C	Q-04; review AC-02	pending-Q-04
AC-R5c-04	The agreement capability alone shows no candidate answers, and the view has its own navigation place.	I, E	AG1	confirmed
AC-R5c-05	The CSV equals the on-screen figures; a Reconcile holder without the agreement capability is refused.	I, E	AG1; QM v2 EXP-03	confirmed
AC-R5c-06	The default inter-rater basis is initial independent observations (AC-R3a-38); screening agreement is per profile; rotating raters use pooled pairwise κ or Krippendorff's α; percent agreement and prevalence are shown.	C	SR-01; Q-16; D4-12	pending-D4-12
AC-R5c-07	A contribution saved after being questioned in reconciliation counts as informed.	C	NS-06	PROPOSAL
AC-R5c-08	Agreement never crosses a compatibility class, and differing versions within one class are flagged.	C	VA-17; D2-02	pending-D2-02
AC-R5c-09	Agreement results live in their own rebuildable store, keyed by project, form version and method version, with a watermark and the independent/informed split; a bounded background job computes them; they are never a FEAT-024 family; full recompute for RV-DS-03 within 10 minutes and view load p95 within 2 s (PROPOSAL).	I, B	MS-20; D3-11	pending-D3-11
AC-R5c-10	A DP2 correction made after a conflict became visible never changes the initial-observation figures.	C	SR-01	PROPOSAL
AC-R5c-11	Agreement is shown by screening order (per 100 studies) for each reviewer pair and criterion, so drift is visible; calibration records are excluded by default and reported separately.	E, C	SR improvement 3; SR-11; D4-04	PROPOSAL, pending-D4-04
AC-R5c-12	The reconciler-override count (gold that differs from every candidate with no explanation) is shown per form and question and exported as goldDiffersFromAllCandidates; RE1's optional explanation stays optional.	I	SR-18; RE1	PROPOSAL
AC-R5c-CONF	C3-T02, T03, T05, T06.	C	review AC-01	PROPOSAL

Changes: AC-R5c-01 and 03 rewritten (placeholders made concrete); AC-R5c-05 to 12 new.

4.22 R5b PRISMA reporting

Tier T3 · freeze F6b · entry: P1, P2, R3b and R4p shipped · fixtures FX-PRISMA-01 to 08 (R5b parts, including 06e), FX-PRISMA-08b · seeds: PRISMA identification; Workflow routing.

ID	Criterion	Verified by	Source	Status
AC-R5b-01	FX-PRISMA-05b and FX-PRISMA-08 pass in full, and the R5b assertions of FX-PRISMA-01 to 04, 06 and 07 pass, including box values with reported external parts.	C	PR1; Q-06a; review AC-04	confirmed
AC-R5b-02	Report snapshots are frozen, and regenerating a frozen report gives identical numbers.	I	Amendment J (Q-06a)	confirmed
AC-R5b-03	Reported external counts are included in diagram totals and marked as reported; the manifest keeps the breakdown; reported-versus-imported mismatches warn.	I, E	Q-06a (Chris's request); amendment K; Q-37	pending-Q-37
AC-R5b-04	Box 3 combines SyRF-detected and externally reported duplicates, and the manifest keeps both parts.	C	Q-06a; amendments K and L; Q-37	pending-Q-37
AC-R5b-05	Adopted legacy projects show coverage and evidence-based lower bounds, never fabricated counts.	I	EX2; invariant 9	confirmed
AC-R5b-06	Box 17 uses metaAnalysisIncluded as set through its owner's UI.	E	C12	PROPOSAL
AC-R5b-07	All 34 PRISMA fields are derivable from SyRF data (with reported external records where amendment K applies), and the diagram export follows the PRISMA 2020 template layout.	I, V	FEAT-011 (34 fields); V2-04	confirmed
AC-R5b-08	PRISMA JSON and CSV exports carry a manifest; an unknown or null source type is its own group.	I	FEAT-011 phase 16 (EXP-05)	confirmed
AC-R5b-09	Every snapshot passes the published arithmetic identities per column: identification sums (fields 31–34); records after removal = records screened + not yet screened; records screened = records excluded + reports sought; reports sought = not retrieved + assessed + not yet assessed; assessed = excluded with reasons + included. The "not yet screened or assessed" remainder appears in the manifest and as a diagram footnote; a mismatch blocks freezing unless an admin records an explanation.	C	SR-09; methodology coverage	PROPOSAL
AC-R5b-10	Until amendment B is approved, exports label citation totals as records, never reports.	I	A-11	assumption-A-11
AC-R5b-11	Reason reporting gives the primary reason plus coverage status when reasons are pending or off; screening gold and ordinary gold are never conflated.	I	Amendment E; Q-22	pending-Q-22
AC-R5b-12	Per-box rules combine reported and computed counts; box 1 stays deferred unless the updated-review template is adopted, in which case it comes from amendment K's "previous review version" counts.	I	V2-04; Q-37; D4-11	pending-Q-37, pending-D4-11
AC-R5b-13	Reports count by report identity, with explicit coverage.	I	Amendment B; Q-23	pending-Q-23
AC-R5b-14	Current reports exclude withdrawn searches and say so; frozen reports never change.	I	Amendment J; Q-33	pending-Q-33
AC-R5b-15	Several reports of one study are linked for boxes 10 and 16 without merging extraction (amendment O).	I	D4-08	pending-D4-08
AC-R5b-16	Derived fields 31–34 accept no reported values, and identification uses an identified-at-source count when one is reported.	I	V2-13; Q-37	pending-Q-37
AC-R5b-17	Records imported after a step done outside SyRF count as having passed that step (an entry-phase rule per search or import).	I	V2-04; Q-37	pending-Q-37
AC-R5b-18	A study included at title/abstract, marked Not retrieved and never screened at full text appears in boxes 6 and 7 and not in box 8; retrieval lives in fullTextStatus, never in lifecycle status (amendment M).	C	SR-02; D4-07	pending-D4-07
AC-R5b-19	Report snapshots are computed from authoritative records (Citations, ExternalStepRecords, ScreeningOutcomes) at the report watermark and stored frozen; FEAT-024 rows and history are never report inputs.	I	MS-11, MS-22; programme integration	PROPOSAL
AC-R5b-20	Corrections and protocol amendments append; they never edit old report counts (amendment F).	I	Q-06b	pending-Q-06b
AC-R5b-21	An export preset lists full-text excluded studies with their primary reason and reviewer or reconciler provenance (the PRISMA 2020 item 16b near-miss list).	I	SR improvement 2; methodology coverage	PROPOSAL
AC-R5b-22	The methods summary (JSON and prose) is generated from the snapshot manifest only and reports eligibility (profile versions), information sources and strategies, the selection process (reviewers, independence, Unsure, conflict routes, calibration, agreement with its basis), data collection (targets, verify or reconcile), risk-of-bias templates, registration and amendments, the deduplication method and counts, external steps and retrieval failures.	I, V	SR improvement 1; methodology coverage	PROPOSAL
AC-R5b-23	A per-study Synthesis inclusion attribute (included; excluded with a reason such as no usable data or outcome not reported; not applicable) is set only through the Record synthesis inclusion capability, is exported, feeds box 17 (AC-R5b-06, FX-PRISMA-06e) and is never derived from extraction completion.	I, E	SR-20; C12; methodology coverage; A-03	PROPOSAL, assumption-A-03
AC-R5b-24	Where a project uses single screening, target-1 extraction without verification, or unverified imported decisions, the project overview and the PRISMA manifest show a persistent methods caveat label.	E, I	SR improvement 10; methodology coverage	PROPOSAL
AC-R5b-25	Field 32 (other_total_identified) equals field 29 (other_results), including records from Other sources.	C	SR-09; methodology coverage	PROPOSAL
AC-R5b-CONF	C12-T04 to T06.	C	review AC-01	PROPOSAL

Changes: AC-R5b-01, 02 and 07 rewritten; AC-R5b-08 to 25 new.

4.23 P1 Identification provenance

Tier T2, with a staging rehearsal for its floor step (Study root fields) · freeze F-P · entry: R0 floor step; X-DEL design join; X-IMPORT · fixtures FX-PRISMA-01 (P1 part) · seeds: PRISMA identification.

ID	Criterion	Verified by	Source	Status
AC-P1-01	New imports in admitted projects create immutable Citations carrying source type and source name (both nullable).	I	FEAT-011 release 1, phase 12 (DOC-APPROVED)	confirmed
AC-P1-02	Each study gets one downstream source column from its earliest import, with deterministic ties.	C	Amendment C (Q-06a)	confirmed
AC-P1-03	Retrieval status changes are recorded as append-only StudyLifecycleEvents with actor and time; an approved checked PDF records a retrieval event.	I	Plan P1; NS-08	PROPOSAL
AC-P1-04	Admins can classify the source type of searches imported before P1 (integration test plus journey); an unknown source stays unknown and is never guessed as Database.	I, E	Amendment C (Q-06a)	confirmed
AC-P1-05	Reported external identification and deduplication counts can be entered per search, with consistency warnings that never block.	E, I	Q-06a (Chris's request); amendment K; Q-37	pending-Q-37
AC-P1-06	Withdrawn searches keep their Citation history.	I	Amendment J (Q-06a)	confirmed
AC-P1-07	The SearchPopulation family gains source-type metric keys under a new family source version; retained history stays unlabelled; withdrawn searches are excluded by the family's enumeration rule.	I	MS-11; OPS1	PROPOSAL
AC-P1-08	FX-PRISMA-01 P1 assertions pass: two immutable Citations of one report; one earliest-source column; a later import changes identification counts only.	C	Amendment C; review AC-04	confirmed
AC-P1-09	An architecture test finds no Study status, state or lifecycle field, no SystematicSearch type or category, and no clash with planned PRISMA names.	U	FEAT-011 release 1 (DOC-APPROVED)	confirmed
AC-P1-10	Citations carry every raw field, and no code path updates a Citation (architecture test).	U, I	FEAT-011 phase 12 (DOC-APPROVED)	confirmed
AC-P1-11	A study-level Full text action records Sought (with date), Retrieved (PDF in SyRF, or read externally) and Not retrieved (reason from a controlled list plus free text; author-contact date) as append-only events with actor; a title/abstract collective Include sets Sought; attaching a PDF only suggests Retrieved.	I, E	SR-02; amendment M; D4-07	pending-D4-07
AC-P1-12	Linking a Citation to a Publication never rewrites the Citation: Publications are created at import from DOI or PMID, or the link is a separate record (amendment N).	I	V2-01; PRISMA amendments	PROPOSAL
AC-P1-13	In an admitted project, an accepted bibliographic correction from a study issue appends a correction event and never edits a Citation; from P2 it re-runs DOI and PMID matching.	I	NS-08	PROPOSAL
AC-P1-14	If approved, a protocol and registration record and search documentation fields (PRISMA items 6, 7 and 24; PRISMA-S) exist per project and search.	I, E	SR (protocol record); D4-05	pending-D4-05
AC-P1-15	External step records tied to a withdrawn search stay in history and leave current reports together with their search.	I	V2-13; Q-33	pending-Q-33
AC-P1-16	Withdrawing a search hides its Studies but keeps Citations and canonical evidence; deleting a whole project keeps ADR-014 removal with a tombstone.	I	PH-02; D3-12	pending-D3-12
AC-P1-17	A null sourceType is handled as its own "unknown" group in every count, export and filter.	I	FEAT-011 (DOC-APPROVED)	confirmed
AC-P1-18	Searches and external step records carry a search round (searchRound, with updateOf for an update search), and R5b reports identification per round; full updated-review support stays deferred.	I	SR-24; D4-11; methodology coverage	PROPOSAL
AC-P1-19	With Citation capture on, a 5,000-record import completes without a job timeout or a duplicate saga, and a 50,000-record import completes in staged mode with a heartbeat and resumes after a worker restart without duplicating studies (PROPOSAL sizes).	B, I, R	PH-09; programme integration	PROPOSAL
AC-P1-CONF	C12-T07, T08, T09.	C	review AC-01	PROPOSAL

Changes: AC-P1-03, 07 and 08 rewritten; AC-P1-09 to 19 new.

4.24 P2 Identification and deduplication

Tier T1 (staging rehearsal) · freeze F-P plus amendments D and L · entry: P1; R3b for the reviewed-record part · fixtures FX-PRISMA-01 (P2 part), FX-PRISMA-07a, FX-PRISMA-08a, FX-PRISMA-09 (if D4-08 is approved), FX-ASYSD · seeds: PRISMA identification.

ID	Criterion	Verified by	Source	Status
AC-P2-01r	ASySD parity: a pinned ASySD commit and R version in a container; named labelled datasets (licences recorded) and SyRF's seeded PRISMA pilot data; committed golden outputs; identical AutoConfirmed groups; ProbableDuplicate pair-set F1 ≥ 0.99; sensitivity and specificity published (SR-22 proposes "within 0.5 percentage points of the R package"); every divergent pair listed for review.	C	Amendment L; Q-37; review AC-21; SR-22; V2-12; D4-21	pending-D4-21
AC-P2-02	Stage 1 DOI and PMID matching completes within the import; Stage 2 fuzzy matching runs once per import and resolves PendingDedupCheck.	I	FEAT-012 (DOC-APPROVED)	confirmed
AC-P2-03	No study with review data is merged automatically; the admin queue shows each pair side by side with scores and review summaries.	I, E	FEAT-012; amendment D (Q-06a)	confirmed
AC-P2-04	Secondary studies are never deleted: scenario 1 sets Duplicate; a reviewed merge sets Merged with an alias; reversing a decision restores status, pool membership and any moved Citation links.	I	FEAT-012 (detailed steps); amendment L; V2-12	confirmed
AC-P2-05	A reviewed duplicate merge is an alias: Study.mergedInto plus a StudyAlias on the primary; immutable records are never re-keyed; when one reviewer reviewed both studies, the admin chooses the current session and the other is superseded with provenance and counted once; merges and splits run as ADR-020-style operations that write both Study documents, refuse busy studies and honour bulk-update locks; a split is a clean reversal.	C, I	Domain model; V2-02; DC-19; amendment D; D2-12	pending-D2-12
AC-P2-06r	The admission service and pool filters exclude Duplicate, Merged, PendingDuplicateReview, PendingDedupCheck, RemovedByAutomation and RemovedOther studies; only Active studies enter screening pools.	C	FEAT-012 §12; FEAT-011 (DOC-APPROVED); review AC-21; V2-12	confirmed
AC-P2-07	The box 3 count-consistency equation holds in every pinned read and frozen report, over Citations held in SyRF.	I	FEAT-012 §11.2; DC-19; V2-13	confirmed
AC-P2-08	A study becomes Included when every required profile (from the phase mapping) is Included.	I	C12; plan P2	PROPOSAL
AC-P2-09	FX-PRISMA-01 P2 assertions and FX-PRISMA-07a pass; every deduplication decision is in the audit log with confidence, source, actor and time, and audit entries are never deleted.	C, I	FEAT-012 §10; review AC-04	confirmed
AC-P2-10	DOI and PMID have unique sparse indexes on pmPublication; lifecycle enum values are exactly as specified.	I	FEAT-011 release 3 (DOC-APPROVED)	confirmed
AC-P2-11	Enrichment follows FEAT-012 §6 with per-field MetadataProvenance; cross-project data is bibliographic only.	C	FEAT-012 §6 (DOC-APPROVED)	confirmed
AC-P2-12	Scenario 2 follows amendment D (admin review when one study has review data); scenario 4 is restated by form and profile; "not duplicate" is never re-queued; Defer changes nothing.	C	FEAT-012 §7, §8; amendment D (Q-06a); domain model	confirmed
AC-P2-13	On Bramble, Stage 1 handles each 1,000-record batch within budget, and Stage 2 runs the 80,000-citation set in under an hour.	B	FEAT-012 §2.1; D4-21	pending-D4-21
AC-P2-14	A deduplication report export carries canonical mappings and confidence scores.	I	FEAT-011 phase 16 (EXP-06)	confirmed
AC-P2-15	Reading a Publication never exposes project or citation IDs from projects the caller can't access; enrichment is a listed Study writer whose changes as-of exports cover (FX-PRISMA-08a).	I	V2-03; PRISMA amendments	PROPOSAL
AC-P2-16	Study.citations[] is backfilled from re-parsed retained files or labelled "derived from current Study metadata"; full-text status, retroactive deduplication and the merge wizard work.	I, E	V2-06; FEAT-011; FEAT-012	PROPOSAL
AC-P2-17	A configurable share of AutoConfirmed groups (PROPOSAL default 5%, at least 20 groups) appears in the admin review queue for confirmation; a reviewer's "Flag as possible duplicate of…" action creates a duplicate review item; the deduplication manifest records the ASySD algorithm version, the tier rules version, the auto-confirmed versus reviewed share, reversals and the QC sample result (PRISMA-S item 16).	I, E	SR-19; SR improvement 6; methodology coverage	PROPOSAL
AC-P2-CONF	C1-T18; C12-T08, T10, T11.	C	review AC-01	PROPOSAL

Changes: AC-P2-01 and 06 retired and replaced by AC-P2-01r and 06r; AC-P2-04, 05, 07 and 09 rewritten; AC-P2-10 to 17 new.

4.25 C1 Populations and explicit classification

Tier T2 (a staging floor step if C1 adds embedded fields) · freeze F-C · entry: R2a; Q-19 · fixtures FX-PRISMA-06a, FX-CLASS · seeds: Classification and outcomes.

ID	Criterion	Verified by	Source	Status
AC-C1-01	Each study population has a system whole-population cohort, and every instance belongs to exactly one population.	I	C13	PROPOSAL
AC-C1-02	Enabling classification on a project with canonical answers changes no answer key.	C	C2; C13	PROPOSAL
AC-C1-03	A parent-subset or set annotation is stored on the parent or set with its evidence; disjointness and exhaustiveness are separate claims, so answering one never implies the other.	I	C13; V2-23	PROPOSAL
AC-C1-04	A shared concept is defined once per project and referenced by per-paper mapping answers; publishing a new project-rule version leaves earlier mappings pinned to the earlier rule version.	I	C13; V2-23	PROPOSAL
AC-C1-05	Compact cohort selection doesn't push the form down (U3 pass bar), and FX-PRISMA-06a assertions pass: populations and cohorts change neither the Study count nor metaAnalysisIncluded.	UT, C	C12; U3; review AC-04	PROPOSAL
AC-C1-06	Classification fields don't use lifecycle enum names.	U	FEAT-011 release 2 (DOC-APPROVED)	confirmed
AC-C1-07	Templates use verified identities (E14), and system types attach only when an extraction feature is used.	I	TC1	confirmed
AC-C1-08	Moving from category tabs to entity types keeps every question, answer and guidance reachable; the legacy category string becomes a display alias with no identity change.	I, E	C1 scope; VA-25	PROPOSAL
AC-C1-09	The Design capability publishes project rules; reviewers confirm per-paper applicability through mapping answers.	I	Q-19	pending-Q-19
AC-C1-10	Exports include populations, cohorts and mappings.	I	V2-24	PROPOSAL
AC-C1-CONF	C2-T06; C13-T01.	C	review AC-01	PROPOSAL

Changes: AC-C1-03, 04 and 05 rewritten; AC-C1-06 to 10 new.

4.26 C2 Inference and counts

Tier T3 · entry: C1; Q-18 · fixtures FX-CLASS, FX-PRISMA-06c.

ID	Criterion	Verified by	Source	Status
AC-C2-01	Implications such as Pregnant ⊆ Female apply without automatic strictness; inferred cohorts are suggestions, never written as reported answers.	C	C13	PROPOSAL
AC-C2-02	Counts are shown only with full support (60 = 25 + 35).	C	C13	PROPOSAL
AC-C2-03	Inferred cohorts show their outcome associations, conflicts show their supporting provenance, and an inference can be withdrawn.	E	C13	PROPOSAL
AC-C2-04	The first reasoner covers conjunction, containment, disjointness and exhaustiveness only.	C	Q-18	pending-Q-18
AC-C2-05	Inference results are a rebuildable projection, never authoritative; a rebuild gives identical results.	C	Domain model (InferenceResult)	PROPOSAL
AC-C2-06	FX-PRISMA-06c assertions pass: inferred cohorts change no count.	C	C13	PROPOSAL
AC-C2-CONF	C13-T02 to T05.	C	review AC-01	PROPOSAL

Changes: AC-C2-04 and 05 new; AC-C2-06 new (V3-09).

4.27 O1 Outcome schemas

Tier T2 (a staging floor step if O1 adds embedded fields) · freeze F-O · entry: R2a; Q-17 · fixtures FX-PRISMA-06b, FX-OUTCOME · seeds: Classification and outcomes.

ID	Criterion	Verified by	Source	Status
AC-O1-01	Legacy-compatible and event-count schemas exist, and projects can create and customise schemas.	I, E	OC1	confirmed
AC-O1-02	Each field's role, type, validators and cardinality are enforced on save.	C	OC1; E12	PROPOSAL
AC-O1-03	Each outcome measure has one versioned direction across cohorts, with no context override.	I, E	ODIR1	confirmed
AC-O1-04	The schema-selection question shows a fixed label when one schema is available and a selector when several are; published forms pin the allowed references.	E	RECOVERED (owner clarification, 27 September)	confirmed
AC-O1-05	The existing matrix, cell dialog and spreadsheet entry work with the new schemas; legacy export returns the typed "unsupported shape" result for new-shape data; FX-PRISMA-06b assertions pass (no metaAnalysisIncluded from extraction completion).	E, I, C	RD16; C14; review AC-04	PROPOSAL
AC-O1-06	Direction is never derived from numeric type and doesn't act as a validator.	C	OC2	confirmed
AC-O1-07	New-shape data round-trips through export and import.	I	O1 scope	PROPOSAL
AC-O1-08	Reviewers create outcome measures from the paper; admins never have to predefine them.	I, E	A-20	assumption-A-20
AC-O1-09	Event-count schema fields follow the domain specification.	C	Q-17	pending-Q-17
AC-O1-10	Observations can carry an "estimated from graph" provenance flag.	I	D4-10	pending-D4-10
AC-O1-11	Every observation records how its value was obtained (extractionMethod; linking a graph region defaults it to graph-estimated); units come from a vocabulary with a free-text fallback, and a measure whose series carry different units warns at Save and blocks binding at reconciliation until mapped; dispersion type comes from a catalogue (SD, SEM, CI, IQR, range, unknown); domain validators apply on Save (SD and SEM ≥ 0, n an integer > 0, events ≤ total, CI lower ≤ upper, quartile order); exports carry observation n and cohort n with nSource.	C, I	SR-06; methodology coverage	PROPOSAL
AC-O1-12	Per form, an extraction QC view counts graph-estimated observations, unit-mismatch warnings, SD/SEM flips corrected at reconciliation and missing n.	E, I	SR improvement 5; methodology coverage	PROPOSAL
AC-O1-CONF	C14-T01 to T03, T05, T06.	C	review AC-01	PROPOSAL

Changes: AC-O1-03 and 05 rewritten (reviewer-created measures moved to AC-O1-08); AC-O1-06 to 12 new.

4.28 O2 Outcome migration

Tier T1 (rehearsal on an authorised copy) · entry: O1; Q-05; separate execution approval; the P1 identity gate · fixtures FX-LEGACY (untouched defaults) · seeds: Legacy adoption rehearsal.

ID	Criterion	Verified by	Source	Status
AC-O2-01r	The dry-run runs under a read-only database role, so any write attempt fails; it produces a manifest with counts, checksums and unresolved records.	I, R	MIG1; review AC-34; Q-05	pending-Q-05
AC-O2-02	Untouched defaults (false direction, SD, mean, zero animals) are labelled "value or default (unknown)" unless an explicit answer is proven.	C	Q-05	pending-Q-05
AC-O2-03	Values are consolidated only within one author's series for one outcome, and conflicting directions block binding until reviewed.	C	ODIR1	confirmed
AC-O2-04	Cutover is fenced per project; before cutover, rollback routes back to intact legacy data; after it, only forward recovery applies.	R	Q-05; migration §5	pending-Q-05
AC-O2-05	Execution has its own approval, separate from the plan and from the dry-run.	G	MIG1	confirmed
AC-O2-CONF	C14-T04.	C	review AC-01	PROPOSAL

Changes: AC-O2-01 retired and replaced by AC-O2-01r; AC-O2-04 rewritten (split); AC-O2-05 new.

4.29 AL1 Shared-form allocation

Tier T2 · freeze F-A · entry: R2b; allocation phase 2 and X-AUTH-RESOLVER for reviewer validity; #3269's checklist · fixtures FX-ALLOC · seeds: Shared-form allocation.

ID	Criterion	Verified by	Source	Status
AC-AL1-01	Shares are computed once per shared form and are equal across its bound stages.	C	A-09 (lifted); OPS1	PROPOSAL
AC-AL1-02	No study is allocated twice through two stages.	C	OPS1	PROPOSAL
AC-AL1-03	Turning the flag off returns to refusing proportional shares for shared forms.	I	A-09	assumption-A-09
AC-AL1-04	Canonical session versions record the admitting allocation regime, as legacy sessions do today.	I	AP-16	PROPOSAL
AC-AL1-05	Reviewer validity on the form-scoped roster uses the out-of-request resolver; an invalid reviewer is never allocated.	I	AP-02, AP-16	conditional-X-AUTH-RESOLVER
AC-AL1-06	Changing a form's target while an active regime uses a different value is refused until the regime is updated.	I	AP-06, AP-16	PROPOSAL
AC-AL1-07	Regime schema v2 has a floor step one release ahead; an older binary refuses to start against an unknown regime schema version.	I, H	AP-10, AP-16	PROPOSAL
AC-AL1-08	The D8 slot rule over form-keyed claims gives the same answers as the stage-keyed rule for single-stage forms.	C	AP-16	PROPOSAL
AC-AL1-09	The allocation read APIs and the editor read the membership projection on canonical stages.	I	AP-15	PROPOSAL
AC-AL1-10	#3269's legacy-stage acceptance checklist is complete before F-A.	G	AP-23	PROPOSAL
AC-AL1-CONF	C7-T06 (lifted for allocated shared forms), C7-T10.	C	review AC-01	PROPOSAL

Changes: AC-AL1-04 to 10 new.

4.30 GA milestone

Tier T1 (milestone) · entry: the R2–R4 core piloted · evidence: every conformance test first required by a release that shipped before GA passes on the GA candidate.

ID	Criterion	Verified by	Source	Status
AC-GA-01	R2a to R2d, R3a to R3d, R4a and R4p have shipped and met their pilot exit criteria.	G	Plan §5.9	PROPOSAL
AC-GA-02	Guided setup parity is accepted (AC-R3d-01).	G	SET2	confirmed
AC-GA-03	Navigation and the editor behave correctly for both legacy and canonical projects, checked by a tester who holds both kinds of project; the workflow-version badge shows each project's mode.	E, UT	U27; UX-11	PROPOSAL
AC-GA-04	Help pages and the in-product "What changed" entries for every shipped release are published.	D	Plan §5.9; UX-09	PROPOSAL
AC-GA-05	The production prerequisites hold, including environment-wide enablement of the flags the canonical path needs, and new projects default to the canonical path.	G, E	Plan §5.9, §5.11; DS-04	PROPOSAL
AC-GA-06	At least one production opt-in pilot per family (R2, R3, R4a) meets PE-01 to PE-08.	G	review AC-33; A-23; D1-07	confirmed
AC-GA-07	The old setup wizard retires only after parity is accepted and the GA milestone is reached.	G, E	SET2	confirmed
AC-GA-08	A WCAG 2.1 AA audit of the canonical path passes.	A, G	D4-18 (answered 3 October, "independent of funders"; the recorded reading keeps the audit and is PROPOSAL until Chris confirms it in the G0 dossier)	pending-D4-18
AC-GA-09	Legacy screens' chrome and shared pages carry the Material 3 restyle, with no behaviour change.	V	UX-11; D3-06	pending-D3-06
AC-GA-10	Production publication counting at GA uses the materialised families activated on the agreed date (D1-03 chose activation of ProjectStatistics, #3987, not a freeze, so Q-31(b) authoritative counting doesn't extend to GA; Chris set the date on 3 October: from 5 October 2026 in staging, with production the following week as a target that keeps its own approval and waits for X-STATS-b1 to b7, decision register §1.14).	G	MS-01; D1-03	confirmed
AC-GA-CONF	Every conformance test first required by a release shipped before GA passes on the GA candidate.	C	review AC-01	PROPOSAL

Changes: AC-GA-05 rewritten (wizard retirement moved to AC-GA-07); AC-GA-06 to 10 new.

4.31 R6 Adoption waves

Tier T1 for every wave (staging and authorised-copy rehearsals) · entry: G-ADOPT per wave · fixtures FX-LEGACY · seeds: Legacy adoption rehearsal.

ID	Criterion	Verified by	Source	Status
AC-R6-01	Each wave's manifest is approved, and any source change invalidates it.	R, G	Migration §4	PROPOSAL
AC-R6-02	Every reader and writer of the adopted scope is canonical (scope completeness).	G	Migration §4	PROPOSAL
AC-R6-03	The shadow backfill is idempotent: reruns create nothing new.	R	Research A18	PROPOSAL
AC-R6-04	Semantic parity (decisions, outcomes, pools, exports, permission-filtered API output, statistics) is verified before cutover; statistics parity is automated only for families with a parity audit (ProjectScreening today) and labelled manual for the rest until #3845; FEAT-024's staged operation fence covers every family during shadow and cutover, with a rebuild under the new source versions afterwards.	R	MS-17	PROPOSAL
AC-R6-05	Cutover is all-or-nothing through ADR-020's lock, verify, stamp and release protocol: each Study is locked, verified, stamped with its CanonicalScopes marker and released with an Audit.Version bump; legacy writes are refused and retried during the window; in-flight writes finish or are refused with retries that keep drafts.	R	VB-07; consistency model	PROPOSAL
AC-R6-06	Legacy records become labelled current snapshots with coverage, never fabricated history; each wave has separate execution approval.	C, G	EX2; MIG1; research A17	confirmed
AC-R6-07	Adopted questions count as published, so QD1 applies to them.	I	QD1	confirmed
AC-R6-08	Adoption never promotes legacy single-reviewer work to gold.	C	Q-29	pending-Q-29
AC-R6-09	E10's labels ("membership-uncertain", "legacy-completed, unvalidated") appear in manifests and exports.	C	E10	PROPOSAL
AC-R6-10	Conflicting legacy duplicates adopt as a Conflicted head holding at least two unordered legacy-snapshot revisions with no current pointer until the reviewer resolves it with Fix or Save; meanwhile it is excluded from prefill and agreement.	C	VB-13	PROPOSAL
AC-R6-11	A LegacyIdAlias table remaps #3944 and #3945 references and exports; after cutover no saved link breaks.	I, E	VB-13; NS §5.3	PROPOSAL
AC-R6-12	An adopted answer pins "wording verified" when its stored Annotation.Question equals the v1 wording, otherwise unknown, which is excluded from same-version agreement.	C	VA-18	PROPOSAL
AC-R6-13	Wave manifests list conversations, study issues and inbox items.	R	NS §5.3	PROPOSAL
AC-R6-14	The stage target (override or inherited) becomes the form's target setting; the project threshold becomes the compatibility profile rule; an enabled legacy regime becomes a frozen record, with allocation disabled on adoption unless AL1 is live.	C, R	AP-13	PROPOSAL
AC-R6-15	Legacy screening is labelled by an admin-reviewed "legacy project screening" compatibility profile at adoption.	G, C	Q-21	pending-Q-21
AC-R6-16	Lifecycle status and screening outcomes are created per project at adoption from the approved manifest, with coverage labels; there is no platform-wide backfill.	C, R	Amendment G (Q-06a)	confirmed
AC-R6-17	An existing project can adopt the screening-profile scope after R3b without adopting its annotation scopes.	R	D4-16	pending-D4-16
AC-R6-18	At adoption, a search's source type is inferred only where evidence determines it, per project, and otherwise stays unknown.	C, R	FEAT-011 MIG-13; amendment G; V2-10	PROPOSAL
AC-R6-CONF	C2-T03 (Conflicted head part); C3-T04; C16-T01 to T08 re-run on each wave's candidate.	C	review AC-01	PROPOSAL

Changes: AC-R6-04 and 05 rewritten; AC-R6-07 to 18 new.

4.32 R7 Retirement

Tier T1 · separate approval.

ID	Criterion	Verified by	Source	Status
AC-R7-01	The consumer inventory is empty for every adapter retired.	G	Research A28	PROPOSAL
AC-R7-02	A restore rehearsal across collections passes: a whole-database point-in-time restore into an isolated database, with the consistency checker green and discontinuity records written.	R	DC-17; D2-13	pending-D2-13
AC-R7-03	Retention is approved, and retirement has its own approval.	G	Plan §5.9	PROPOSAL
AC-R7-CONF	The whole catalogue passes on the last image that still contains adapters.	C	review AC-01	PROPOSAL

Changes: AC-R7-02 rewritten.

4.33 External joins and their evidence

The programme integration document is authoritative for each join's owner and timing; this table names the evidence an activation or production gate checks.

Join	Needed by	Evidence checked	Rows
Per-project AF2 and shell admission (X-AF2)	R2a–R4 production pilots	AC-R2a-42 plus the AF2 owner's go/no-go	AC-ALL-12
X-STATS-a	R2c staging pilots	Usage family on, pilot projects allowlisted on both hosts, by FEAT-024 decision	AC-R2c-08
X-STATS-b1 to b7	R2c production publication	b1 gate (b) idle-host pass; b2 soak (#3510, #3952); b3 production pending index built in an approved window; b4 production rollout approval lifting the in-code refusal; b5 production allowlist or eligibility for pilots; b6 usage family built; b7 its staging proof	AC-R2c-08, AC-GA-10
X-ELIG	R3a production admission	AC-R3a-33	AC-R3a-03
X-CLAIMS	Any production reliance on claims or capacity	AC-R2b-14, AC-T-01 to 09	AC-ALL-12
X-RECLAIM (internal to the reconciliation stream)	R4a everywhere	AC-R4a-36, 37	—
X-AUTH-SCHEMA, X-AUTH-ENFORCE, X-AUTH-WP9	R1c; explanations in R1b	Production migration evidence; cutover or parity tests; explanation-equals-enforcement contract test	AC-R1b-08, AC-R1c-05
X-AUTH-RESOLVER	Per-reviewer Monitor rows (R3a); AL1	Resolver merged and consumed	AC-R3a-09, AC-AL1-05
X-BATCH	Batches in R3c	AC-R3c-17	AC-R3c-05
X-NOTIF	Notices in R1c, R2c, R3c, R4a, R4b	Steps 1 to 5 of the D1-09 merge order merged with flags off	AC-R1c-04, AC-R4a-41
G-NOTIF	Any notification enablement	AC-ALL-29	AC-ALL-22
X-DEL	Search withdrawal in P1	Agreed reversible-deletion design	AC-P1-16
X-AF2-PR9	R4c	Merged code	AC-R4c-03

4.34 Production enablement steps

Every release names how it reaches production users and what evidence that step needs (DS-04). Until a step's evidence exists, the release stays on staging and preview (Q-25).

Release	Production enablement step	Evidence
R1a	The new editor becomes the default entry point for legacy projects once the coexistence design defines its two modes	Staging acceptance; flag decision; AC-R1a-07
R1b	Owner-only enforcement is live on merge (security fix); the Members & groups page flag turns on after staging acceptance	AC-R1b-01 to 07
R1c, R1d	Enabled per environment after the authorization joins	§4.33 joins
R2a to R2d	Opt-in pilot projects admitted through R0 with per-project AF2 and shell admission (AC-R2a-42), under D1-07	AC-ALL-12; PI rows
R2c	Production publication only under X-STATS-b or Q-31(b)	AC-R2c-08
R3a to R3d	As R2, plus X-ELIG for production admission	AC-R3a-33
R4a to R4c	As R2, with the task editor claim; X-CLAIMS only where capacity promises apply	AC-R4a-36, 37; AC-R2b-14
R5a to R5c, P1, P2, C1, C2, O1, AL1	Per admitted project after staging acceptance	Activation record
Notifications (any release)	Per environment and kind family under G-NOTIF	AC-ALL-29
GA	Canonical default for new projects	AC-GA-01 to 10

4.35 Claims and tracking prerequisites (X-CLAIMS)

ID	Criterion	Verified by	Source	Status
AC-T-01	A reviewer working continuously for over 30 minutes sees no expiry UI; a network drop under 10 s changes nothing; reconnecting within the grace period, even through another API pod, cancels the scheduled removal; reconnecting after the grace period with the study full shows the refusal and keeps the draft recoverable.	E	RT §5.2	PROPOSAL
AC-T-02	Stale scheduled deliveries (an old suspension baseline, an old idle generation, an old stage-keyed command shape) do nothing after a reconnect or a deploy.	I	RT §5.2	PROPOSAL
AC-T-03	A rolling restart of every API pod with 50 active reviewers (PROPOSAL) loses and duplicates no claim, clears orphaned connections within 2 minutes and produces no burst of 503 responses.	R	RT §5.2	PROPOSAL
AC-T-04	The previous web bundle keeps working through the declared window; then MinUiVersion forces a reload.	R	RT-11	PROPOSAL
AC-T-05	After rolling the image back to the recorded minimum, with form claims and canonical sessions present, capacity guards and pool filters are still correct.	R, H	RT-07	PROPOSAL
AC-T-06	A lost scheduled message can't hold a place beyond the backstop horizon (an absolute lease expiry, or a backstop sweep behind its own flag).	I	RT-24	PROPOSAL
AC-T-07	With 300 connections across 2 replicas, 30 s heartbeats and a burst of 20 joins per second, join and save p95 stay within budget, the Quartz backlog stays flat and no claim is duplicated (PROPOSAL numbers).	B	RT §5.2	PROPOSAL
AC-T-08	Presence sent to someone who doesn't hold the claim carries counts plus their own claim only; names go only to Monitor-capability holders; nothing crosses reconciliation blinding.	I	RT-14; D3-20	pending-D3-20
AC-T-09	The production claims route is a binding-scope tracking setting (#3876 reshaped), enabled per admitted pilot project and for legacy projects that opt in; a shared form is tracked if any bound stage is; API and PM switch together.	I, G	RT-02, RT-03; D3-16	pending-D3-16

4.36 Lanes awaiting a Batch D decision

X1 Analysis-ready exports: tier T3 · freeze F6a · entry: O1, R4c, R5a; F6a (C11); D4-09 · fixtures FX-OUTCOME, FX-X1 · applies only if Chris approves D4-09.

ID	Criterion	Verified by	Source	Status
AC-X1-01	The comparison-level export (gold by default, candidates optional) gives one row per comparison and timepoint, pairs cohorts by Experiment membership and control flags, flags a control serving several treatment cohorts as sharedControl, carries the dispersion type unconverted, defaults to collectively Included studies (AC-R5a-10), and matches the FX-X1 fixtures.	C	SR-08; D4-09; methodology coverage	pending-D4-09
AC-X1-02	A RIS export of any study set (included; excluded with reason; duplicates; not retrieved), built from Citation raw fields, re-imports into EndNote and Zotero without losing raw fields.	E	SR-08; D4-09	pending-D4-09
AC-X1-03	Every export ships a machine-readable codebook (question identity, version, wording, options, semantic role, entity scope, requiredness) with per-answer answeredUnderVersion and qualificationPolicy.	I	SR improvement 8; SR-16; D4-09	pending-D4-09
AC-X1-CONF	C11-T01 to T05, re-run on the comparison export.	C	review AC-01	pending-D4-09

If Chris approves D4-14 (an answer-import lane after R2a, from FEAT-004) or D4-15 (routing studies by answer values after R4a), that lane's brief adds criteria here under its own release ID. They start from floors this page already states: imported answers carry provenance Imported (source system, import job, mapped reviewer), count toward a target only when mapped to a SyRF reviewer and declared independent, are excluded from default independence statistics, never become gold automatically and pin the current question version, as AC-R3a-30 does for screening decisions; routing reads gold values or collective outcomes only, never one candidate's answers.

Changes: new section; AC-X1-01 to 03 new.

4.37 Retired IDs

These IDs are retired and never reused. Reviewer-proposed IDs that this revision renumbered (listed as aliases in the resolution record) were never live and are not reserved.

Retired	Replaced by	Why
AC-R5a-02	AC-R5a-02r	"Identical" ignored generation metadata and unversioned datasets (review AC-34, DC-13)
AC-O2-01	AC-O2-01r	"Read-only" was unproven; a read-only database role now proves it (review AC-34)
AC-P2-01	AC-P2-01r	The parity tolerance couldn't be computed (review AC-21, D4-21)
AC-P2-06	AC-P2-06r	The excluded-status list was incomplete (review AC-21, V2-12)
PE-04	PE-04r	Synthetic fixtures on pilot data are replaced by the invariant monitor (review AC-16)

5. Pilot entry, pilot exit and user testing

5.1 Pilot exit criteria

ID	Criterion	Verified by	Source	Status
PE-01	No lost or silently changed work across the pilot: INV-01, INV-02 and INV-09 report no violation, and every reported loss is traced to a typed cause, none of them the engine.	M, S	Invariants 1, 2, 9; review AC-16	PROPOSAL
PE-02	No permission, blinding or privacy leak: the AC-ALL-19 probe suite passes against the pilot projects' data in the pilot environment, telemetry shows no disclosure anomaly, and no tester or reviewer reports one.	C, M, S	Invariant 10; review AC-16; V2-23	PROPOSAL
PE-03	No open Sev-1 or Sev-2 defect (PE-07); every Sev-3 defect is triaged with an owner.	G	Plan §9	PROPOSAL
PE-04r	The invariant monitor reports zero violations on the pilot projects, nightly, for the whole pilot.	M	review AC-16	PROPOSAL
PE-05	AC-UX-01 and AC-UX-02 are met for every user-testing task of the release (§5.3), with each "explain" answer scored against its rubric.	UT	UX-01; review AC-29	PROPOSAL
PE-06	Minimum exposure, overridable per release at its freeze gate: at least 2 projects, at least 3 reviewers in each, at least 50 studies with two or more completed contributions, and at least 10 working days.	S, M	review AC-16	PROPOSAL
PE-07	Severity definitions. Sev-1: lost or silently changed work, a disclosure leak, or a wrong authoritative outcome. Sev-2: a wrong count or status, or a blocked task with a workaround. Sev-3: cosmetic.	G	review AC-16	PROPOSAL
PE-08	For releases that enable notifications in the pilot, no notice or email reaches a user outside the admitted pilot projects (inbox and Mailpit checked).	I, M	NS §5.3	pending-D3-21

Changes: PE-01, 02 and 05 rewritten with measurement; PE-04 retired and replaced by PE-04r; PE-06 to 08 new.

5.2 Pilot entry conditions

Plan §5.10's conditions are written here as entry rows; a pilot starts only when its rows hold.

ID	Entry condition	Source	Status
PI-ALL-01	The release's automated activation rows pass on the release candidate; the telemetry dashboard (AC-ALL-20) and the invariant monitor (AC-ALL-21) run in the pilot environment.	review AC-16; §8.2	PROPOSAL
PI-ALL-02	Seeds are deployed additively; pilot projects are admitted through R0's admission service by an audited action; the testers are named and booked.	Q-07; D1-06 (panel shape approved; names given on 3 October, decision register §1.14; no external SyRF users named yet)	confirmed
PI-ALL-03	The rollback and containment plan is recorded: the minimum image, and what reviewers and admins see if the pilot becomes read-only (U28).	Plan §9 item 7	PROPOSAL
PI-ALL-04	A production pilot starts only with AC-ALL-12 evidence and under D1-07; until then pilots run on staging and preview only.	Q-25; D1-07	confirmed
PI-ALL-05	Notifications are enabled in a pilot only under G-NOTIF (AC-ALL-29).	NS-04; D3-21	pending-D3-21
PI-R2a-01	Forms are target-1 or their reconciliation can wait until R4a; target-1 exports are labelled "single reviewer, unreconciled".	Plan §5.10; Q-29	pending-Q-29
PI-R2a-02	One stage per form.	A-21	assumption-A-21
PI-R2a-03	One form per entity category.	A-19	assumption-A-19
PI-R2a-04	Used forms needn't change before R2c.	A-14	assumption-A-14
PI-R2a-05	Project 0102 ("Ready for Annotation", FEAT-024's staging pilot) stays out until the canonical-commit-with-statistics fixture (C8-T07) passes.	MS-10; D3-10	pending-D3-10
PI-R2b-01	No proportional shares on shared forms, and no allocation on canonical stages.	A-09; D3-13	assumption-A-09, pending-D3-13
PI-R2b-02	Stages bound to one form have identical stage-owned settings, or Q-28's interim rule applies.	Q-28	pending-Q-28
PI-R2c-01	Staging pilots meet X-STATS-a; preview pilots use Q-31(b) authoritative counting.	MS-10; D3-10	pending-D3-10
PI-R3a-01	Conflicts resolve through extra votes (eligibility D1 and D2, Allow); a pilot using Stop on a profile that feeds a cross-stage route accepts that conflicted studies wait for R4p.	Plan §5.10	PROPOSAL
PI-R3a-02	Eligibility is enabled in the pilot environment; production admission needs X-ELIG (AC-R3a-33).	AP-09; D3-09	pending-D3-09
PI-R3b-01	Multi-profile statistics are served live.	MS-08; D3-10	pending-D3-10
PI-R3c-01	Batches are used only with X-BATCH evidence (AC-R3c-17).	AP-05	PROPOSAL
PI-R4a-01	The task editor claim is live; any production capacity promise also needs X-CLAIMS.	RT-01; D3-16	pending-D3-16
PI-R4a-02	Conversations are enabled only after #3965's Q-10 changes have merged, in the D1-09 order.	Q-10; D1-09	confirmed
PI-R4c-01	X-AF2-PR9 has merged.	Plan R4c	PROPOSAL
PI-R5b-01	P1, P2, R3b and R4p have shipped, and the F6b answers (Q-06b, Q-22, Q-23) are recorded.	Plan R5b	PROPOSAL
PI-P2-01	ASySD parity (AC-P2-01r) has passed.	D4-21	pending-D4-21
PI-AL1-01	#3269's legacy-stage checklist is complete (AC-AL1-10).	AP-23	PROPOSAL

5.3 User-testing tasks, rubrics and pass bars

Pass bar for every task: AC-UX-01 (at least 80% complete without help) and AC-UX-02 (at least 80% give an explanation containing every point in the rubric). Tester numbers follow D1-06 (approved 3 October: five named CAMARADES reviewers or administrators for T1 releases, three elsewhere, with at least two external SyRF users where possible). Chris named the panel late on 3 October (decision register §1.14): for T1 releases Gillian Currie, Alexandra Bannach Brown, Francesca Tinsdeall, Chris Sena and Nadia Soleman; for the rest Gillian Currie, Alexandra Bannach Brown and Francesca Tinsdeall. No external SyRF users are named yet. Sessions are batched monthly across neighbouring releases (DS-16). The UX strategy owns the protocol and may refine tasks and rubrics.

How an explanation is scored: each rubric lists two or three key points, recorded in the session protocol before the session. The facilitator asks once ("Tell me what you see and why") and may prompt once ("Anything else?"). Two observers score each point present or absent; the tester passes when every point is present and nothing contradicts it. Observers settle disagreements from the recording or notes. Sessions use the seeded or open-licence realistic-content projects, and notes never contain study content.

Release	Task the tester completes and explains	A correct explanation names	Testers
R1a	Import two question templates with a parent and a lookup, then explain what changed in the project	The parent and lookup were remapped; the copies won't change when the templates do	3
R1b	Say who can do what in a project, and why	The grant's source (group, stage or owner); which actions are owner-only	3
R1c	Create a group with a stage grant and predict what a member can do	The group's scope; the anti-escalation rule; ChangeOwner is never grantable	3
R1d	Delegate permission administration and predict what the delegate can grant	The envelope's limits; never ChangeOwner	3
R2a	Edit, save and complete a session; say which version counts and why; recover a two-tab conflict	The latest explicit Save or Complete counts; autosave doesn't; a Save after Complete removes the completed contribution; the other tab's edits are kept as a conflict copy	5
R2b	Open the same study from two stages and explain the count	One session per form; counted once in each stage	3
R2c	Predict a publication's impact on completed, saved-incomplete and draft-only sessions before publishing	For each category, what happens under the chosen treatment (pass bar applies per category)	5
R2d	Fix an outdated session and say why it was flagged	Their own newer answer elsewhere; Fix creates an incomplete version; a warning alone keeps Complete	3
R3a	Say why a study is offered or locked at a step; screen 20 studies by keyboard	The gate or dependency and its state; no personal vote is revealed	5
R3b	Say what a screening decision rests on; set up a title/abstract → full-text route	The triggering criteria and own answers; the decision counts only on submit	3
R3c	Approve a pending change to a Completed stage you were alerted to, predicting its effect	Which stages reopen; nothing changes before approval	3
R3d	Set up a project from templates, then resume a saved setup draft	Task completion and time (AC-UX-07)	5
R4a	Reconcile a study with three candidates and say why the gold answer is what it is; find work assigned to you in a project you haven't opened	Every candidate was used; prefill only on exact agreement; Complete accepted the displayed answers	5
R4p	Adjudicate a decision with conflicting reasons	Decision agreement and supporting-answer agreement are separate; adjudication adds no vote	3
R4b	Raise a query and find its outcome	Gold stays effective while queried; you see only your own outcome	3
R4c	Reconcile outcome series from three candidates	Direction is reconciled once per measure	3
R5a	Download an as-of export and explain its coverage labels	Versioned, current-only and not observed	3
R5c	Explain independent versus informed figures	Informed means after viewing accepted answers or being questioned	3
R5b	Read the PRISMA diagram, including reported external counts	Which numbers are reported and which computed; the "not yet screened" remainder	3
P1	Enter external deduplication counts and explain the warning	Identified at source minus removals should equal imported records	3
P2	Resolve a duplicate pair	Which study is primary; nothing is deleted; the decision is reversible	3
C1	Select cohorts for an outcome without losing your place in the form	Task completion and time	3
C2	Accept or withdraw an inferred cohort and say when a count is shown	A count appears only with full support	3
O1	Create an outcome measure and choose its schema	One direction per measure	3
AL1	Configure shared-form allocation and say why both stages show the same shares	One plan per shared form	3

5.4 UI validation pass bar

A UI validation (U1 to U29, and the new U items in the UX strategy) passes when, on its prototype, at least five participants per affected role (at least two from outside CAMARADES where possible, D3-08) meet AC-UX-01 and AC-UX-02 for its tasks, and no Sev-1 usability issue remains (a misread authoritative state or a risk of losing work). Each validation is scheduled at least one window before the build that consumes it, and each freeze gate's exit evidence lists the validations that passed (UX-03). Status: PROPOSAL.

6. Pilot projects and seeded test data (Q-07)

Chris, 3 October 2026 (Q-07): pilots run on new projects and on the seeded projects in the staging and preview environments; seed projects may be added where helpful.

6.1 Test-data tiers

Tier	What	Where	Built by	Used by
DT1 Code fixtures	The FX-* JSON corpus (§7) and builders	src/libs/testing/SyRF.Testing.Common/	S0 harness (E99)	U, I, C
DT2 Scenario builders	API-driven, with per-test unique IDs; canonical states built by a test-only scenario endpoint in the e2etest environment that calls canonical commands, never raw database writes	Hermetic e2e stack	L17-12	E, X
DT3 Human-acceptance seeds	The seed projects in §6.3, created by the seed-if-absent job (AC-S0-06)	Preview and staging	E97; D3-14	S, UT
DT4 Benchmark datasets	RV-DS-01 to 05 on FEAT-024's generator and seeds, at the D1-08 tiers: typical (50 questions, 100 pins), p99 (340 questions, 1,000 pins), max (2,023 questions, 5,000 pins, 50 instances per category)	Bramble	E98	B
DT5 ASySD golden outputs	Generated once in a pinned R container from labelled datasets, licences recorded	Repository test data	P2 stream	C

Dataset	Basis	Shape	Serves
RV-DS-01	FEAT-024's PS-DS-01	PS-DS-01's project shape with one canonical form at the typical tier	S0 baseline, M0
RV-DS-02	PS-DS-02	PS-DS-02's shape with a p99-tier form bound to two stages	M0, R2a, R2c
RV-DS-03	PS-DS-03	25,000 studies, 25 reviewers, 8 stages, as PS-DS-03, with canonical forms	M0, R2c, R5c
RV-DS-04	E28	The max-form case (2,023 questions; 5,000 pins per session version)	M0, R2a
RV-DS-05	FEAT-007 and FEAT-008 metric	100,000 studies with profile and route filters and 2,500 batches	R3a, R3c

Dataset IDs and shapes are PROPOSALs fixed in S0; FEAT-024's dataset table is in docs/features/materialized-project-statistics/phase0-benchmark-and-capacity-baseline.md.

6.2 Personas

Today the e2e stack has three users (e2e/setup/auth.setup.ts): admin (SyRF Seed Bot, roles administrator and SyrfAdmin), reviewer (Alpha) and standard (Beta). Application-admin bypasses distort project-permission tests, so the persona set below lands in S0 (AC-S0-05). GUIDs are proposals fixed at S0 in auth.setup.ts and e2e/helpers/constants.ts.

Persona	Purpose	e2e user	Application roles
SyrfAdmin	Application-admin paths only, plus one negative test per blinded surface	Existing admin (…0001)	administrator, SyrfAdmin
Owner	Owner-only paths (transfer, delegation); never an application admin	New (…0020)	none
Project admin, not owner	Admin-not-owner refusals; publication and settings	New (…0021)	none
Reviewer A	Candidate	Existing reviewer, Alpha (…0010)	none
Reviewer B	Candidate	Existing standard, Beta (…0011)	none
Reviewer C	Third candidate	New, Gamma (…0012)	none
Reviewer D	Fourth candidate	New, Delta (…0013)	none
Reconciler	Never a candidate on the studies they reconcile	New (…0022)	none
Extra reviewer	RA5 requested reviewer	New (…0023)	none
Observer	View-only member	New (…0024)	none
Query raiser	Raises queries	New (…0025)	none
Query reviewer	Holds the query-review capability	New (…0026)	none
Support impersonator	Support edit-mode and impersonation paths	New (…0027)	The support or impersonation role in use today

On staging, human testers log in as themselves: the seed-if-absent job grants the named tester accounts (D1-06) the persona memberships in seed projects. There are no shared credentials.

6.3 Seed projects

Existing seed projects (docs/platform/enhanced-database-seeding.md): Quick Start Demo, Screening In Progress, Ready for Annotation (project 0102, FEAT-024's staging pilot, kept out of R2a–R3a pilots under PI-R2a-05), Complete Review and Private Research, with the Seed Bot owner and the Alpha and Beta reviewers.

Proposed seed projects, each delivered with the release it serves:

Seed project	Contents	Serves
Versioned forms, one stage	A form with sessions in every state (completed, saved-incomplete, draft-only, drafts over explicit versions) under v1, bound to one stage	R2a
Shared forms, two stages	Form F (target 2) bound to stages A and B with sessions reached from both; an overlapping form G under the same entity category; incompatible question versions across the two forms	R2b, R2c, R2d
Workflow routing	Title/abstract → combined full text → extraction steps; Pending, Conflict, Included and Excluded studies; Allow and Stop settings; batched and early-stopped variants	R3a, R3b, R3c
Reconciliation, four candidates	Studies with three and four completed candidates; disagreements; entity-matching cases; a target-1 form; legacy reconciled answers; an explicit assignment; a requested extra review; a queried answer	R4a, R4p, R4b
Classification and outcomes	Populations and cohorts; an implication (Pregnant ⊆ Female); event-count outcomes; several measures with directions	C1, C2, O1, R4c
PRISMA identification	Searches of every source type plus one unknown legacy source; cross-search duplicates, including reviewed duplicates; a search with reported external deduplication counts; retrieval statuses	P1, P2, R5b
Legacy adoption rehearsal	A synthetic legacy-shaped project with cross-stage answer overwrites, legacy reconciled answers, untouched outcome defaults, missing timestamps, conflicting duplicates, and v0 and v1 system questions	R6 and O2 dry-runs
Realistic content	An open-licence reference set of real abstracts (licence recorded) for the UX baseline and summative sessions	UX baseline, R2a, R3a
Shared-form allocation	Legacy and canonical stages with allocation regimes	AL1

6.4 Rules

• Seeds are additive and idempotent, keyed by fixed GUIDs, and contain no real user, clinical or participant data.
• Canonical seed projects are created through canonical commands after R0 admits them. The legacy seeder (application services) creates only legacy-shaped seeds, because from R0 it is a legacy writer that refuses canonical scopes.
• Preview and staging receive seeds through the seed-if-absent job (AC-S0-06), separately from ownership reconciliation. It never drops or edits existing data and never runs the operator reseed procedure, so tester-created pilot projects survive.
• Each seed project documents the releases, fixtures and personas it serves.
• New pilot projects are created by CAMARADES testers on staging for each release.
• In production, a new project joins a pilot only after the production prerequisites hold; until GA, only when its creator opts in at creation (A-23) and under D1-07.
• Existing real projects stay on the legacy path until adopted in R6.

7. Fixtures, invariants and conformance tests

7.1 Fixture format and location

• Each fixture is a versioned JSON file under src/libs/testing/SyRF.Testing.Common/ (a corpus folder per family; the folder name is settled in S0, E99) with: id, version, title, sourceRefs (decision, research and specification IDs), inputs (entities and canonical commands, in order) and assertions keyed by release ("R2a": [...]).
• Inputs change only with a version bump. Assertions per release are append-only. A release can't pass with an empty assertion set for a fixture assigned to it.
• xUnit theories and Vitest describe.each read the same files; the DT2 scenario endpoint builds the same inputs for e2e journeys. For the applicability and admission corpora, a seeded generated corpus (fixed, recorded seed) is diffed across the .NET and TypeScript evaluators (review AC-31).
• Timing (review AC-04, V3-10): every family, PRISMA included, is written by the freeze gate of its first release; for the PRISMA fixtures the release is the part's Release column in §7.2. So the parts first used by R2a (02a, 04a) and R2b (02b) are written by F1a; R2c (04b) by F2; R3a (03a, 03b) and R3c (04d) by F3; R4p (03c) by F4; R3b (02c, 04c) by F5; R5a (05a) by F6a; R5b (01 R5b, 02d, 03d, 04e, 05b, 06d, 06e, 07b, 08, 08b) by F6b; P1 and P2 (01 P1, 01 P2, 07a, 08a, 09) by F-P; C1 and C2 (06a, 06c) by F-C; and O1 (06b) by F-O.

7.2 PRISMA fixtures by release

The eight fixtures come from the PRISMA compatibility review. Fixtures 3 and 4 are split by release, so each part is testable when it first applies (V2-07). FX-PRISMA-09 comes from the methodology coverage for amendment O and applies only if Chris approves D4-08.

Part	Release	Evidence assertion	Source
FX-PRISMA-01 P1	P1	Two immutable Citations of one report; one earliest-source column; a later import changes identification counts only; distinct-report and same-report imports are tested separately; an unknown legacy source stays unknown.	Amendment C
FX-PRISMA-01 P2	P2	Stage 1 finds the duplicate; the secondary is kept as Duplicate; box 3 counts SyRF-detected duplicates; no report, study or animal units are mixed.	FEAT-012; amendment L
FX-PRISMA-01 R5b	R5b	Box values, including reported external parts and source columns.	Amendment K
FX-PRISMA-02a	R2a	One form, one stage: one qualifying contribution per reviewer per study and form; repeated Saves add none.	SF2
FX-PRISMA-02b	R2b	One form bound to two stages: one contribution, counted once in each stage's progress; repeated pool evaluations and personal batch grants add no screened units.	SF1; SF2
FX-PRISMA-02c	R3b	The same profile in two stages: one effective decision per profile per reviewer; different profiles stay independent.	DP4
FX-PRISMA-02d	R5b	Screened-unit counts equal unique studies, never stage sums.	PR1
FX-PRISMA-03a	R3a	Own Include with collective Pending opens permitted within-stage extraction with no collective Included; cross-stage work is blocked under the default and admitted under the advanced option; collective Exclude blocks new dependent work while EW1 governs saved work; PR1 holds; one current ScreeningOutcome per profile; StudyEnteredPool entries carry versions.	DP6; DP7; PR1; EW1
FX-PRISMA-03b	R3a	Early-stopped and batched reviews: pool entry is the first release to anyone; shared openings and personal grants are recorded separately; re-evaluation reproduces membership.	Amendment A; D3-13
FX-PRISMA-03c	R4p	Pending reason coverage becomes adjudicated coverage; the collective Exclude veto holds while reasons are pending; adjudication adds no vote.	RX1
FX-PRISMA-03d	R5b	The current or preliminary report exposes reason coverage and pinned decision sources.	Amendment E (Q-06b)
FX-PRISMA-04a	R2a	A Save after Complete removes the qualifying contribution; autosave alone doesn't.	SL3
FX-PRISMA-04b	R2c	A publication with sessions in all three categories: qualifying counts per version follow the recorded policy.	FV2; FV3
FX-PRISMA-04c	R3b	A profile publication: decisions under the prior profile version follow the chosen treatment.	Q-26
FX-PRISMA-04d	R3c	Unresolved applicable work blocks automatic readiness; a protected correction or new arrival needs confirmation, then the automatic or manual transition follows.	LC1
FX-PRISMA-04e	R5b	An earlier PRISMA snapshot is unchanged after every step above.	Amendment J
FX-PRISMA-05a	R5a	An as-of export reproduces the pre-correction state where history exists and labels coverage where it doesn't.	EX1; EX2
FX-PRISMA-05b	R5b	Correcting Exclude to Include, amending a profile or filter, changing retrieval status and reversing a dedup decision each append events and provenance; old as-of counts reproduce; missing legacy history gives a coverage status, never a reconstruction.	EX2; amendment F
FX-PRISMA-06a	C1	Populations and cohorts change neither the Study count nor metaAnalysisIncluded.	C12
FX-PRISMA-06b	O1	Outcome assignments and a custom schema change neither; completing extraction never sets metaAnalysisIncluded.	C12
FX-PRISMA-06c	C2	Inferred cohorts change no count.	C13
FX-PRISMA-06d	R5b	Box values are unchanged.	PR1
FX-PRISMA-06e	R5b	Box 17 comes only from the Synthesis inclusion attribute, never from extraction completion.	SR-20; C12
FX-PRISMA-07a	P2	Originals are kept; the admin's identity mapping is an alias; conflicts are flagged; one contribution is counted; no automatic double target count or gold promotion.	Amendment D; domain model
FX-PRISMA-07b	R5b	The reviewed duplicate counts once in the report.	Amendment D
FX-PRISMA-08a	P2	A cross-project Publication lookup exposes no foreign project or citation IDs (moved from R5b).	V2-03
FX-PRISMA-08	R5b	A stale statistics state or rewrite lock gives a consistent manifest or an explicit retry; concurrent snapshot generation never mixes epochs; a revocation leaks no candidate data.	PRISMA review fixture 8
FX-PRISMA-08b	R5b	An early-stopped batched review satisfies the arithmetic identities, with the "not yet screened" remainder shown.	SR-09
FX-PRISMA-09	P2 (if D4-08 is approved)	Two reports linked to one study: one study and two reports in box 10; an excluded companion report stays in box 9 (amendment O).	D4-08; methodology coverage

7.3 Other fixture families

Family	Contents	First release	Source
FX-ACCESS-01 to 10	01 within-stage own Include opens the next step while the collective decision is Pending; 02 cross-stage locked by default; 03 advanced personal cross-stage opens; 04 strict within-stage waits (pending Q-01); 05 collective Exclude blocks each new route without deleting extra work; 06 PRISMA stays Excluded with completed extraction; 07 a prerequisite self-cycle is rejected; 08 a personal Exclude is never silently overridden; 09 EW1 saved completion is preserved; 10 a changed published policy is rechecked at transactional admission	R3a (04 in R3c)	docs/planning/review-stage-step-access-policy-proposal-2026-10-03.md
FX-LIFE-01 to 10	01 readiness counts unresolved applicable drafts and corrections; 02 abandonment is never inferred, and discard is explicit and audited; 03 a change to a Completed stage becomes a pending request, with nothing committed before approval; 04 approval covers that change only; 05 approval never grants the initiator authority; 06 commit rechecks permission, expiry, source hashes and stage state, and changed inputs invalidate approval; 07 shared work needs approval for every affected Completed stage, all or none; 08 automatic mode commits the change and Active status in one transition record; 09 manual mode needs an explicit Reopen; 10 new arrivals take the same gate	R3c	docs/planning/review-lifecycle-gold-settings-proposal-2026-10-03.md; Q-02
FX-SETUP-01 to 13	01 profile copies stay independent; 02 a later template change doesn't alter local configuration; 03 parent and lookup imports survive ID remapping; 04 cross-project dependencies are denied; 05 privacy, contact, name, keywords and protocol fields survive the replacement; 06 the old create entry uses the new flow without duplicate creation; 07 navigation and manual setup are preserved; 08 disabled living-search and ML behaviour is preserved; 09 an empty project creates no PRISMA records or reports; 10 extraction off adds no unused mandatory types; 11 an interrupted draft setup resumes; 12 publish honours impact gates; 13 the ordinary editor and category UI still work without the wizard	R1a (02 to 04), R3d	docs/planning/review-guided-setup-template-plan-2026-10-03.md
FX-PUB	Policy-combination table: per-question treatments × per-category treatments × compatible or incompatible changes × added and removed questions, with expected qualifying counts per version	R2c	FV2; FV3; VA-14
FX-PUB-10K	10,000 sessions across v1 to v3 and two stages, split 60/30/10 completed, saved-incomplete and draft-only, 5% with drafts over explicit versions; variants at 1,000 and 100,000	R2c	E22; review AC §3.1
FX-LEGACY	Cross-stage answer overwrites; legacy reconciled answers; untouched outcome defaults (false direction, SD, mean, zero animals); missing timestamps; conflicting legacy duplicates; schema-v0 and v1 options; SystemQuestionVersion v0 and v1 projects; legacy thresholds (single, manual dual, automated dual, custom)	R0 onwards	Review AC §3.5; VB-13; research A2
FX-FLOOR	Documents with unknown elements at Study, Project and SystematicSearch top level and in every enumerated embedded type, including schema-conditional fields	R0 and floor steps	VB-02; review AC-13
FX-APPLIC	The applicability corpus, starting from FEAT-020's specification and fixtures (multi-option conditional parents, filtered options, branch context, ADR-011), plus a seeded generated corpus diffed across the .NET and AF2 evaluators	R2a	E23; review AC-31; PH-07
FX-DRAFT-01 to 08	01 the lease and its holder; 02 take-over; 03 the conflict copy; 04 Save and Complete consume the draft; 05 a late autosave is rejected; 06 a duplicate write sequence counts as success; 07 the first-draft race on the natural key; 08 a network loss	R2a	DC-07 (AC-DC-08); RT-10
FX-CLAIMS	Two tabs through two stages; release on first explicit save; reconnect within and after grace; stale scheduled deliveries; RA5 admission	R2a, R2b, R4a	RT §5.2
FX-ELIG	The eligibility truth table (docs/planning/review-eligibility-truth-table.md), for membership-facts parity and C6	R0, R3a	AP-01
FX-PERM	Persona × activity matrix, including owner-reserved activities, anti-escalation and the delegation envelope	R1b	PM1; PM2; Q-03a
FX-RX1	The ledger's RX1 example (two Excludes with conflicting must-agree reasons) and its variations	R4p	RX1
FX-RE5	The ledger's RE5 delivery list (four cases)	R4a	RE5
FX-SF4	The ledger's SF4/RE3 delivery list (six cases), including outcome series	R4a, R4c	SF4/RE3
FX-SF5	The ledger's SF5 delivery list (seven cases)	R2d	SF5
FX-DP4	The ledger's DP4 delivery list (four cases)	R3b	DP4
FX-QY	QY1 to QY9 cases: two raisers; addressed by update; an unsatisfied concern; invalidated children; audited self-review; an empty rejection explanation	R4b	QY1–QY9
FX-AGREE	Hand-computed agreement: multi-select sets, N/A pairs, compatible versions, informed and independent contributions, a DP2 correction after conflict, missing states	R5c	AG2; AG3; VS2; SR-01
FX-ASOF	History gaps, an adoption date, an erasure event, clock skew near the watermark, unversioned datasets	R5a	DC-13
FX-ASYSD	Labelled benchmark datasets (licences recorded) and SyRF's seeded PRISMA pilot data, with golden outputs from a pinned R container	P2	Amendment L; D4-21
FX-OUTCOME	Legacy-compatible and event-count schemas; several measures with directions; legacy defaults	O1, O2, R4c	OC1; ODIR1
FX-X1	Hand-built comparison fixtures: shared controls, multi-arm experiments, mixed dispersion types and one collectively Excluded study	X1	SR-08; D4-09
FX-CLASS	Populations, cohorts, Pregnant ⊆ Female, counts with and without full support	C1, C2	C13
FX-ALLOC	Allocation regimes on legacy and canonical stages; RA5 under allocation; shared-form plans	R2a, R4a, AL1	AP-03; AP-16
FX-NOTIF	Disclosure fixtures per kind × channel (inbox, email, digest) × role (candidate, reconciler, admin, revoked, blinded); two-event lifecycles	Releases adding kinds	C15; NS §4.2

7.4 Invariant checks

One executable check per invariant in plan §2. The invariant monitor (§10, L17-09) runs the data checks read-only and typed, nightly per admitted project, after every restore and before every adoption step (AC-ALL-21). It also reports the operational checks in the consistency model: derived records current or flagged for a sweep, per-aggregate stamps monotonic, outstanding intents and operations within their age bounds.

ID	Invariant	Executable check	Runs from	Source
INV-01	Forms own evidence; stages own workflow; one session and one contribution per reviewer, study and form; form-owned minimum target	No two FormSessions share (study, form, reviewer); at most one qualifying contribution per reviewer, study and form; sufficiency reads the form target; Study.CanonicalSummary equals recomputation	R2a	SF1; SF2; SF4
INV-02	The latest explicit Save or Complete is current; autosave is a draft; prior versions are immutable and never counted twice	Every session pointer resolves to its latest explicit version; every pinned revision exists; version digests verify; every draft's base exists; no draft counts	R2a	SL1–SL3; SF6
INV-03	Within a stage, own Include opens dependent steps subject to the collective-Exclude veto; across stages, Collective Include by default	Every admission record recomputes to the same result from its recorded policy and version evidence; no dependent admission follows a collective Exclude	R3a	DP6; DP7
INV-04	PRISMA reports the collective authoritative outcome; a collective Excluded stays Excluded	No collectively Excluded study counts as Included in any outcome projection or snapshot; its extraction evidence and provenance remain	R3a	PR1
INV-05	One versioned outcome-measure direction across cohorts, with no context override	At most one current direction head per measure; no direction stored per series	O1	ODIR1
INV-06	Adding a question creates a new form version; publication checks every prior version, needs a recorded admin choice and current statistics at a protected boundary	Every published form version has a policy record and a recorded usage-evidence identity; no version referenced by a session or task changed after first use	R2c	FV1–FV3; PS1–PS3
INV-07	Reconciliation acceptance: final submission accepts displayed valid answers; no gold from agreement or majority	Every gold snapshot links to a final reconciler submission (or an attributed accept-as-gold act); none was created by agreement alone	R4a	RE2; SF4
INV-08	Gold is an immutable snapshot; queries never take gold out of effect until a valid replacement exists	Snapshot digests verify; every current pointer resolves; queried answers stay in the current snapshot until a replacement publishes	R4a	GS1; QY1–QY3
INV-09	No fabricated history, votes, versions or reasons	Every version has a command-ledger record or a migration manifest ID; every screening vote traces to a submit command; adopted records carry coverage labels; no legacy review data was written after its scope's marker	R2a	EX2; research §5
INV-10	Possessing a capability is not administering it; ownership transfer is owner-only; assignments never override eligibility; notifications only under fresh authority	No group holds an owner-reserved activity; no assignment targets an ineligible reconciler; every inbox SourceId resolves or is labelled	R1b	PM1; PM2; RA1; RA2
INV-11	A published question is never permanently deleted	Every question version referenced by a published form or profile version exists	R2a	QD1
INV-12	New and updated screens are consistent, modern and Material 3	UI-1, UI-3, UI-10 and UI-11 guard checks pass on main; every programme route is in FEAT-023's route matrix	S0	UI1

7.5 Contract conformance tests

IDs are stable. The contract texts (contracts for C1–C17; consistency model for the new C18 and C19) are authoritative for wording, and each contract's conformance list maps onto these IDs. A CONF row requires the listed tests, plus every test first required by an earlier release, to pass in full on the release candidate.

C1 Canonical annotation identity, revisions, commands and Study coupling

ID	Assertion	First release	Source	Status
C1-T01	A repeated command and a concurrent duplicate submit leave one head, one effective vote and one command result; a correction appends history without increasing the voter count.	M0	Research A1	PROPOSAL
C1-T02	Open, dirty, idle, disconnect and draft save never create a vote or alter an effective decision.	M0	Research A3	PROPOSAL
C1-T03	Changing a decision preserves old reasons and ordinary saved answers; the same question ID in a different profile or entity context never collides.	M0	Research A7	PROPOSAL
C1-T04	A valid Complete-and-Include commits both; an injected failure before commit commits neither; a retry after an unknown commit returns the original result.	M0 (engine), R3a (journey)	Research A8	PROPOSAL
C1-T05	A shared question and context across stages reuses the reviewer's answer identity, pins submitted versions and is never counted twice.	M0	Research A11	PROPOSAL
C1-T06	Two stages or tabs share a claim and leaving one doesn't release it; the first explicit save releases only the annotation claim; a stale expiry can't remove a newer claim.	M0 (synthetic), R2a (release on save), R2b	Research A13; DC-16	PROPOSAL
C1-T07	Final-slot races, vote corrections that reopen disagreement and unsatisfiable assignments give correct queues and counts; having no available work never completes a stage.	M0 (synthetic), R2b, R3c	Research A14; DC-16	PROPOSAL
C1-T08	Answer and ScreeningDecision pass the same identity, context, attribution, revision, CAS, idempotency and history contract suite through one logical repository; kind-specific keys and validators still apply.	M0	Research A20	PROPOSAL
C1-T09	Owned reason descendants pin exactly the submitted versions; cross-owner edges, cycles, wrong study or profile and stale definition contexts fail before publication; a candidate child never attaches to a reconciled parent.	M0	Research A21; DD-26	PROPOSAL
C1-T10	Two drafts based on one shared answer conflict safely; reverting one never changes the other's submitted answer; explicit independent contexts stay separate.	M0	Research A22	PROPOSAL
C1-T11	A synthetic quality-judgement kind reuses storage, receipts, history, tree handling and export without screening effects.	M0	Research A23	PROPOSAL
C1-T12	A canonical commit racing a bulk-update lock conflicts.	M0	C1	PROPOSAL
C1-T13	Legacy readers see correct tallies and membership facts through Study.CanonicalSummary.	M0 (skeleton), R2a	C1; consistency model	PROPOSAL
C1-T14	Command ledger: the same ID and digest return the original result; a different digest returns 409; an indeterminate commit returns "outcome unknown", and a retry resolves it.	M0	Consistency model	PROPOSAL
C1-T15	No canonical command for study S commits without writing S (architecture test).	R2a	DC (CR-1); consistency model	PROPOSAL
C1-T16	Immutable collections are append-only (an architecture test fails the build on replace, update or delete), content digests verify on read-back, collection names are explicit and mapped, and no canonical collection has a TTL index.	R2a	VB-10	PROPOSAL
C1-T17	Commands above the E28 ceiling are refused before any write.	R2a	E28; VB-12	PROPOSAL
C1-T18	A merge is an alias: no immutable record is re-keyed; one reviewer's two sessions resolve to one counted contribution with provenance; a split reverses it.	P2	Domain model; V2-02; DC-19	pending-D2-12
C1-T19	Natural-key aggregates get deterministic IDs; client-proposed IDs are validated; a foreign-scope ID is refused before mutation.	R2a	E27; VB-16; research A5	PROPOSAL

C2 Answer context identity and sharing

ID	Assertion	First release	Source	Status
C2-T01	An identical QuestionId under different entities or branches stays separate.	R2a	SF5; C2	confirmed
C2-T02	Ancestor lineage shows across two forms in the matching context.	R2d	SF5	confirmed
C2-T03	Conflicting legacy duplicates are surfaced with a conflict marker, and adopt as a Conflicted head.	R2d, R6	SF5; VB-13	confirmed
C2-T04	Two profiles stay separate, even with identical wording.	R3b	DP4	confirmed
C2-T05	Candidate and reconciled heads stay separate.	R4a	C2	PROPOSAL
C2-T06	Enabling classification changes no existing key.	C1	C2; C13	PROPOSAL
C2-T07	Two forms on incompatible versions of one question never flag each other; a v2-only option never appears in a v1 session; Fix shows the in-class current revision.	R2d	VA-02; D2-02	pending-D2-02
C2-T08	Two heads that differ only in the second entity-path element coexist, and an exact duplicate is refused (scalar key hash, partial unique indexes per kind).	R2a	VB-05	PROPOSAL

C3 Provenance, exposure and history capture

ID	Assertion	First release	Source	Status
C3-T01	A reused answer keeps its original authoring stage.	R2b	PV1	confirmed
C3-T02	An informed contribution counts for progress but is labelled informed in agreement statistics.	R4a, R5c	VS2	confirmed
C3-T03	A lost exposure report never turns informed work into independent work.	R4a	VS2	confirmed
C3-T04	Legacy records never gain fabricated versions.	R2a, R6	EX2	confirmed
C3-T05	"Questioned in reconciliation" is an exposure kind that makes later versions informed.	R4a	NS-06	PROPOSAL
C3-T06	The initial independent submission marker is set once, before any collective outcome was visible to that reviewer.	R3a	SR-01	PROPOSAL
C3-T07	Collective exposure is recorded at correction time.	R3b	SR-01	PROPOSAL
C3-T08	Imported screening decisions carry authority Imported and independence unknown.	R3a	SR-03	PROPOSAL
C3-T09	Exposures carried in the Save or Complete payload, or arriving late keyed by draft etag, bind to the right version; the class is derived on read.	R4a	DC-20	PROPOSAL

C4 Question, form and profile definitions and versioning

ID	Assertion	First release	Source	Status
C4-T01	Adding a question creates a new form version.	R2c	FV1	confirmed
C4-T02	Sessions under v1 and v2 are both found when publishing v3.	R2c	FV2	confirmed
C4-T03	Needs updating stays visible and blocks Complete.	R2c	VU1	confirmed
C4-T04	Copies of one template (question templates; profiles) stay independent after the template changes.	R1a, R3b	SET1; DP4	confirmed
C4-T05	A question hidden by a condition is never required.	R2a	UA1	confirmed
C4-T06	Phase 1 is constant work; its time is flat across 1,000, 10,000 and 100,000 sessions.	R2c	VB-06	PROPOSAL
C4-T07	Compatibility is declared at commit, immutable once pinned, and transitive.	R2c	VA-01; D2-02	pending-D2-02
C4-T08	Option identity: a rename keeps answers valid; a retirement doesn't.	R2c	VA-05	PROPOSAL
C4-T09	Composition: ancestors are included and dangling conditions are refused.	R2a	VA-06; QM-09	PROPOSAL
C4-T10	"In use" is defined, and an edit under a draft-only session returns a stale-definition conflict.	R2a	VA-13; research A16	PROPOSAL
C4-T11	Added and removed questions have their own treatments.	R2c	VA-14	PROPOSAL
C4-T12	System questions are versioned data; a deploy changes no published form.	R2a	VA-09; D2-06	pending-D2-06
C4-T13	Publication writes no session versions and no answer revisions.	R2c	VA-03; D2-01	pending-D2-01
C4-T14	Only one publication per form is active at a time.	R2c	VB-06; D2-11	pending-D2-11
C4-T15	A policy revision compare-and-sets the policy generation and rewrites no version or work.	R2d	FV4	confirmed
C4-T16	Every published canonical form version passes AF2's structural guards, with no AF1 fallback.	R2a	VB-08	PROPOSAL
C4-T17	A question referenced by a published version is never deleted by any path.	R2a	QD1	confirmed
C4-T18	Operational settings change with audit and no impact flow.	R2a	VA-07; D2-05	pending-D2-05
C4-T19	A data-type or multiplicity change is an incompatible version of the same identity.	R2c	VA-16; D2-03	pending-D2-03
C4-T20	Profile publication applies the chosen treatment to decisions cast under prior versions.	R3b	Q-26	pending-Q-26

C5 Form session lifecycle, drafts and contribution qualification

ID	Assertion	First release	Source	Status
C5-T01	A Save after Complete removes qualification.	R2a	SL3	confirmed
C5-T02	Autosave alone doesn't.	R2a	SL1; SL3	confirmed
C5-T03	Complete restores one contribution, not two.	R2a	SL3; SF2	confirmed
C5-T04	The same session is reached from two stages.	R2b	SF1	confirmed
C5-T05	An order-only change never removes Complete.	R2a	C5	PROPOSAL
C5-T06	A warning alone keeps Complete; a reviewer-created incomplete version removes it.	R2d	SF6	confirmed
C5-T07	A withdrawn session neither counts nor loses its history.	R2a	C5	PROPOSAL
C5-T08	Draft mechanics FX-DRAFT-01 to 08: lease, take-over, conflict copy, consumption by Save and Complete, late autosave rejected, duplicate write sequence, first-draft race, network loss.	R2a	DC-07; consistency model	PROPOSAL
C5-T09	A session version's previous-version export equals its full pin map.	R2a	VA-22	PROPOSAL
C5-T10	A late Save is pinned to its declared version; Upgrade keeps pins.	R2c	VA-10	PROPOSAL
C5-T11	The per-answer state enum is derived consistently.	R2d	VA-27	PROPOSAL
C5-T12	A draft-only session is created by upsert on the natural key, with a deterministic SessionId.	R2a	VB-16; consistency model	PROPOSAL

C6 Workflow binding, steps and admission

ID	Assertion	First release	Source	Status
C6-T01 to T10	FX-ACCESS-01 to 10 (T04, strict mode, first applies in R3c).	R3a	Access-policy proposal; DP6; DP7	PROPOSAL (T04 pending-Q-01)
C6-T11 to T15	Research A12 to A16: assigned-reviewer completion, shared claims, capacity and final-slot races, independent outcomes and denominators, stale-context conflicts.	R3a	Research A12–A16	PROPOSAL
C6-T16	FX-PRISMA-03a.	R3a	PR1	confirmed
C6-T17	PRISMA stays Excluded with completed extraction.	R3a	PR1	confirmed
C6-T18	The evaluation table gives identical results for selection, reservation, direct access and submit.	R3a	C6	PROPOSAL
C6-T19	Skip records nothing; AND/OR, terminal and compulsory scopes behave as specified.	R3a	Amendment A; C6	PROPOSAL
C6-T20	Screening capacity follows the profile rule (eligibility D6).	R3a	Q-24	pending-Q-24
C6-T21	Admission writes no per-project document per save.	R3a	DC-05	PROPOSAL
C6-T22	An incomplete save or reopen creates no Include; annotation completion never changes an existing Exclude; Stop and Allow are rechecked under concurrent completion.	R3a	Research A9	PROPOSAL

C7 Operational projections and claims

ID	Assertion	First release	Source	Status
C7-T01	Every eligibility truth-table row gives the same answer from the membership-facts seam as from today's predicates (embedded provider in R0, canonical provider in R2a).	R0, R2a	AP-01	PROPOSAL
C7-T02	Stage views project their bound form and never sum duplicate stage projections.	R2b	C7; SF2	confirmed
C7-T03	Typed claims are unique per (study, kind, scope, reviewer) and released when the last page ends.	R2b	RT-11	PROPOSAL
C7-T04	Two stage tabs reuse one claim; closing either keeps it.	R2b	RT-16	PROPOSAL
C7-T05	An optional capacity cap is separate from the minimum target.	R2b	RT-13; D3-17	pending-D3-17
C7-T06	Proportional shares are refused for shared forms until AL1.	R2b	A-09	assumption-A-09
C7-T07	Allocation is refused on canonical stages until AL1.	R2a	AP-06; D3-13	pending-D3-13
C7-T08	Target-aware classification has parity with the authoritative calculation.	R2b	MS-07	PROPOSAL
C7-T09	An RA5 scoped admission admits exactly the requested reviewer.	R4a	AP-03; D3-13	pending-D3-13
C7-T10	The D8 slot rule reads form-keyed claims.	R2b	AP §5	PROPOSAL
C7-T11	An orphaned claim can't outlive the backstop horizon.	X-CLAIMS	RT-24	PROPOSAL
C7-T12	A draft holds the reviewer's place under the D2-07 rule.	R2a	D2-07	pending-D2-07

C8 Version usage evidence and protected publish boundary

ID	Assertion	First release	Source	Status
C8-T01	Usage counts explicit versions; draft-only sessions are counted from pmSessionDraft at the fence.	R2c	MS-03	PROPOSAL
C8-T02	"Current" is a FEAT-024 read at the fence (Fresh or pinned-Authoritative) with its identity recorded.	R2c	MS-04; D3-10	pending-D3-10
C8-T03	Missing or stale evidence is never treated as zero.	R2c	PS2; PS3	confirmed
C8-T04	Affected identities come from authoritative records, never from counts.	R2c	PS1 (boundary)	confirmed
C8-T05	Question-version usage is counted from revisions, form-version usage from session versions.	R2c	VA-17	PROPOSAL
C8-T06	An N-1 binary reading a project with rows of an unknown family serves its known families and ignores the rest.	R2c	MS-14	PROPOSAL
C8-T07	A canonical commit on an allowlisted project with statistics on leaves every affected family exact or Stale, never Fresh and wrong.	R2a	MS §7(a)	PROPOSAL
C8-T08	Profile-version usage is available for profile publication.	R3b	C8	PROPOSAL

C9 Reconciliation task, gold snapshots, assignments and queries

ID	Assertion	First release	Source	Status
C9-T01	One task per study × form, reachable through any bound stage.	R4a	RE4	confirmed
C9-T02	All qualifying candidates take part, including outcome series; non-qualifying sessions never do.	R4a	SF4/RE3	confirmed
C9-T03	Input drift never retracts gold.	R4a	GS1; RE4	confirmed
C9-T04	Gold snapshots are immutable, and the current pointer changes only by compare-and-set.	R4a	GS1	confirmed
C9-T05	Free text prefills only on exact text in the same context, with no normalisation.	R4a	RE5	confirmed
C9-T06	No gold exists before the reconciler's final submission.	R4a	RE2	confirmed
C9-T07	The task editor claim is exclusive and works with tracking off.	R4a	RA1; RT-01	confirmed
C9-T08	Assignment expiry, start and release races each have one outcome.	R4a	RA2–RA4; E6	confirmed
C9-T09	A requested extra reviewer sees no candidate answers or identities.	R4a	RA5	confirmed
C9-T10	One query work item per reconciled revision ID, with per-concern outcomes; children resolve before a replacement.	R4b	QY2; QY3; VA-23	confirmed
C9-T11	QY8 and QY9 closure rules hold.	R4b	QY8; QY9	confirmed
C9-T12	After a correction, screening decisions re-run profile rules, while annotation gold needs the final submission.	R4b	RECOVERED (RC10 split)	confirmed
C9-T13	Target-1 forms create no task.	R4a	Q-29	pending-Q-29
C9-T14	Legacy reconciled answers are handled as AC-R4a-12 states.	R4a	Q-35	pending-Q-35
C9-T15	The second task may revise shared gold, with provenance.	R4a	D2-09	pending-D2-09
C9-T16	An incompatible publication flags gold for re-reconciliation without retracting it.	R4a	VA-11	PROPOSAL
C9-T17	Profile adjudication is a separate, versioned aggregate and never writes through a reconciliation session.	R4p	FEAT-011 (MUST NOT); RX1; V2-18	confirmed
C9-T18	Conversation rules follow Q-10.	R4a	Q-10	confirmed
C9-T19	A question whose candidates span compatibility classes is held on its own.	R4a	VA-04; D2-02	pending-D2-02

C10 Capabilities, groups, delegation and disclosure

ID	Assertion	First release	Source	Status
C10-T01	Every permission-update endpoint refuses owner-reserved activities.	R1b	SEC1	confirmed
C10-T02	Anti-escalation holds across the FX-PERM matrix.	R1c	Q-03a	confirmed
C10-T03	Delegation stays inside the owner's envelope and is non-recursive.	R1d	PM2; Q-03 (approved as recommended, 3 October)	confirmed
C10-T04	Revocation applies to canonical commands on the next request and to page reads within the C18-T06 bound.	R1b, R2a	C10; DC-12	PROPOSAL
C10-T05	The disclosure probe suite passes per channel, including presence and notifications.	R2a	C10; review AC-24; RT-14	PROPOSAL
C10-T06	The export disclosure contract holds: authorised unmasking only, audited, candidates separate from gold for exporters who aren't reconcilers.	R2a	C10	PROPOSAL
C10-T07	Every endpoint is in the permission catalogue (coverage test).	R1b	C10	PROPOSAL
C10-T08	Monitor-capability holders may see personal votes; reviewer-facing warnings never reveal them.	R3a	RECOVERED (OD5); V2-08	PROPOSAL
C10-T09	Study-issue and PDF-correction capabilities exist and drive recipients.	R1c	NS-20	PROPOSAL

C11 History, export and manifests

ID	Assertion	First release	Source	Status
C11-T01	As-of(T) is the set of records stamped at or before T, offered only for T ≤ now − (transaction lifetime + sweep interval + skew bound); ordering is transaction time, never an observed-at field.	R5a	DC-13; VA-21; consistency model	PROPOSAL
C11-T02	Two exports at one watermark have identical data files for versioned datasets and the same authority.	R5a	EX1; DC-13	PROPOSAL
C11-T03	The manifest classifies each dataset as versioned, current-only or not observed.	R5a	DC-13	PROPOSAL
C11-T04	Dates before adoption return "not observed".	R5a	EX2	confirmed
C11-T05	Erasure events appear in manifests and are the only permitted difference at a watermark.	R5a	D2-14	pending-D2-14
C11-T06	Exports carry per-cell question version, class and option IDs.	R2a	VA-17	PROPOSAL
C11-T07	Extraction exports default to collectively Included studies.	R5a	SR-17	PROPOSAL
C11-T08	FEAT-024 history is never an input to as-of exports or report snapshots.	R5a	MS-22	PROPOSAL
C11-T09	After a restore, manifests report the history-discontinuity record.	R5a	DC-17; D2-13	pending-D2-13

C12 PRISMA units, authority and report manifest

ID	Assertion	First release	Source	Status
C12-T01	One current outcome per study and profile, with route provenance, the approved authority set and a structured reason with coverage.	R3a	Amendment H (Q-06a)	confirmed
C12-T02	Pool entry is the first release to anyone; shared openings and personal grants are recorded separately, with filter and profile versions kept.	R3a	Amendment A; D3-13	pending-D3-13
C12-T03	No personal Include, extra completed work, form target or inferred cohort changes a PRISMA count.	R3a, C2	C12; PR1	confirmed
C12-T04	Snapshots pass the arithmetic identities.	R5b	SR-09	PROPOSAL
C12-T05	Snapshots are computed from authoritative records only.	R5b	MS-11	PROPOSAL
C12-T06	Reported external counts combine as amendment K says, with both parts in the manifest.	R5b	Q-37	pending-Q-37
C12-T07	The entry-phase rule per search or import holds.	P1, R5b	V2-04; Q-37	pending-Q-37
C12-T08	Linking a Citation to a Publication never rewrites the Citation.	P1, P2	V2-01	PROPOSAL
C12-T09	Retrieval is fullTextStatus only, never a lifecycle state.	P1	SR-02; D4-07	pending-D4-07
C12-T10	Reading a Publication exposes no foreign project or citation IDs.	P2	V2-03	PROPOSAL
C12-T11	An alias merge counts once in reports.	P2	Amendment D; domain model	PROPOSAL

C13 Classification, populations and inference

ID	Assertion	First release	Source	Status
C13-T01	Each population has a whole-population cohort; every instance belongs to exactly one population.	C1	C13	PROPOSAL
C13-T02	Inference is never written back as a reported answer and can be withdrawn.	C2	C13	PROPOSAL
C13-T03	Counts show only with full support.	C2	C13	PROPOSAL
C13-T04	Implications apply without automatic strictness.	C2	C13	PROPOSAL
C13-T05	The first reasoner's scope is conjunction, containment, disjointness and exhaustiveness.	C2	Q-18	pending-Q-18

C14 Outcome schemas, measures and observations

ID	Assertion	First release	Source	Status
C14-T01	Field roles, types, validators and cardinality are enforced on save.	O1	OC1; E12	PROPOSAL
C14-T02	One versioned direction per measure across cohorts, with no override.	O1	ODIR1	confirmed
C14-T03	Direction is never derived from numeric type and is not a validator.	O1	OC2	confirmed
C14-T04	Legacy defaults are labelled "value or default (unknown)".	O2	Q-05	pending-Q-05
C14-T05	New-shape data round-trips through export and import.	O1	C14	PROPOSAL
C14-T06	Legacy export returns "unsupported shape" for new-shape data.	O1	C14	PROPOSAL

C15 Notification events through the existing notification stack

ID	Assertion	First release	Source	Status
C15-T01	If capture fails, the source change rolls back; if the source rolls back, no inbox row remains.	Releases adding kinds	NS §5.3 (AC-C15-01)	PROPOSAL
C15-T02	Replaying an occurrence or resuming a half-applied fan-out creates nothing new; two lifecycle transitions of one source create two items.	Releases adding kinds	NS §5.3 (AC-C15-02); NS-12	PROPOSAL
C15-T03	Every kind has a category, resolver, label and fixtures (registry test).	Releases adding kinds	NS §5.3 (AC-C15-03); NS-03	PROPOSAL
C15-T04	Disclosure fixtures pass per kind across inbox, email and digest, and across candidate, reconciler, admin, revoked and blinded recipients; a revoked recipient sees "Related item unavailable" and gets no email.	Releases adding kinds	NS §5.3 (AC-C15-04)	PROPOSAL
C15-T05	With the kind's flag off or the project not admitted, nothing is captured and saved items stay readable.	Releases adding kinds	NS §5.3 (AC-C15-05)	PROPOSAL
C15-T06	An old client with a new server, and a new client with an old server, can both save an opt-out.	Releases adding kinds	NS §5.3 (AC-C15-06); NS-02	PROPOSAL
C15-T07	The delivery halt pauses dispatch within one worker cycle and resumes without loss or duplicates.	Releases adding kinds	NS §5.3 (AC-C15-07)	PROPOSAL
C15-T08	Fan-out above the cap goes through recorded fan-out; a 10,000-session publication gives one item per affected owner within AC-R2c-06's bounds.	R2c	NS §5.3 (AC-C15-08)	PROPOSAL
C15-T09	A burst of writes for one recipient causes at most one refetch per tab per second.	Releases adding kinds	NS §5.3 (AC-C15-09)	PROPOSAL
C15-T10	Preferences tolerate unknown and missing keys across the version-skew matrix (before #3942 merges, or one deploy before the first new category).	X-NOTIF	NS-02	PROPOSAL
C15-T11	An unknown kind leaves its ledger row ready rather than suppressed, one deploy before the first new kind.	X-NOTIF	NS-26	PROPOSAL

C16 Compatibility floor, admission and reader and writer compatibility

ID	Assertion	First release	Source	Status
C16-T01	The minimum image round-trips unknown elements through its normal replace path on every extended type.	R0, floor steps	VB-02; review AC-13	PROPOSAL
C16-T02	Computed fields merge Study.CanonicalSummary, and a mixed-fleet recount matches.	R0	DC-02; VB-01	PROPOSAL
C16-T03	Every legacy writer is refused by the ownership guard, and the architecture test fails on an unguarded write.	R0	DC-04; DS-10	PROPOSAL
C16-T04	Removing admission doesn't change ownership.	R0	A-22	assumption-A-22
C16-T05	The admission service gives the API and the web the same answer.	R0	C16	PROPOSAL
C16-T06	The minimum-image rollback rehearsal passes with canonical data present.	R0, floor steps	C16	PROPOSAL
C16-T07	A legacy writer racing a marker sweep never lands after the marker.	R0	DC-04	PROPOSAL
C16-T08	Project admission and the statistics allowlist stay independent.	R0	MS-24	PROPOSAL

C17 Information architecture, coexistence, overview and settings DTOs

ID	Assertion	First release	Source	Status
C17-T01	New screens import copy-deck constants (guard spec).	R2a	UX-05; C17	PROPOSAL
C17-T02	Overview and settings DTOs keep gate status, sufficiency and work status separate; a lock is never labelled "Excluded".	R3a	C17; C6	PROPOSAL
C17-T03	The Dockview layout contract validates panel keys and migrates saved version-2 layouts.	R2a	C17	PROPOSAL
C17-T04	AF2 extension points exist as merged code with contract tests.	R2a	C17; delivery operating model (F1c)	PROPOSAL
C17-T05	Navigation follows each project's mode, and the workflow-version badge shows it.	R2a, GA	C17; UX-11	PROPOSAL
C17-T06	The "My work" surface lists actionable items by role.	R3c, R4a	UX-08; D3-07	pending-D3-07

C18 Concurrency, transactions and idempotency (new)

ID	Assertion	First release	Source	Status
C18-T01	Fault injection at every write step of Save, Complete, decision, gold and publication commits leaves no readable partial state; a retry returns the original result.	M0	DC §6 (AC-DC-01)	PROPOSAL
C18-T02	Zero engine-caused exhausted submissions at 1, 2, 5 and 10 reviewers, same and different study, with the fold worker, claims and a sweep running.	M0, then every AC-ALL-26 release	DC §6 (AC-DC-02); D1-08	confirmed
C18-T03	The command ledger's duplicate, digest-mismatch and post-retention behaviour hold.	M0	DC §6 (AC-DC-03)	PROPOSAL
C18-T04	A forced UnknownTransactionCommitResult and a primary failover in a replica-set Testcontainer produce no duplicate versions or notices.	M0	DC §6 (AC-DC-04)	PROPOSAL
C18-T05	At least 1,000 randomised interleavings of commits against publication phase 1, stage completion and settings changes never violate PS3, LC1 or eligibility D4.	R2c, R3a, R3c	DC §6 (AC-DC-09); D2-10	pending-D2-10
C18-T06	With two API instances, CAS bases and "current" reads are never stale; revocation applies to canonical commands on the next request and to page reads within 2 s (PROPOSAL).	R2a	DC §6 (AC-DC-11); DC-12	PROPOSAL
C18-T07	With injected clock skew and a long transaction near the watermark, exports at one watermark are identical and causally closed.	R5a	DC §6 (AC-DC-12)	PROPOSAL
C18-T08	Reconciliation races: published versus displayed answers (Complete carries the base snapshot and input etag); release versus Save; expiry versus start; query target retention.	R4a, R4b	DC §6 (AC-DC-14); DC-15	PROPOSAL
C18-T09	Canonical repositories never serve deciding reads from the shared RepositoryCache and never use upsert saves (architecture test; #3985 merged first).	R2a	DC-12; consistency model (C18); D1-02	PROPOSAL
C18-T10	A DuplicateKey on a natural-key first write reloads and takes the compare-and-set path.	R2a	DC-11	PROPOSAL
C18-T11	Command-budget tests pin the canonical commit shape.	M0, R2a	DC-11; VB-12	PROPOSAL

C19 Durable effects and events (new)

ID	Assertion	First release	Source	Status
C19-T01	A crash between commit and dispatch still delivers the durable intent; a lease takeover resumes; duplicate delivery is a no-op.	R2a	DC §6 (AC-DC-10); consistency model (C19)	PROPOSAL
C19-T02	Outdated flags and task drift are derived on read and bounded to one reviewer's sessions on one study.	R2d	Consistency model (C19); VB improvement 4	PROPOSAL
C19-T03	Dropping every SignalR and change-stream hint loses no obligation; clients refetch on focus or reconnect.	R2a	Consistency model (C19)	PROPOSAL
C19-T04	Each committed legacy screening change produces exactly one capture entry; overflow becomes a coverage gap.	R2a	DC §6 (AC-DC-13)	PROPOSAL
C19-T05	A publication or sweep operation resumes after a crash with a new lease generation and applies each item exactly once.	R2c	DC-06; VB-06	PROPOSAL

8. Definition of ready and done, and release tiers

The delivery operating model owns the process (slice briefs, review tiers, WIP limits, the STATUS ledger); this section states what each gate checks.

8.1 Pull requests

Ready (before work starts):

• The PR lists the criterion IDs it advances, and the release's freeze-gate dossier authorises its slice (D1-04).
• The contracts it consumes are frozen, or it builds against a published fake.
• Its UI validation passed its pass bar (§5.4), and its copy comes from the copy deck.
• Its flag is declared in env-mapping.yaml, default off.
• Its test plan names a layer and a fixture for each criterion; the fixture files exist or ride in the PR.
• No behaviour depends on an unanswered question unless it is written as a pending row and stays dark.
• Excluded specs in the areas it touches are identified for re-enabling (AC-ALL-15).
• Its slice brief exists, and any hot-file lease it needs is free.

Done (merge):

• The merge criteria (§2.1) and the M rows of §3 pass on the exact head.
• Conformance suites for touched contracts are green.
• The SonarCloud new-code gate passes.
• Docs, user guide and any ADR are in the same PR.
• Review has passed on the exact head under the PR's review tier (§8.3), with no unresolved thread and the latest review summary not requesting changes.
• The traceability file is updated, and the tests carry criterion IDs.

8.2 Releases

Ready (before the build):

• The freeze gate has passed: ADR, DTOs, fake and conformance suite.
• Every pending row is re-confirmed from Chris's answer or its behaviour is descoped; every PROPOSAL row is confirmed or rewritten; both are recorded in the acceptance record.
• Its fixture files, benchmark datasets and seed projects are designed; its UI validations have passed.
• Its brief names the flags-off spec set, the tracking modes, the supported-flag matrix and the e2e minutes it adds (AC-ALL-14, AC-ALL-17).
• Its pilot entry rows (§5.2), pilot plan (projects, testers, and a duration that meets PE-06) and telemetry are agreed.
• The minimum rollback image and the rehearsal plan are recorded; a Bramble window is booked if the release has B rows.
• Its tier (§8.3) is assigned.

Done (activation for pilots):

• A release-candidate commit and image SHAs are deployed to staging (or to a pinned preview for T2 and T3 releases that persist no data) and recorded in the acceptance record.
• Every automated row passes on that commit: CI, the e2e label run, the conformance suites and the Bramble report against main's baseline.
• The rehearsals and containment checks the tier needs are done.
• Seeds are deployed additively.
• A staging acceptance note names who accepted, when, and on which SHA; Chris's walkthrough is done.
• PE-01 to PE-08 are met with monitor evidence, and user testing meets its pass bars.
• External joins have go/no-go evidence before any production pilot.
• The ship-gate verifier's report (AC-ALL-13) and the acceptance record are committed, and Chris gives the go/no-go.

8.3 Release tiers

The tiers merge the review's T1/T2/T3 proposal (review AC-25) with the delivery review's gate weights (DS-11). Status: PROPOSAL, except the tester numbers, which D1-06 approved on 3 October (the panel was named that night, §5.3; no external SyRF users are named yet).

Tier	Applies when	Activation evidence	Rollback	Testers	e2e in CI	Review tier
T1 heavy	The release builds the core canonical write path, migrates or adopts data, or changes the production default	Every applicable activation criterion	AC-ALL-04 (a) and (b): staging image rollback in an agreed promotion-pause window	5	run:e2e-full on the candidate	Supervised: /claude-review opus plus a fresh-context verifier, and Chris reads the summary
T2 standard	The release builds on the T1 core, or adds UI over existing data	Every applicable activation criterion except the staging rehearsal	AC-ALL-04 (a) on a pinned preview when it persists data; floor steps still need staging	3	Smoke plus the release's targeted specs	Supervised for engine, authorization, blinding, admission and flag code; delegated otherwise
T3 light	Derived or read-only outputs, or scaffolding	AC-ALL-03, 08, 13, 19 and 21, its own rows and one walkthrough	None	3, in one batched walkthrough	Smoke	Delegated; supervised for export disclosure

Release	Tier	Rehearsal	Testers	Benchmarks	e2e in CI
S0	T3	None	—	S0 baseline (AC-S0-03)	None
M0	T1 (milestone)	Mixed-version harness	—	M0 go/no-go	None
R0	T1	Staging	— (no UI)	Floor round trip	Smoke
R1a, R1b, R1c, R1d	T2	None (no canonical data); R1a's N-1 test	3	—	Smoke
R2a	T1	Staging	5	Write gate; autosave latency	Full
R2b	T2	Staging for the floor step	3	Write gate	Smoke plus targeted
R2c	T1	Staging	5	Phase 1; FX-PUB-10K	Full
R2d	T2	Harness plus pinned preview	3	Write gate	Smoke plus targeted
R3a	T1	Staging (screening floor step)	5	Write gate; selection	Full
R3b, R3c	T2	Harness plus pinned preview	3	Write gate (R3b)	Smoke plus targeted
R3d	T2	None	5 (AC-UX-07)	—	Smoke plus targeted
R4a	T1	Staging	5	Workspace performance; write gate	Full
R4p, R4b, R4c	T2	Harness plus pinned preview	3	Write gate (R4p); AF2 matrix (R4c)	Smoke plus targeted
R5a, R5c, R5b	T3	None	3 (walkthrough)	Export start; agreement store; report generation	Smoke
P1	T2	Staging for the floor step	3	Import at 5,000 and 50,000 records (AC-P1-19)	Smoke plus targeted
P2	T1	Staging	5	ASySD at 80,000 citations	Full
C1, O1	T2	Staging floor step if they add embedded fields; harness otherwise	3	AF2 matrix (O1)	Smoke plus targeted
C2	T3	None	3	—	Smoke
O2	T1	Authorised copy	— (administrators only)	Dry-run	None
AL1	T2	Harness	3	Selection	Smoke plus targeted
X1 (if D4-09 is approved)	T3	None	3 (walkthrough)	Export start	Smoke
GA	T1	—	Production pilot evidence (AC-GA-06)	—	Full
R6	T1	Staging and authorised copy per wave	—	Parity	Full per wave
R7	T1	Restore rehearsal	—	—	None

9. Traceability

9.1 The traceability file

One machine-readable file holds every criterion, starting in this package (traceability.yaml, beside this page) and moving to a permanent docs/features/ location at G0 (PROPOSAL). Format:

decisions:
  - id: SL3
    kind: ledger          # ledger | s111 | recovered | approved-spec
    meta: false
  - id: IP1
    kind: ledger
    meta: true            # exempt from the coverage check
criteria:
  - id: AC-R2a-02
    release: R2a
    gate: activation      # merge | activation
    tier: T1
    source: [SL2, SL3]    # ledger or s111 IDs | RECOVERED:<ref> | RULE | FEAT-011 | Q-26 | A-14 | D2-01 | review:AC-07
    status: confirmed     # confirmed | pending-Q-xx | pending-Dn-nn | assumption-A-xx | PROPOSAL | conditional-X-...
    confirmed_at: null    # freeze-gate record for PROPOSAL rows; answer reference for pending rows
    traces:
      research: [A1]
      qmv2: [FORM-04]
      feat011: []
      feat012: []
      conformance: [C5-T01]
    fixtures: [FX-PRISMA-04a]
    methods: [I, C]
    tests:
      - "dotnet:FormSessionLifecycleTests.SaveAfterComplete_RemovesQualification"
      - "playwright:@AC-R2a-02"
    evidence:
      rc_commit: null
      images: {}
      ci_run: null
      record: "acceptance/R2a.md#ac-r2a-02"
    aliases: []           # reviewer-proposed IDs folded into this row
    retired: false
    superseded_by: null

9.2 Generated views and checks

1. Decision → criteria. Fails when a non-meta ledger or §1.11 ID has no criterion.
2. Criterion → tests. Fails at a ship gate when an applicable row has no test, or only skipped tests.
3. Per-release acceptance record. A generated page listing, for each applicable row, its status, tests, evidence links, the candidate commit and image SHAs, tester notes and the verifier's sign-off; committed at activation.
4. Pending view. Rows grouped by the question, assumption or join they wait on; it feeds each freeze gate's dossier.
5. Tag check. A test tag naming an unknown or retired ID fails docs CI.

9.3 Coverage of owner decisions

Every ledger ID and §1.11 ID has at least one criterion, except the meta decisions IP1 and AC1 (AC1 is covered anyway) and DP1, which DP6 and DP7 superseded.

Decision	Criteria
SF1	AC-R2b-01, 02, 05, 08; C5-T04; INV-01
SF2	AC-R2a-18, 31; AC-R2b-01, 06, 07; AC-R3a-06; C7-T02
SF3	AC-R2d-01, 07
SF4/RE3	AC-R4a-01, 09, 14; AC-R4c-01, 04; AC-R2b-16; C9-T02
SF5	AC-R2d-01 to 04, 09; C2-T01 to T03
SF6	AC-R2d-05 (AC-R2d-12 pending D2-01); C5-T06
SL1	AC-R2a-01, 08, 28; C5-T02
SL2	AC-R2a-02, 03, 05
SL3	AC-R2a-02, 18, 28; C5-T01, T03
PV1	AC-R2a-26; C3-T01
PV2	AC-R3a-36; AC-R2b-15 (pending D2-04)
GS1	AC-R4a-04, 20; C9-T03, T04; INV-08
VS1	AC-R3a-15; AC-R4a-42
VS2	AC-R4a-19, 42; AC-R5c-02; C3-T02, T03
EW1	AC-R3a-01, 35
FV1	AC-R2a-14; C4-T01
FV2	AC-R2c-01, 02; C4-T02
FV3	AC-R2c-09, 11
FV4	AC-R2d-06; C4-T15
Recovered transitions (requireReanswer, autoUpdate, doNothing)	AC-R2c-11; AC-R2c-02 (pending D2-01)
PS1, PS2, PS3	AC-R2c-04, 05, 08; C8-T03, T04
VU1, VU2, VU3	AC-R2c-03, 12; C4-T03
RA1	AC-R4a-05, 22, 36, 37; C9-T07
RA2	AC-R4a-22, 39; C9-T08
RA3	AC-R4a-07, 40
RA4	AC-R4a-29, 39
RA5	AC-R4a-06, 38; C9-T09
EX1	AC-R2a-05; AC-R5a-01, 05
EX2	AC-R5a-01, 03; AC-R5b-05; AC-R6-06; C3-T04
AG1	AC-R5c-04, 05
AG2, AG3	AC-R5c-01
RE1	AC-R4a-16
RE2	AC-R4a-03, 14, 24, 25, 26; C9-T06; INV-07
RE4	AC-R4a-15, 20; C9-T01
RE5	AC-R4a-03, 18; C9-T05
BL1	AC-R3a-15; AC-R4a-08
QY1, QY7	AC-R4b-01
QY2, QY3	AC-R4b-02; C9-T10
QY4	AC-R4b-06, 11; AC-R4a-05
QY5	AC-R4b-07
QY6	AC-R4b-03, 08
QY8, QY9	AC-R4b-04, 10; C9-T11
MG1	AC-R4a-02
NT1	AC-R4a-17
DP1	Superseded by DP6 and DP7 (decision register §2); no criterion
DP2	AC-R3b-11
DP3	AC-R3b-03; AC-R3a-04
DP4	AC-R3b-01, 02, 09; C2-T04
DP5	AC-R3b-04, 10; AC-R4p-02
DP6	AC-R3a-01, 05; INV-03
DP7	AC-R3a-01, 05, 14; AC-R4p-03
PR1	AC-R3a-05; AC-R4p-03; C6-T17; INV-04
RX1	AC-R4p-02, 05
RX2	AC-R3c-03, 06, 09
LC1	AC-R3c-01 to 04, 15
UA1	AC-R2a-04; AC-R4a-44
PM1	AC-R1b-01 to 05; AC-R1c-09; AC-ALL-03; INV-10
PM2	AC-R1d-01 to 04
OC1	AC-O1-01
OC2, ODIR1	AC-O1-03, 06; AC-R4c-02; AC-O2-03; INV-05
TC1	AC-R3d-06; AC-C1-07
MIG1	AC-O2-05; AC-R6-06
IP1	Meta decision; exempt
SET1	AC-R1a-05; AC-R3b-01; AC-R3d-02
SET2	AC-R3d-01; AC-GA-02, 07
OPS1	AC-R2b-02; AC-R3a-06; AC-AL1-01, 02; AC-P1-07
NOTIF (3 October addition)	AC-ALL-22, 29; AC-R2c-07
UI1	UI-1 to UI-11; AC-ALL-08; INV-12
AC1	AC-ALL-16; AC-S0-04 (meta)
QD1	AC-R2a-10; AC-R6-07; C4-T17; INV-11
SEC1	AC-R1b-01, 03, 07, 09; C10-T01
Q-10	AC-R4a-21; PI-R4a-02; C9-T18
Q-07	AC-ALL-02; §6; PI-ALL-02
Q-08	AC-M0-04
Q-09	AC-R1c-12
Q-13	UI-11
Q-03a	AC-R1c-01, 02, 03
Q-25	AC-ALL-12; AC-R2a-42; PI-ALL-04
Q-31	AC-R2c-04, 08
Q-06a	Amendment A: AC-R3a-13, 19; C: AC-P1-02, 04; D: AC-P2-03; G: AC-R6-16; H: AC-R3a-18; I: AC-ALL-04; J: AC-P1-06, AC-R5b-02

9.4 Research acceptance cases A1 to A28

Case	Criteria
A1, A3, A7, A11, A20, A21, A22, A23	C1-T01, T02, T03, T05, T08, T09, T10, T11 (AC-M0-01); A22 also AC-R2b-07
A2	AC-R3a-12
A4	AC-R3b-02
A5	AC-R2a-21; AC-ALL-19; C1-T19
A6	AC-R3b-18
A8	C1-T04; AC-R3a-11
A9	C6-T22
A10	AC-R2a-16; AC-ALL-19
A12 to A16	C6-T11 to T15; A13 also C1-T06 (synthetic in AC-M0-01); A14 also C1-T07 (synthetic in AC-M0-01) and AC-R3c-10; A16 also AC-R2a-14
A17	AC-R6-06
A18	AC-R6-03
A19	AC-R0-01, 05; AC-ALL-04
A24	AC-R4a-14; C9-T02
A25	AC-R4p-05
A26	AC-ALL-19; AC-R3a-06
A27	AC-R0-08; AC-M0-03
A28	AC-R7-01, 02

9.5 Approved specifications and the QM v2 tracker

Requirement	Criteria
FEAT-011 reserved names (release 1)	AC-P1-09
FEAT-011 Citation raw fields and immutability; nullable source type and name	AC-P1-01, 10, 17
FEAT-011 per-profile outcomes, no single Study status, structured reasons and authority values	AC-R3a-18
FEAT-011 pool membership derivable from filter rules; pool exclusion	AC-R3a-19; AC-P2-06r
FEAT-011 enum values and DOI/PMID indexes (release 3)	AC-P2-10
FEAT-011 no reconciliation writing screeningOutcomes; Reconcile covers both kinds	AC-R4p-01, 04
FEAT-011 34 fields; EXP-05; EXP-06; classification enum names	AC-R5b-07, 08; AC-P2-14; AC-C1-06
FEAT-011 MIG-11, MIG-12, MIG-13 (per project under amendment G)	AC-R6-16, 18
FEAT-012 §2.1 performance and batching; §6 enrichment; §7 and §8 scenarios, Defer, "not duplicate"; §10 audit retention; §11.2 box 3; §12 exclusions	AC-P2-13; AC-P2-11; AC-P2-12; AC-P2-09; AC-P2-07; AC-P2-06r
QM v2 ARCH-03 (scope, owner, derived-from)	C2 owner scope (AC-R3b-09); copy provenance (AC-R1a-08)
QM v2 QM-09; QM-11, QM-14	AC-R2a-24; AC-R2c-27
QM v2 FORM-06; FORM-07	AF2 mounting caps (AC-R4a-13, AC-ALL-24); AC-R2a-28, 46
QM v2 RECON-10, RECON-11, RECON-17; SCR-07; FILT-04	AC-R4a-15, 42, 16; AC-R4p-05; AC-R3a-26, 41
QM v2 MIG-01, MIG-09; EXP-01 to EXP-06; PRISMA-07	AC-R6-03, 04; AC-R2a-43, AC-R5a-07, AC-R5c-05, AC-R3b-19, AC-R5b-08, AC-P2-14; AC-R5b-08

10. Acceptance tooling deliverables (lane L17)

Tooling facts verified read-only on main at de3e98c59 (3 October 2026): e2e/playwright.config.ts defines the projects setup, smoke, @full, @perf and @bulk-pdf, all on devices['Desktop Chrome']; e2e/setup/auth.setup.ts defines three users (one of them SyrfAdmin); e2e/package.json has no axe dependency; src/libs/testing/SyRF.Testing.Common/Fixtures/ holds MongoDbReplicaSetTestFixture (mongo:8.0, replica set rs0), ForwardingProxy and MongoDriverFaults (UnknownTransactionCommitResult, TransientTransactionError); FEAT-024's BenchmarkEnvironment.cs gates benchmarks on SYRF_STATS_DATASET with iteration and warm-up variables (defaults 100 and 10); e2e/tests/perf/annotation-form-perf.spec.ts holds AF2's budgets (first interactive 1,500 ms, edit-to-settle p95 16 ms, category switch 250 ms, at most 20 mounted controls and 10 units, an 8 MiB heap plateau); and docs/platform/enhanced-database-seeding.md describes reconciliation that only transfers ownership of the five seed projects, with staging reseeds as an operator procedure.

ID	Deliverable	Detail	Needed by	Verifies	Engineering item
L17-01	Persona set	The §6.2 personas in e2e/setup/auth.setup.ts and e2e/helpers/constants.ts, matching seed investigators	R1b (S0)	AC-ALL-03, AC-ALL-19	—
L17-02	axe in journeys	@axe-core/playwright in e2e/package.json; per-route checks inside journey specs with a committed baseline	R1b (S0)	AC-ALL-07, AC-UX-09	—
L17-03	Screenshot capture	Named-state captures in light at the §3.1 widths, attached to PRs; dark captures on staging per release	R1b (S0)	UI-4, UI-7, AC-ALL-08	—
L17-04	Firefox and WebKit smoke	New Playwright projects beside the Desktop Chrome projects, for reviewer and reconciler journeys	R2a	AC-R4a-32, AC-R3a-29	—
L17-05	Barrier-injection harness	Named interleaving points ("after read", "before commit", "after commit, before dispatch") on MongoDbReplicaSetTestFixture, reusing ForwardingProxy and MongoDriverFaults; fixed seeded schedules	M0 (S0)	Concurrency rows; C18	E96
L17-06	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 a replace round trip (the e2e stack starts from a fresh database today)	R0 (S0 skeleton)	AC-R0-01, 06, 09; AC-ALL-04	E95
L17-07	Canonical benchmark datasets	RV-DS-01 to 05 on FEAT-024's environment-gated generator, plus a canonical-commit arm	M0 (baseline in S0)	AC-ALL-09, AC-ALL-26, AC-M0-02	E98
L17-08	Cross-language fixture corpus	The §7.1 JSON corpus read by xUnit and Vitest; seeded generated corpora diffed across evaluators	S0	AC-S0-02; C rows	E99
L17-09	Invariant monitor	Read-only checker for INV-01 to 12 plus the consistency model's operational checks; nightly per admitted project; typed findings; staging dashboard	R2a	AC-ALL-21; PE-04r	— (checker contract in the consistency model)
L17-10	Traceability file and check	§9 format, generated views, docs-CI job	S0	AC-ALL-16; AC-S0-04	E94
L17-11	Tracking-mode matrix	Playwright project matrix with tracking on and off on one stack	R2a	AC-ALL-23	—
L17-12	Scenario endpoint	A test-only endpoint in the e2etest environment that builds canonical states through canonical commands	R2a	DT2; E rows	—
L17-13	Seed-if-absent job	Additive, idempotent seeding for preview and staging	S0 (skeleton); each release (seeds)	AC-S0-06	E97
L17-14	Telemetry dashboard	Staging dashboard of pilot-exit signals	R2a pilot entry	AC-ALL-20	—
L17-15	Excluded-spec check	A script comparing changed paths with both web exclusion lists	S0	AC-ALL-15	—
L17-16	Two-API journeys	Variants on the e2e/tests/materialized-statistics-two-api.spec.ts pattern for claims, drafts and fences	R2a	C18-T06; AC-R2a-06	—
L17-17	Network-throttling helper	Offline and latency injection for journeys	R2a	AC-R2a-46; AC-UX-06	—
L17-18	Native-drag guard spec	A guard spec failing on native HTML5 drag events in programme code, beside CDK drag helpers for journeys	R1a (S0)	AC-R1a-12; AC-R4a-32	—

Resolution record

Categories: Corrected (the plan was wrong or inconsistent; fixed), Adopted (improvement accepted, labelled PROPOSAL where it is a design choice), Question (needs Chris; Batch D ID cited), Follow-up (recorded for the backlog, outside this scope), Noted (no change).

Counts. The previous version had 227 IDs. This revision keeps 222 of them (111 unchanged in substance, with copy edits at most; 111 rewritten in place, as the change logs and §2 and §3 show), retires 5 (replaced by r rows, §4.37), and adds 346 new criteria (345 plus AC-C2-06, added after verifier V3), 23 pilot entry rows and 33 conformance rows, plus 210 contract conformance tests in 197 rows (§7.5) and 12 invariant checks (§7.4). Every ledger and §1.11 ID is covered (§9.3). A last pass aligned the rows with the companion documents as merged into this package (consistency model, domain model, methodology coverage, programme integration, UX strategy and versioning model); it added 22 criteria and the X1 conformance row, listed below under their findings.

Review AC (acceptance criteria and testability)

Finding	Category	Where	Note
review AC-01	Corrected	§1.2; CONF rows; §7.5; §9.3	Source and Status on every row; a conformance row per release naming test IDs; coverage table. New rows for PV1 (AC-R2a-26), VS1 (AC-R3a-15, AC-R4a-42), RE1 (AC-R4a-16), NT1 (AC-R4a-17), TC1 (AC-R3d-06, AC-C1-07), QY5 (AC-R4b-07), RE4 (AC-R4a-15), Q-10 (AC-R4a-21), Q-13 (UI-11) and amendment H (AC-R3a-18).
review AC-02	Corrected	§1.2; pending rows	Pending rows are concrete recommended answers that can't pass until answered: AC-R1c-08, AC-R1d-05, AC-R2d-08, AC-R3a-07, 21, AC-R3b-05, AC-R3c-07, 08, AC-R4a-12, 28, 30, 31, AC-R5c-03, 06. Q-32 (AC-R4p-06), E1 (AC-R2c-02, 20) and E11 (AC-R3b-10) now have rows.
review AC-03	Adopted	§1.3; §2.1; §2.2; §8.2	Merge criteria versus activation criteria on a recorded candidate commit and image SHAs; acceptance record. PROPOSAL.
review AC-04	Corrected	§7.1; §7.2	Fixtures as versioned data with per-release parts and authoring dates.
review AC-05	Corrected	AC-R3a-14; AC-R3c-08 to 10; AC-R3d-06, 07; §7.3	Access-policy, lifecycle and setup fixtures are rows and fixture families.
review AC-06	Corrected	AC-R3a-11 to 41	Every proposed R3a row, plus other reviews' additions.
review AC-07	Corrected	AC-R2a-20 to 31	Proposed IDs kept; AC-R2a-20 now states the consistency model's ordering (HLC plus per-aggregate versions) instead of a per-project commit sequence.
review AC-08	Corrected	AC-R4a-14 to 22 (and 23 to 49)	Negative cases and the missing decisions.
review AC-09	Adopted	§10 (L17-01 to 17); §1.2	Dated tooling with "needed by" releases; rows whose tooling doesn't exist can't pass.
review AC-10	Adopted	§6.2; AC-ALL-03	Persona set; SyrfAdmin only for application-admin paths.
review AC-11	Adopted; Question (D3-14)	AC-S0-06; §6.1; §6.4	Seed-if-absent job; data tiers.
review AC-12	Adopted	§1.4; L17-05; C18	Barrier harness and the interleaving rule.
review AC-13	Corrected	AC-R0-01, 06, 07	Subject is the recorded minimum image; capture, never ignore-only.
review AC-14	Corrected; Question (D2-08)	AC-R2a-06, 28	Lease model with a conflict copy; durability and draft-changes indicator.
review AC-15	Corrected	AC-ALL-15; AC-R1a-07	Both exclusion lists checked (verified: 45 angular.json entries; vitest.config.ts excludes question-management/**).
review AC-16	Corrected	PE-01, 02, 04r, 06, 07; AC-ALL-20, 21; §5.2	Measurable exit, minimum exposure, severity, entry rows.
review AC-17	Corrected; Question (D3-01)	UI-3; UI-9	Statically checkable UI-3; route matrix registration.
review AC-18	Corrected	§6.1; AC-ALL-09; AC-M0-02; AC-R2a-19; AC-R2c-06, 13; AC-R4a-13	Named datasets on FEAT-024's harness, iteration counts, same-host baselines, AF2 gate reuse.
review AC-19	Corrected; Question (D3-15)	AC-ALL-07; UI-6; AC-R4a-32; L17-04	FEAT-023 accessibility matrix; one width list; CDK drag; Firefox and WebKit smoke.
review AC-20	Corrected	AC-P1-09, 10, 17; AC-P2-10, 14; AC-R3a-18, 19; AC-R5b-08; AC-C1-06; §9.5	FEAT-011 MUSTs as rows.
review AC-21	Corrected; Question (D4-21)	AC-P2-01r, 06r, 11 to 14	Parity made computable; exclusion list completed.
review AC-22	Adopted	AC-ALL-17; §8.2	Fail-closed surfaces; supported-flag matrix in each brief.
review AC-23	Adopted	AC-ALL-18; AC-ALL-04	Containment row; rehearsal scoped by tier.
review AC-24	Adopted	AC-ALL-19; C10-T05	Disclosure-matrix probe suite (matrix produced at F1b).
review AC-25	Adopted; Question (D3-02, D1-06); D1-06 answered 3 October	§8.3; UI-8	Tiers merged with DS-11's gate weights.
review AC-26	Adopted	§1.4; AC-ALL-14; §8.2	Persisted-state rows carry I or C; briefs list spec sets and e2e minutes.
review AC-27	Adopted	UI-10	Literal-colour guard spec.
review AC-28	Adopted	UI-2; UI-5; UI-8	Pattern inventory, handoff link, "materially changed" defined.
review AC-29	Adopted	§5.3; §5.4	Tasks for every user-facing release, with rubrics and pass bars.
review AC-30	Adopted	§7.4	INV-01 to 12.
review AC-31	Adopted	§7.1; E99	Corpus location, format and cross-language harness.
review AC-32	Adopted	AC-ALL-22; C15-T01 to T11	Notifications-on criteria.
review AC-33	Question (D1-07); answered 3 October	AC-GA-06	Production opt-in pilot per family before GA.
review AC-34	Corrected	AC-R5a-02r; AC-R2a-09, 10, 32; AC-R3a-07; AC-R1b-08; AC-R2c-10; AC-O2-01r; AC-R3d-01	Each precision defect fixed.
review AC-35	Corrected	AC-M0-01; §9.4	Research cases mapped.
review AC §3.1–§3.5, §5	Adopted	§2; §4; §6; §8; §9	Proposed rows, DoR/DoD, tiers, traceability format, test strategy, data plan and coverage gaps adopted; data tiers renamed DT1 to DT5 to avoid clashing with release tiers.

Reviewer IDs folded into other rows (aliases)

Proposed by	Proposed ID(s)	Final ID(s)
VB; RT; DC	VB AC-R0-06; RT AC-R0-06; AC-DC-05	AC-R0-09
VB	AC-R0-07	AC-R0-06
VB; DC; MS	VB AC-R2a-20; AC-DC-03; MS-05	AC-R2a-07; C18-T03
VB	AC-R2a-21, 22, 23, 24	C2-T08; C1-T16; AC-R2a-44; AC-R2a-19 and C18-T11
VB	AC-R2a-25, 26, 27	AC-R2a-38 and AC-R2c-16; AC-R2a-39 and AC-R2d-14; AC-R2a-17
VB	AC-R2c-10, 11, 12, 13	AC-R2c-13; AC-R2c-06; AC-R2c-05; AC-R2c-14
VB	AC-R2d-09; AC-R6-05, 07, 08	AC-R2d-10; AC-R6-05, 10, 11
VA	AC-R2a-20, 21, 22, 23, 24	AC-R2c-21; AC-R2c-22; AC-R2a-24; C5-T09; AC-R2a-14
VA	AC-R2c-10, 11, 12, 13, 14	AC-R2c-02 and C4-T13; AC-R2c-18; AC-R2c-20; AC-R2d-06; AC-R2a-23
VA	AC-R2d-09, 10; AC-R4a-14, 15	AC-R2d-11; AC-R2d-13; AC-R4a-33 and C9-T19; AC-R4a-34
VA	AC-R5a-07, AC-R5c-05; AC-R6-07	AC-R5a-07 and AC-R2a-43; AC-R5c-08; AC-R6-12
RT	AC-R2a-20, 21, 22, 23	AC-R2a-35, 36, 37, 06
RT	AC-R2b-03, 07, 08	AC-R2b-03, 09, 10
RT	AC-R3a-11, 12; AC-R3c-08; AC-R2c-10	AC-R3a-24, 25; AC-R3c-14; AC-R2c-19
RT	AC-R4a-14, 15, 16, 17; AC-R4b-07	AC-R4a-36, 37, 38, 39; AC-R4b-09
RT	AC-ALL-13 (tracking-mode parity)	AC-ALL-23 (AC-ALL-13 was already in use)
NS	AC-R3c-08; AC-R4a-14, 15; AC-R4b-07	AC-R3c-11, 12; AC-R4a-40, 41 and AC-R4a-21; AC-R4b-08
NS	AC-R5c-05; AC-R6-07; AC-ALL-14; PE-06	AC-R5c-07; AC-R6-11, 13; AC-ALL-04 (d); PE-08
SR	AC-R5b-08; AC-P1-09	AC-R5b-09; AC-P1-11 and AC-R5b-18 (both IDs were already used by review AC proposals)
UX	AC-ALL-14 onwards (efficiency)	AC-ALL-24, 25
DC	AC-DC-01, 02, 04	C18-T01 and AC-M0-06; AC-ALL-26 and C18-T02; C18-T04 and AC-M0-06
DC	AC-DC-06, 07, 08, 09, 10	AC-R2b-11; AC-R0-11 and C16-T07; AC-R2a-06 and C5-T08; AC-R3c-13 and C18-T05; C19-T01
DC	AC-DC-11, 12, 13, 14, 15	C18-T06; AC-R5a-08 and C18-T07; AC-R2a-17 and C19-T04; AC-R4a-27 and C18-T08; AC-R2a-29
NS	AC-C15-01 to 09	C15-T01 to T09 (AC-ALL-22)
AP	AC-AL1-04 to 08	Same IDs

Verifier V2

Finding	Category	Where	Note
V2-01	Adopted	AC-P1-12; C12-T08	Amendment N criterion. PROPOSAL.
V2-02	Adopted; Question (D2-12)	AC-P2-05; C1-T18	Merge as an alias.
V2-03	Adopted	AC-P2-15; FX-PRISMA-08a	Publication privacy; the cross-project fixture part moves to P2.
V2-04	Corrected; Question (Q-37, D4-11)	AC-R5b-07, 12, 17	Entry-phase rule, per-box rules, box 1.
V2-05	Corrected	§1.2; Status column; UI-8; AC-R4a-05, 28	Recommendations marked pending; A-24 cited; Q-36 caveat.
V2-06	Corrected	AC-R2a-20 to 25, 31; AC-R3a-11 to 13, 17, 19, 23; AC-R4a-14, 16, 17, 19, 20, 44; AC-R5b-10, 12 to 14; AC-P2-10, 16	MVP-boundary items have rows.
V2-07	Corrected	§7.2; AC-R3c-15; AC-R4p-07	Fixtures 3 and 4 split by release.
V2-08	Corrected	AC-R3a-09; C10-T08; integrated plan; contracts C10	Monitor holders may see votes; reviewer-facing warnings never do. Plan and C10 wording aligned.
V2-09	Corrected; Question (D3-14)	AC-S0-06; §6.2; §6.3	A seed mechanism exists; the versioned-forms seed is split; testers use their own accounts.
V2-10	Adopted	AC-R6-18	MIG-13 per project.
V2-12	Corrected	AC-P2-01r, 04, 06r	Scenario 3 sets Merged; reversal restores Citation links; pilot-data parity; full exclusion list.
V2-13	Corrected	AC-P2-07; AC-P1-15; AC-R5b-16
V2-15	Adopted	AC-M0-03	Missing Study writers added to the inventory.
V2-16	Adopted; Question (D2-15)	AC-R1a-08, 10	Copy provenance with an N-1 test; system-scoped templates.
V2-18	Adopted	AC-R4p-01; AC-R2a-06	Versioned adjudication; where the losing tab's draft lives.
V2-21	Corrected	AC-ALL-04, 11; AC-R0-01	Scoped by tier; subject corrected.
V2-22	Corrected; Question (D3-01)	UI-3; UI-6; UI-8	925 px added; A-24 cited; the UI1 reading put to Chris.
V2-23	Corrected	§5.1; AC-R4a-03, 07; AC-O2-04; AC-R6-05; AC-R3b-04; AC-R4c-03; AC-C1-03, 04; AC-R4a-13	Methods added; bundled rows split; non-observable rows rewritten.
V2-24	Corrected	AC-R3d-06, 07; AC-R3c-08; AC-R4b-07, 11; AC-R4p-05; AC-R5c-05; AC-C1-07, 08, 10; AC-M0-04, 05, 07; AC-R6-08, 13; AC-R1c-09; AC-R2d-09
V2-25	Corrected	§5.3	Tasks for R2d, R3c, R4b, R4p, R5c, P2 and C2.

Data consistency (DC)

Finding	Category	Where	Note
DC-01	Corrected	AC-R2a-20; AC-M0-07	No per-project document in interactive commits.
DC-02	Corrected	AC-R0-09; AC-R2a-12	Study.CanonicalSummary behavioural floor.
DC-03	Corrected	AC-R2a-07	Command ledger.
DC-04	Corrected	AC-R0-02, 08, 11	Markers, guard, race test.
DC-05	Adopted	AC-R3a-27
DC-06	Corrected	AC-R2c-05, 06
DC-07	Corrected	AC-R2a-06; C5-T08
DC-08	Adopted	AC-R3a-31; AC-R2c-15
DC-09	Adopted; Question (D2-10)	AC-R3c-13
DC-10	Adopted	C19-T01 to T05
DC-11	Adopted	AC-ALL-10; C18-T10, T11
DC-12	Adopted	AC-ALL-03; C18-T06, T09
DC-13	Corrected	AC-R2a-20; AC-R5a-02r, 04, 08; C11-T01
DC-14	Corrected	AC-R2a-17; AC-R3a-10
DC-15	Adopted	AC-R4a-22, 27, 39; AC-R4b-10; C18-T08
DC-16	Corrected; Question (D1-08); answered 3 October	AC-M0-01, 02, 06; AC-ALL-26; AC-R2a-19	A13 and A14 run on synthetic claims in M0, as the consistency model asks, and again as journeys in R2a and R2b (C1-T06, T07).
DC-17	Adopted; Question (D2-13)	AC-R2a-29; AC-R5a-11; AC-R7-02
DC-18	Corrected	AC-R0-01
DC-19	Corrected	AC-P2-05, 07
DC-20	Adopted	AC-R4a-19; C3-T09
DC-21	Adopted	AC-R0-12

Versioning implementation (VB) and versioning model (VA)

Finding	Category	Where	Note
VB-01	Corrected	AC-R0-09
VB-02	Corrected	AC-R0-01, 06
VB-03	Adopted	AC-R2c-13
VB-04	Corrected	AC-R2a-07
VB-05	Adopted	C2-T08
VB-06	Corrected; Question (D2-10, D2-11)	AC-R2c-05, 06, 14, 15
VB-07	Corrected	AC-R0-02, 08; AC-R6-05
VB-08	Adopted	AC-R2a-38; AC-R2c-16
VB-09	Adopted	AC-R2a-39; AC-R2d-14
VB-10	Adopted	C1-T16
VB-11	Adopted	AC-R2a-10, 44; §7.4
VB-12	Corrected	AC-R2a-19, 22; §6.1
VB-13	Adopted	AC-R6-10, 11
VB-14	Corrected	AC-R2a-17
VB-15	Adopted	AC-R2d-10; AC-R3c-16
VB-16	Adopted	AC-R2a-21; C5-T12
VB-17	Adopted	AC-M0-04
VB-18	Adopted	AC-R0-14
VB-19	Adopted; Question (D2-14)	AC-R2a-30
VB-20	Adopted; Question (D2-13)	AC-R2a-29
VA-01	Question (D2-02)	AC-R2c-21; C4-T07
VA-02	Question (D2-02)	AC-R2d-11; C2-T07
VA-03	Question (D2-01)	AC-R2c-02; AC-R2d-12; C4-T13	The FV4 row (AC-R2d-06) stays confirmed.
VA-04	Question (D2-02)	AC-R4a-33; C9-T19
VA-05	Adopted	AC-R2c-22; C4-T08
VA-06	Adopted	AC-R2a-24; C4-T09
VA-07	Question (D2-05)	AC-R2a-14, 33
VA-08	Question (D2-04, D2-05)	AC-R2b-15
VA-09	Question (D2-06)	AC-R2a-23; C4-T12
VA-10	Adopted	AC-R2c-20; C5-T10
VA-11	Adopted; Question (D2-09)	AC-R4a-34, 43; C9-T16
VA-12	Corrected; Question (D2-08)	AC-R2a-06
VA-13	Adopted	AC-R2a-14; C4-T10
VA-14	Adopted	AC-R2c-18; C4-T11
VA-15	Corrected	AC-R2a-10, 32
VA-16	Question (D2-03)	AC-R2c-26; C4-T19
VA-17	Adopted	AC-R2a-43; AC-R5a-07; AC-R5c-08; C8-T05
VA-18	Adopted	AC-R6-12
VA-19	Question (D2-05)	AC-R3b-05
VA-20	Adopted	AC-R3a-32
VA-21	Adopted	C11-T01
VA-22	Adopted	C5-T09; AC-R2a-26
VA-23	Adopted	AC-R4b-02; C9-T10
VA-25	Adopted	AC-C1-08
VA-27	Adopted	AC-R2d-13; C5-T11

Active reviewer tracking (RT) and notifications (NS)

Finding	Category	Where	Note
RT-01	Corrected	AC-R4a-36, 37; C9-T07; §4.33	X-RECLAIM replaces X-TRACK as R4a's route.
RT-02	Corrected; Question (D3-16)	AC-ALL-12; AC-R2b-14; AC-T-09
RT-03	Corrected	AC-R2b-14; AC-T-09
RT-04	Adopted	AC-ALL-01, 23; L17-11
RT-05	Adopted	AC-R2a-35, 36
RT-06	Corrected	AC-R2a-12; AC-R0-09
RT-07	Corrected	AC-R0-09; AC-T-05
RT-08	Corrected	AC-R0-02; AC-M0-03
RT-09	Question (D2-07)	AC-R2a-37
RT-10	Adopted	AC-R2a-06
RT-11	Adopted	AC-R2b-12; C7-T03
RT-12	Question (D3-18)	AC-R2b-10
RT-13	Question (D3-17, D3-13)	AC-R2b-16; AC-R4a-38
RT-14	Question (D3-20)	AC-T-08; AC-ALL-19
RT-15	Adopted	AC-R2a-36
RT-16	Corrected	AC-R2b-03
RT-18	Adopted	AC-R3c-14
RT-19	Adopted	AC-R2c-19
RT-20	Adopted	AC-R1c-10
RT-21	Adopted; Question (D2-14)	AC-R2a-30
RT-23	Adopted; Question (Q-24)	AC-R3a-24
RT-24	Adopted	AC-T-06; C7-T11
RT-26	Adopted	AC-R4a-19	Exposure travels in REST payloads, never hub calls.
RT AC-T-01 to 08	Adopted	§4.35	IDs kept; AC-T-09 added for the D3-16 route.
NS-01	Adopted	AC-R2c-07; AC-R4a-40	Recorded fan-out; scheduler markers.
NS-02	Adopted	C15-T06, T10
NS-03	Adopted	AC-ALL-22; C15-T03
NS-04	Question (D3-21)	AC-ALL-29; PI-ALL-05
NS-05	Adopted; Question (D1-09); answered 3 October	AC-R2a-40; AC-R4a-21; PI-R4a-02
NS-06	Adopted	AC-R4a-35; AC-R5c-07; C3-T05
NS-07	Question (D3-07)	AC-R3c-11; AC-R4a-47
NS-08	Adopted	AC-M0-03; AC-R0-02; AC-P1-03, 13
NS-09	Corrected	AC-R1c-04	Conditional on X-NOTIF.
NS-10	Noted	AC-ALL-08	The stack's screens fall under UI1 like any updated screen; timing is D3-01.
NS-11	Adopted	AC-ALL-22
NS-12	Adopted	C15-T02
NS-14	Question (Q-20)	AC-R2d-08
NS-15	Adopted	AC-R2c-07
NS-18	Adopted	AC-R2a-40
NS-20	Adopted	AC-R1c-11; C10-T09
NS-21	Adopted; Question (D2-14)	AC-R2a-30
NS-24	Adopted	AC-R4b-12
NS-26	Adopted	C15-T11; AC-ALL-04 (d)
NS AC-C15-01 to 09	Adopted	C15-T01 to T09; AC-ALL-22
NS §5.3 release criteria and user-testing tasks	Adopted	AC-R1c-04; AC-R2c-07; AC-R2d-08; AC-R3c-11, 12; AC-R4a-21, 40, 41; AC-R4b-08; AC-R5c-07; AC-R6-11, 13; AC-ALL-04 (d); PE-08; §5.3

Materialised statistics (MS) and allocation (AP)

Finding	Category	Where	Note
MS-01	Adopted	AC-R2c-08; §4.33	X-STATS-b1 to b7 and X-STATS-a.
MS-03	Adopted	AC-R2c-01, 25; C8-T01
MS-04	Question (D3-10)	AC-R2c-04; C8-T02
MS-05	Adopted	AC-R2a-07
MS-06	Adopted	AC-M0-05
MS-07	Adopted	AC-R2b-13; AC-R3a-06
MS-08	Question (D3-10)	AC-R3a-34; AC-R3b-12
MS-10	Question (D3-10)	AC-R2c-08, 17; PI-R2a-05
MS-11	Adopted	AC-P1-07; AC-R5b-19
MS-12	Adopted	AC-R2a-20; AC-S0-03
MS-14	Adopted	C8-T06
MS-16	Adopted	AC-ALL-04 ©
MS-17	Adopted	AC-R6-04
MS-19	Adopted	AC-R3a-27
MS-20	Question (D3-11)	AC-R5c-09
MS-22	Adopted	C11-T08; AC-R5b-19
MS-24	Adopted	AC-R0-13
MS §7 (a) to (g)	Adopted	(a) C8-T07; (b) AC-R2c-24; © AC-R2b-13; (d) C8-T06; (e) AC-ALL-26, AC-S0-03; (f) AC-R2c-25; (g) AC-ALL-04 ©
AP-01	Corrected	AC-R0-10; C7-T01; AC-R2a-12
AP-02	Question (D3-13)	AC-R3a-09; AC-AL1-05
AP-03	Question (D3-13)	AC-R4a-38; C7-T09
AP-04	Corrected	AC-R3c-05
AP-05	Adopted	AC-R3a-10; AC-R3c-17
AP-06	Question (D3-13)	AC-R2a-41; AC-AL1-06
AP-08, AP-09	Question (D3-09)	AC-R3a-33
AP-10	Adopted	AC-AL1-07
AP-12	Question (D3-13)	AC-R3c-19
AP-13	Adopted	AC-R6-14
AP-14	Adopted	AC-R2b-13
AP-15	Adopted	AC-AL1-09
AP-16	Adopted	AC-AL1-04 to 08
AP-17	Adopted	AC-R3a-26
AP-19	Adopted	AC-R3c-17
AP-23	Adopted	AC-AL1-10

Domain-driven design (DD)

Only the DD findings that need a criterion are listed; the domain model resolves the rest.

Finding	Category	Where	Note
DD-04	Adopted	AC-R0-16	PM capture capability is an R0 item (E59).
DD-16	Adopted	AC-M0-02	Project-document contention arm.
DD-22	Adopted	AC-M0-08	Fitness tests (E58).
DD-26	Adopted	C1-T09	A candidate child never attaches to a reconciled parent.

Methodology (SR), UX, past-year planning (PH) and delivery (DS)

Finding	Category	Where	Note
SR-01	Adopted; Question (D4-12)	AC-R3a-38; AC-R3b-17; AC-R5c-06, 10; C3-T06, T07
SR-02	Question (D4-07)	AC-P1-11; AC-R5b-18; C12-T09
SR-03	Adopted	AC-R3a-30; C3-T08
SR-04	Question (D4-05)	AC-P1-14; AC-R3b-15
SR-05	Question (D4-06)	AC-R1a-09, 11
SR-06	Adopted; Question (D4-10)	AC-O1-10, 11
SR-07	Question (D4-08)	AC-R5b-15
SR-08	Question (D4-09)	AC-X1-01 to 03
SR-09	Adopted	AC-R5b-09, 25; FX-PRISMA-08b
SR-10	Question (D4-13)	AC-R3b-13
SR-11	Question (D4-04)	AC-R3c-18; AC-R5c-11
SR-12	Question (D4-03)	AC-R4a-49
SR-13	Question (D4-01)	AC-R3b-14
SR-14	Question (D4-11)	AC-R5b-12
SR-15	Corrected; Question (D4-07)	AC-R5b-18; C12-T09	Resolved by amendment M.
SR-16	Adopted	AC-R2c-28; AC-X1-03	The recovered autoUpdate choice is kept, with guards.
SR-17	Adopted	AC-R5a-10; C11-T07
SR-18	Adopted	AC-R5c-12	RE1 is not reopened.
SR-19	Adopted	AC-P2-17
SR-20	Adopted	AC-R5b-23
SR-21	Adopted	AC-R3d-09
SR-22	Question (D4-21)	AC-P2-01r	SR-22's tolerance (sensitivity and specificity within 0.5 percentage points) is recorded in the row for D4-21 to decide.
SR-23	Question (D4-02)	AC-R4p-08
SR-24	Adopted	AC-P1-18
SR-25	Adopted	AC-R3b-20
SR improvements 1 to 10	Adopted (7 Noted)	1 AC-R5b-22; 2 AC-R5b-21; 3 AC-R5c-11; 4 AC-R4p-09; 5 AC-O1-12; 6 AC-P2-17; 8 AC-X1-03; 9 AC-R3d-09, AC-R1a-09; 10 AC-R5b-24	Improvement 7 (reuse the pair view for report linkage) is a design note with no criterion of its own.
UX-01	Adopted	§2.3; §5.3; §6.3	Baseline study and realistic-content seed.
UX-02	Adopted	AC-ALL-24, 25; AC-R3a-28; AC-UX-03, 04
UX-04	Adopted	AC-R2a-46
UX-05	Question (D3-03)	UI-11; C17-T01
UX-06	Adopted	AC-ALL-07; L17-02
UX-07	Question (D3-04)	UI-2; UI-5
UX-08	Question (D3-07)	AC-R3c-11; AC-R4a-47; C17-T06
UX-09	Adopted	AC-ALL-27; AC-GA-04
UX-10	Adopted	§5.3 (R2c pass bar per category)
UX-11	Question (D3-06)	AC-GA-03, 09; C17-T05
UX-12	Question (D3-01)	UI-3; UI-4; UI-7	Dark evidence from staging, where themeToggle is on (verified).
UX-13	Question (D3-02)	UI-8
UX-14	Adopted	AC-R4a-42, 45
UX-15	Corrected; Question (D3-05)	UI-6; AC-ALL-07; AC-R3a-29	Widths aligned with break-points.ts (verified).
UX-16	Adopted	UI-2
UX-17	Adopted	AC-UX-06
UX-19	Adopted	AC-R3d-08; AC-UX-07
UX-20	Adopted	AC-ALL-28
UX-21	Question (D3-08)	AC-ALL-25
UX AC-UX-01 to 09	Adopted	§2.3; UI-6; UI-7	PROPOSAL thresholds; the UX strategy owns the protocol, and the rows now use its wording (a 60-second offline interval, latency at 200 and 1,000 questions, per-metric release lists, the screenshot matrix at the UI-6 widths).
PH-01	Corrected; Question (D1-08); answered 3 October	AC-ALL-26; AC-R2a-19; AC-M0-02
PH-02	Question (D3-12)	AC-P1-16
PH-03	Question (D2-07)	AC-R2a-37
PH-05	Adopted	AC-R3a-37	Every existing per-stage setting has a stated home.
PH-07	Adopted	FX-APPLIC	FEAT-020's specification and fixtures seed the applicability corpus.
PH-09	Adopted	AC-P1-19	Import scale with Citation capture on.
PH-10	Question (D4-14)	§4.36	Lane floors stated; criteria follow if approved.
PH-13	Adopted; Question (D3-15)	AC-R1a-12; AC-R4a-32
PH-17	Question (D4-17)	AC-R2d-15
PH-22	Question (D4-20)	AC-R2a-45
PH-23	Adopted; Follow-up	AC-R3a-26; AC-R3b-16; AC-R6-17 (D4-16)	FEAT-007's "80% fewer multi-project workarounds" is a post-GA outcome measure, left to the UX research plan as a follow-up.
PH-25	Adopted	AC-ALL-19	Blinded export columns are in the disclosure probes.
PH-27	Question (D2-15)	AC-R1a-10
PH-29	Adopted	AC-R0-15	Reuses ServiceVersionFloor and ADR-019's tripwire.
PH-30	Adopted	AC-R4a-40
PH-32	Corrected	AC-R4a-13; AC-ALL-09
DS-04	Adopted	AC-R2a-42; §4.34
DS-07	Adopted	AC-S0-07; §8.1
DS-08	Adopted	§4.1; AC-M0-05
DS-09	Adopted	AC-S0-01
DS-10	Corrected	AC-R0-08
DS-11	Adopted	§8.3; AC-ALL-04
DS-12	Adopted	AC-ALL-09
DS-13	Adopted	AC-ALL-13; §8.3
DS-16	Question (D1-06); answered 3 October	§5.3; PI-ALL-02	Standing tester panel and batched sessions.