Specification: stage pools, steps, capacity and history

Temporary planning specification, written on 5 October 2026 from the owner session of 4–5 October. It turns consolidation §3 and the stage-filters clarification into a design detailed enough for the T-SP-00 brief ("stage pools, steps, capacity and history"). Owner decisions recorded here are planning approval. Brief approval and implementation authorisation are separate decisions taken per gate (D1-04), and both remain on hold. No work has started, no gate has passed and nothing is enabled in production. Storage names, fields, indexes and numbers are PROPOSALs for the F1a storage and naming ADRs and the F3 workflow freeze unless a decision ID is cited. Where this page and an older package text disagree, the consolidation wins, then this page. §13 lists the package documents to amend.

Sources. Primary: consolidation §3; stage study filters and steps; the session register entries Q-15, Q-24, Q-28, Q-01, Q-02 (Batch B), D3-09, D3-13, D3-16 to D3-20 (Batch D3), D4-15 and D4-19, and every section appended after its sources note (pool-departure continuation, targeted pool history, eligibility explanation, historical coverage, entry justification, structured events, required queries and reviewer-pool browsing); the condensed packages O4 and E4, the carry-forward and brief tables and the browsing clarifications. Context: FEAT-008 stage filtering, the stage and step access-policy proposal (unapproved research input), the owner ledger (EW1, DP6, DP7, LC1, RX2), contracts C6, C7 and C12, the domain model, programme integration §3–§6 and the consistency model.

Sibling specifications. Sessions, targets and overrides: RD. Duplicate merge identities: DM. Outcome states, blinding, hints and adjudication: RS. Legacy conversion: BC. PRISMA use of history: RI. Screens: UX. Contribution exclusion and project deletion: ACD.

1. Summary in plain English

This specification explains five things:

• how SyRF decides which Studies a stage works on;
• how it decides which work each reviewer is offered;
• how steps inside a stage depend on each other;
• how capacity, timeouts and in-progress limits work when one form is used by several stages;
• how SyRF keeps structured history so that an admin can later explain why a Study was, or was not, reviewed.

Six ideas carry the design.

1. A stage study filter defines the stage pool. The filter is a set of clauses joined by AND and OR groups. A clause asks about a Study's current screening result under a named screening profile, or about its accepted (reconciled) answer to a named annotation question. A Study is in the stage pool while its current evidence satisfies the filter. There is no other gate into a stage.
2. Being in the pool says nothing about work. Allocation, batches, permissions, capacity, step rules and evidence that is already sufficient decide what work is offered, when and to whom. A Study can sit in a pool with nothing left to do.
3. Steps live inside a stage. Each step contains screening, annotation or both. A step can depend on earlier steps. A separate exclusion-stop setting says whether an Exclude stops further progression. By default a reviewer moves on after their own Include while the team result is still pending. A stage setting can make everyone wait for the team's Include instead. Beside these review steps, SyRF adds a system adjudication step for screening ties, and a project may add training steps (§3.4).
4. Evidence belongs to the project. A form or profile that is already sufficiently reviewed needs no repeat work when a new stage uses it. SyRF never invents a stage-local review to explain why nothing was asked.
5. Current pools are calculated; history is recorded. SyRF calculates the current pool from current evidence whenever it is needed. Separately, it records immutable, structured events when membership actually changes, when a reviewer starts work and what made that start legitimate. Decisions about current access never read that history.
6. Leaving a pool never erases evidence. A valid result recorded through a stage can make its own Study leave that stage's pool. SyRF accepts the result, records the departure and its cause, stops new offers and, by default, lets reviewers finish work they had already started. An authorised admin can restrict that.

The table shows the layers this page keeps apart.

Layer	Plain question	How SyRF knows	Stored?
Project Study	Is this a current reviewable Study?	Study state, lifecycle status and search withdrawal	Yes, the Study document
Stage pool	Does the Study match this stage's filter now?	The filter evaluated against current evidence	No, calculated on read
Stage pool history	When and why did it enter or leave the pool?	StagePoolBaselineMember, StagePoolEntered and StagePoolDeparted events	Yes, immutable events
Reviewer study pool	Which pool Studies can Alice work on in this stage now?	Stage pool, then Alice's allocation or assignment, then current availability	No, calculated on read
Offered work	Which step would Next or Browse give Alice now?	One admission decision per request	No; page queries are not logged
First release	When was work in this stage first released to anyone?	WorkFirstReleased event	Yes
Started review	When did Alice begin, through which route, and why was that allowed?	ReviewStarted event carrying ReviewStartEligibility	Yes
Saved and completed review	What did Alice submit?	Session versions and decision revisions	Yes, existing records
Saved work outside the pool	Can Alice finish what she started after the Study left?	Continuation rules; each completion records its basis	Derived, with the basis stored on the version

A short example. In a stroke review, the "Full text" stage has the filter "title/abstract result is Included AND full-text result is not Excluded". Alice and Bob both Exclude Okafor 2021 at full text, so the full-text result becomes Excluded. SyRF saves Bob's decision first. It then sees that Okafor 2021 no longer matches the filter and records a departure that names Bob's decision as the cause and the failing clause. Nobody is offered new work on Okafor 2021 in that stage. Chandra had already started extracting outcomes for it. She sees it under Saved work and may finish. PRISMA still reports Okafor 2021 as excluded at full text.

Out of scope. A separate stage-entry gate. Filter clauses that depend on which reviewer is asking. Answer-based branching between steps (D4-15, deferred beyond MVP). A stored "current pool" table trusted for access. Any history invented for the time before tracking began.

2. Decisions covered

ID	Decision in one line	Status	Section
Q-15	The stage study filter defines the pool; there is no incoming stage gate; dependencies are between steps inside a stage; exclusion-stop is a separate step setting	Replaced	§3.3, §3.4, §5.1, §5.2
Q-24	Independent annotation stays independent unless a dependency is configured; legacy stages map to steps through the opt-in wizard; new combined steps stop extra screening at sufficiency, with Allow available; Apply anyway releases temporary reservations only	Decided	§3.4, §3.11, §7, §10.4
Q-01	A reviewer may progress after their own Include while the collective result is pending; a stage setting can require collective Include; exclusion-stop still applies	Decided	§3.4, §5.2
Q-02	Automatic completion follows remaining work; static completion stays until explicit authorised reopening; admin changes show the extra work first; merges change evidence and never change stage status directly	Decided	§3.10, §4.11, §5.9
Q-28 (stage and capacity parts)	Saved work completes after screening exclusion by default and a step setting can prevent it; the form owns the inactivity timeout and per-reviewer in-progress limit; one shared place across tabs and routes; the form's capacity baseline applies to every route and a stage may be stricter	Decided	§3.9, §3.11
D4-19 (serving and browsing parts)	Random serving stays the default; optional browsing of the reviewer study pool is dynamic, blinded and never grants broader rights	Decided-amended	§3.6, §4.5
D4-15	Accepted-answer branching between steps is outside MVP; reconciled-answer clauses in stage filters stay in scope	Deferred	§3.4, §10.3
D3-09	Align the paused eligibility programme with the filter and step model	Brief item	§12.1
D3-13	Allocation and batch contracts; WorkFirstReleased kept distinct from StagePoolEntered, review start and completion	Brief item	§3.7, §12.1
D3-16	Production capacity route through admitted pilot projects	Brief item	§3.11, §12.1
D3-17	Capacity cap separate from the target; explicit defaults; no eviction	Brief item (carry-forward alignment)	§3.11, §12.1
D3-18	Form-owned timeout and in-progress limit; one shared place; stage-derived rules removed	Brief item (carry-forward alignment)	§3.11, §12.1
D3-19	Reserve the dependent annotation place at personal Include; keep the screening decision if no place is free	Brief item	§4.6, §12.1
D3-20	Reviewers see active counts and their own place; Monitor holders see names; blinding is never defeated	Brief item	§6, §12.1
D2-07	The form owns the inactivity timeout and per-reviewer in-progress limit; expiry keeps the draft (the RD spec owns sessions)	Decided	§3.11
D2-08	One shared session and place across tabs and devices (the RD spec owns sessions)	Decided	§3.11
Amendment: results produced through a stage	Accept the valid result, recalculate membership, keep the evidence and its cause, stop new offers	Decided	§4.2, §9.2
Amendment: finishing after pool departure	Started work may finish after any filter-driven departure by default; an authorised admin can restrict it; the setting's placement is still to specify	Decided	§3.9, §12.4
Amendment: targeted pool history	Current pools stay query-time; actual membership changes are recorded through targeted reevaluation	Decided	§3.5, §4.1 to §4.4
Amendment: explicit entry justification	Each entry records effective time, filter version, satisfied clauses, input versions, cause and actor	Decided	§3.5.3
Amendment: structured events and required queries	Versioned, queryable event schemas; distinct entering and exiting Studies with episodes	Decided	§3.12, §3.13
Amendment: eligibility explanation	A permission-aware admin timeline explains review and non-review honestly	Decided	§3.14
Amendment: historical pool coverage, with the reporting-priority clarification	Retain baseline and transitions for audit; reporting prioritises actual review through the stage	Decided	§3.13, §12.2
Amendment: reviewer study pool, browsing, dynamic pool and browsing blinding	The reviewer pool is a stage-specific subset; browsing is optional, dynamic and blinded	Decided	§3.6
Tie adjudication amendment (step-model mapping; RS owns the policy)	A tie routed to adjudication is handled in a system adjudication step inside the stage, never as a stage-entry dependency	Decided (mapping PROPOSAL)	§3.4, §5.12
EW1, LC1, RX2, PV2, PR1, SF1, SF2, DP4	Earlier owner decisions kept and applied (LC1's confirmation hold for automatic stages is superseded by Q-02, §3.10)	Decided	Throughout
DP6 and DP7 cross-stage part; A-06; A-18	Cross-stage route policy and its interpretations	Replaced	§14

Scope of the counts. Of the 74-entry session register, this page places Q-15, Q-24, Q-01, Q-02, Q-28, D4-19 and D4-15 among the 52 resolved, replaced, removed or deferred entries. It owns 7 of the 22 alignment and brief entries: D3-09, D3-13, D3-16, D3-17, D3-18, D3-19 and D3-20. In the repository universe of 89 those 7 sit inside the 25 alignment, brief and validation entries. D2-07 and D2-08 are among the 11 decisions outside the register that the owner session decided; the RD spec owns them. The amendments are outside the register count, and the integration document gives them OS-A IDs.

3. Concepts, entities and storage

3.1 How to read this section

Each entity block answers the same questions: what it is, its identity, its versions and pointers, whether it changes, its proposed storage and what it is not. Storage is PROPOSAL throughout. The design adds one append-only history store and a few fields on existing documents. Every other concept is derived on read.

3.2 Stage and StageSettingsVersion (existing, amended)

• What it is. A stage is a named piece of workflow, such as "Full text". Its settings version is the immutable description of how the stage works from a point in time: its filter version, the forms and profiles it binds, its steps and its stage-level defaults.
• Identity. stageId, the ID already embedded in Project. Versions are (stageId, seq).
• Versions and pointers. The Stage head holds the current settings pointer. Lifecycle status and mode live in the lifecycle part (V2-17).
• Mutability. Versions never change. Publication raises the settingsChange fence, drains, switches the pointer and releases (consistency model §7.6). A Completed stage accepts a new settings version only through an approved change request (LC1).
• What changes from the package. Removed: the incoming cross-stage route policy (the DP6 and DP7 cross-stage part, replaced by Q-15's model). Moved to the form: the target-enforcement switch (now a capacity cap), the inactivity timeout and the in-progress limit (Q-28, D3-18). Moved to the form or profile, specified by the RS spec: reconciliation identity blinding and the reconciled-answer visibility baseline, which a step may only narrow (Q-28). Added: the filter version (§3.3), the progression basis (Q-01), the exclusion-stop, saved-work and started-work settings (§3.4, §3.9), an optional stricter route capacity cap (§3.11) and the browsing setting (§3.6).
• Storage (PROPOSAL). The existing planned collections pmReviewStage and pmStageSettingsVersion (domain model §4.4).
• What it is not. A stage owns no evidence, target or session. Two stages that bind one form share one session per reviewer and one target (SF1, SF2).

3.3 StageStudyFilter and StageStudyFilterVersion

• What it is. The stage study filter is the rule that decides which current Studies are in the stage pool. The owner decided that it may combine clauses on screening-profile outcomes and on reconciled answers to specified annotation questions, using AND/OR groups (consolidation §3, item 1). A filter version is one immutable published form of that rule.
• Structure. A filter version is a tree.

Node	Fields	Reads	Notes
Group	logic (AND or OR), children (groups or clauses)	Its children	Groups nest; proposed depth limit 4 (not approved)
Profile outcome clause	profileId, op (in or notIn), states	The Study's current outcome under that profile	States Included, Excluded and Unresolved, with optional unresolved sub-states equal to the RS spec's resolutionState values (Pending, AwaitingExtraReview, InDiscussion, PendingAdjudication; RS §3.8). A collective all-Unsure state is not offered until RS §5.10 decides it
Accepted answer clause	questionId, the accepted question versions, op (in, notIn, anyOf, allOf, hasAcceptedAnswer, hasNoAcceptedAnswer), option identities or typed values, an optional authority restriction	The Study's current accepted answer to that question	Whole-Study answer context in MVP; entity-scoped clauses are ambiguity SP-AMB-06
Base predicate (implicit)	None	Study state, lifecycle status, search withdrawal	Always joined to the root with AND; not editable

"Current outcome" means the final facet when an adjudicated or merge-resolved final result exists (RS §3.8 finalSource), including one flagged "inputs changed" (RS-R58), and otherwise the candidate collective facet evaluated by the profile rule (ScreeningOutcome, domain model §4.2). It never means one reviewer's own decision. "Current accepted answer" means the answer in the Study's current AcceptedResultVersion of any authority (SingleAnnotator, HumanReconciled, Adjudicated, MergeResolved) unless the clause restricts authority (ambiguity SP-AMB-02). Option identities follow VA-05, so a wording change to an option never breaks a clause.

• Clause kinds left out on purpose. A reviewer's own decision or progress (the owner did not approve reviewer-dependent pool clauses). Membership of another stage's pool. Remaining work, capacity or allocation facts. These omissions keep the filter the same for every reviewer and make recursion impossible, because a filter only reads preserved project evidence.
• Evaluation. Three-valued. A clause is True, False or Unknown. It is Unknown when its input cannot be evaluated, for example an accepted answer recorded under a question version that the clause does not accept. Groups combine values with the usual three-valued AND and OR. A Study is a member only when the root is True. Unknown therefore fails closed, and the explanation shows which clause was Unknown and why (PROPOSAL).
• Identity. filterVersionId, deterministic over (stageId, filterSeq). A stage has exactly one filter, so the filter needs no identity of its own beyond the stage.
• Versions and pointers. A new filterSeq is minted whenever the clause tree changes. Each stage settings version references exactly one filter version. A settings version that changes only steps keeps the same filterVersionId. The filter version's activatedAt is the HLC stamp of the settings version that first activated it.
• Dependency set. Computed at publication and stored with the version: the profile IDs and question IDs that its clauses read. Targeted reevaluation uses it (§4.2, §4.3).
• Validation at publication. Referenced profiles and questions exist and are published. Groups are not empty. FEAT-008's same-profile simplifier runs before compilation; it stays a correctness rule for matching screeningOutcomes[] entries. A tree that is always False or always True warns and needs confirmation. A clause that reads a profile or question bound in the same stage shows the feedback notice: "Results recorded in this stage can remove Studies from its pool. Reviewers keep their evidence, and by default they can finish work they have started." (The wording is a PROPOSAL; the owner asked that configuration explain this feedback effect.)
• Mutability. Immutable once published. Edits happen in the stage designer's draft and write no history.
• Storage (PROPOSAL). Embedded in pmStageSettingsVersion as filter {filterVersionId, seq, root, dependencySet, digest}. No collection of its own. FEAT-008's Filter Set JSON (schema v2) becomes filter schema v3: accepted-answer clauses keyed by option identity, the implicit base predicate and three-valued evaluation. A legacy stage without a filter keeps FEAT-008's "no Filter Set means all project studies" until conversion maps it (§10.4).
• What it is not. It is not an admission rule for a reviewer. It does not decide whether work is needed. A filter failure is not a screening exclusion.

Example filters used in §9:

Stage	Filter	Plain meaning
Title and abstract	Base predicate only	Every current Study
Full text	TA in {Included} AND FT notIn {Excluded}	The team included it at title/abstract, and full-text screening has not excluded it
Rodent synthesis	FT in {Included} AND (Species anyOf {rat, mouse} OR Model in {MCAO})	Included at full text, and the accepted species is rat or mouse or the accepted model is MCAO

3.4 Review steps

• What it is. A step is one unit of reviewer work inside a stage. It contains a screening activity (a screening profile), an annotation activity (a form) or both.
• Identity. stepId, stable across settings versions so that provenance and history can follow a step. Steps are stored inside the stage settings version.
• Mutability. Changed only by publishing a new stage settings version.

Step kinds (added in the 5 October harmonisation; kinds other than review steps are PROPOSAL).

Kind	Contents	Dependencies	Exclusion-stop	Source
Review step	A screening activity, an annotation activity or both	Configured explicitly by the designer (this section)	Its own settings (table below)	Q-15 (owner)
Adjudication step	System-defined. The adjudication activity for one screening profile: its open AdjudicationTasks for any trigger (RS-R52, RS-R59); for decision triggers the outcome is PendingAdjudication. It accompanies each screening step whose profile can route work to adjudication, which in practice is every profile (RS-R51)	Designers add none to or from it. Downstream steps depend on the screening step and read its outcome	None of its own. The screening step's collective exclusion-stop applies once the adjudicated outcome is a definite Exclude	Tie amendment ("a separate explicit adjudication step ... not a separate hidden stage-entry dependency"); mapping PROPOSAL
Training step	Practice on bound form or profile versions against training references (TI §3.1)	None by default. A live step may depend on "passed this training step" only if TI-R23's optional PROPOSAL is adopted	None	S4 expansion (owner); step mechanics PROPOSAL

An adjudication step is shown only to eligible adjudicators (RS-R17, RS-R53, RS-R54). Adjudication resolves decisions already submitted, as reconciliation does, so its tasks are not limited to the stage's current pool: a reason disagreement on a Study that the Excluded outcome moved out of the pool stays reachable (PROPOSAL). This is not a new review outside the pool (SP-R34). Open adjudication work is remaining work for automatic completion of each stage that binds the profile (§3.10). Discussion and extra review are not steps; they stay inside the screening step's resolution route (RS §3.10, RS-R51). Training attempts create no live work, claims or pool events (TI-R04). Rules SP-R91 and SP-R92 (§5.12) state these kinds.

Step and stage settings.

Setting	Level	Values	Default	Source
Activities	Step	Screening profile, form, or both	None	Q-15; stage filters §2
Display order	Step	Integer	None	Never creates a dependency (stage filters §2)
Depends on	Step	AND/OR group of prerequisite steps	None	Stage filters §2
Progression after own Include	Stage	OwnIncludeSufficient or CollectiveIncludeRequired	OwnIncludeSufficient	Q-01 (owner)
Tighten-only progression override	Step	CollectiveIncludeRequired	Inherit	Q-01's original recommendation (PROPOSAL)
Extra screening after sufficiency	Step with screening	Stop or Allow	Stop for new combined steps; legacy value preserved by mapping	Q-24 (owner)
Exclusion-stop: personal	Step with screening	A reviewer's own Exclude stops that reviewer's progression in scope: on or off	On (PROPOSAL)	Stage filters §3 requires stated defaults; the within-stage handoff table (C6)
Exclusion-stop: collective	Step with screening	A collective Exclude is terminal for new work in scope: on or off	On (PROPOSAL)	Q-01; DP6 veto
Exclusion-stop scope	Step with screening	DependentSteps (direct and transitive dependants) or an explicit step list	DependentSteps (PROPOSAL)	Stage filters "apply the configured termination scope"
Saved work after screening exclusion	Stage default, step override	AllowCompletion or PreserveOnly	AllowCompletion	Q-28; EW1 (owner)
Started work after leaving the pool	Placement open	Allow or Restrict	Allow	Owner amendment; placement is SP-AMB-01
Reconciled-answer visibility	Step	Hide-only narrowing of the form baseline	Inherit	Q-28 (the RS spec owns it)
Compulsory, handoff allowed	Step	Carried from C6	As C6	C6 (PROPOSAL)

When a dependency is satisfied for reviewer R (owner basis cited; mechanics PROPOSAL).

Prerequisite activity	Basis in force	Satisfied when
Screening under profile P	OwnIncludeSufficient (stage default, Q-01)	R's current decision under P is Include (or Unsure, under the RS-R47 PROPOSAL), even while the collective result is pending. Or R has no decision and P's current outcome is Included, in which case SyRF records collective satisfaction and invents no vote
Screening under profile P	CollectiveIncludeRequired (stage setting, Q-01)	P's current outcome is Included
Annotation with form F	Either	R's current session for F is Completed, or F is already sufficient for the Study through qualifying evidence from any route (collective satisfaction, no duplicate work)
Both	Either	Both rows above hold

Exclusion-stop then applies on top. With the personal setting on, R's own current Exclude under P blocks R from the scope even when collective satisfaction would otherwise admit R. With the collective setting on, a collective Exclude under P stops new work in the scope for everyone; an adjudicated Exclude is a collective Exclude, while a pending outcome (AwaitingExtraReview, InDiscussion, PendingAdjudication) never triggers exclusion-stop (RS-R57). Steps outside the scope are untouched. Own Unsure (PROPOSAL, consistent with D4-01, identical to RS-R47). Under OwnIncludeSufficient, a reviewer's own current Unsure satisfies the dependency exactly as their own Include does and tries the dependent claim as an own Include does (D3-19). It never satisfies CollectiveIncludeRequired, never counts as a definite Include and never triggers personal exclusion-stop. The single confirm item is in RS §12; SP-AMB-04 is retired into it.

Pending never means ignoring an Exclude. Alice may move to the extraction step after her own Include while the team result is pending. If the team result later becomes Excluded and the collective exclusion-stop is on, no new work is offered in the scope. Work Alice already started becomes saved work under the saved-work setting (§3.9).

Already-sufficient evidence. Step eligibility uses the current applicable evidence for the Study across the whole project. A form whose effective target is already met, or a profile whose sufficiency rule is already met, offers no new work in any step, whichever stage collected the evidence. Binding such a form or profile into a new stage creates no new evidence target. If every activity in the stage is sufficient, the Study stays in the pool with nothing to do. SyRF records no stage-local review, vote or submission to explain this. Extra screening after sufficiency is offered only where a step says Allow. Effective targets (RD spec) and publication treatment still apply, so an authorised target or requirement change can later create work.

Terminal exclusion before offering. When a governing screening step's profile is already collectively Excluded and its collective exclusion-stop is on, SyRF applies that result before offering any work in the scope. This holds even if nobody reviewed the Study through this stage. The governing step's own extra screening is not offered either (PROPOSAL). The Study stays in the pool unless the filter itself excludes it.

Remaining work. For reviewer R, a step activity has remaining work when the dependency is satisfied, exclusion-stop does not apply, the activity is not yet sufficient (or extra screening is allowed) and R has not completed it. For "anyone", the same test runs without the per-reviewer parts. Automatic stage completion (§3.10) and the "no remaining work" explanation use the "anyone" form.

• What it is not. A step owns no evidence and no target. No step-level target override exists (consolidation §1). Display order is never a dependency. Branching on accepted answer values between steps is deferred beyond MVP (D4-15).

3.5 The stage pool and its history

3.5.1 The current stage pool (derived)

• What it is. The set of current Studies whose evidence satisfies the stage's current filter version right now.
• How it is read. Selection, browsing, admission, counts and Monitor views compile the current filter version into a predicate over the Study document and its canonical summary (screeningOutcomes[] and filterInputs[], §3.5.2). The predicate carries the current binding and definition vector as constants, so a Study whose projection is stale is not offered (consistency model §8.2). Nothing reads history or the tracking marker for this.
• Storage. None. A stored membership cache is allowed only if every read proves it current for its input vector, and only if the F3 benchmark shows the compiled predicate cannot meet the selection budget (PROPOSAL).
• What it is not. It is not a count of reviewed Studies, it does not grant any reviewer access and it does not prove that work existed.

3.5.2 Filter inputs on Study

• What it is. Study.CanonicalSummary.filterInputs[]: a small projection of the Study's current accepted answers for the questions that any current filter version in the project reads. Each entry holds the question ID, the accepted answer (option identities or typed value), the AcceptedResultVersion ID, its authority and its stamp.
• Written by. The command that changes the accepted result (gold publication, target-one automatic acceptance, merge resolution), in the same transaction as the Study write that CR-1 already requires. When a new filter version starts reading a question that no current filter read before, a preparation operation fills the entries before that version activates (§4.1).
• Storage (PROPOSAL). A new part of Study.CanonicalSummary. The alternative, a lookup into the gold store at query time, is kept as a fallback for the F3 benchmark.

3.5.3 Pool transition events and entry justification

Three event types record membership. Each is a HistoryEvent (§3.12).

Event	Written when	Carries
StagePoolBaselineMember	Tracking starts for a stage whose pool already existed (conversion, or the first release of history for an existing canonical stage)	The matching filter version and clause evaluation; coverage BaselineAtTrackingStart; no earlier entry time and no invented cause
StagePoolEntered	Membership changes from out to in	Entry justification (below)
StagePoolDeparted	Membership changes from in to out	The failing clauses, the causal change, reason codes and the evidence versions

Entry justification (owner amendment). Every entry records:

• the effective time (when the cause became current) and the recorded time;
• the exact filter version and the full clause evaluation tree, marking which groups and clauses were satisfied;
• the supporting input versions: the screening outcome versions and accepted result versions read by each clause, and the Study version;
• the causal change: import, a screening outcome change, an accepted answer change, a filter version activation, a merge or unmerge, a search reinstatement or a lifecycle change, with the command or operation ID and the cause record's ID;
• the actor where one exists: the member, the system rule, an AI screening model (named as such), or the operator.

Entry justification records filter eligibility only. Permission, allocation and capacity eligibility to review belong to ReviewStartEligibility (§3.8).

Departure reasons distinguish:

Reason code	Meaning
SCREENING_OUTCOME_EXCLUDED	A failing profile outcome clause whose input changed to Excluded
SCREENING_OUTCOME_CHANGED	A failing profile outcome clause whose input moved to another state, for example back to Unresolved after a correction
ACCEPTED_ANSWER_NOT_MATCHING	A failing accepted answer clause whose accepted value changed
ACCEPTED_ANSWER_ABSENT	The accepted answer the clause needs no longer exists in the current result
CLAUSE_UNKNOWN	A clause could not be evaluated and failed closed
FILTER_RECONFIGURED	Unchanged evidence fails a new filter version
STUDY_NOT_CURRENT_MERGED	The Study stopped being current because of a StudyMerge
STUDY_NOT_CURRENT_UNMERGED	A consolidated Study stopped being current because of a StudyUnmerge
HIDDEN_BY_SEARCH_WITHDRAWAL	Withdrawal hid the Study and no other current search supports it
LIFECYCLE_NOT_ACTIVE	The Study's lifecycle status left Active

A departure is labelled SCREENING_OUTCOME_EXCLUDED only when that is the actual failing input. Filter failure is never automatically a screening exclusion.

3.5.4 Episodes and the per-study tracking marker

• Episode. Each entry (or baseline membership) opens an episode for the Study in that stage, and the next departure closes it. Episodes are numbered per (Study, stage). A re-entry opens episode 2. It never creates a second distinct Study.
• Tracking marker (PROPOSAL). Study.CanonicalSummary.stagePoolTracking[], one entry per tracked stage, holding stageId, filterVersionId, member, episodeSeq, lastEventSeq, lastEvaluatedStamp and inputDigest. It is the last recorded membership. Commands and operations use it to detect transitions exactly once and to order them. No admission, selection or count ever reads it.
• Why it works. Every filter input changes through a Study write (CR-1): decisions, outcomes, accepted results, imports, merges, withdrawals and lifecycle changes all write the Study. Each such transaction can therefore compare the marker with the new evaluation and record the difference in the same commit.

3.5.5 Baseline

Tracking for a newly created canonical stage starts when the stage first becomes Active. Its members at that moment get StagePoolEntered with cause StageActivated, because coverage is complete from that point. StagePoolBaselineMember is used only when a pool existed before tracking could observe it: baseline conversion of a legacy stage (BC spec) or the first release of pool history for a canonical stage created earlier. Baseline events carry the tracking start as their effective time and say that earlier history was not recorded.

3.6 Reviewer study pool, offered work and browsing

• Reviewer study pool (owner definition). The reviewer study pool is stage-specific. It is the subset of the stage's current pool allocated or assigned to that reviewer and currently available under the applicable review rules. It is derived on read and never stored.
• Allocation scope. Until AL1, canonical stages refuse proportional allocation (D3-13a), so every eligible member's allocation scope is the whole stage pool. Explicit assignments (for example an additional-review request naming Bob) add or narrow scope as recorded.
• Currently available. At least one step activity passes the admission decision for this reviewer: permission, stage Active, batch access, dependency satisfied, exclusion-stop not applying, remaining work, a place already held or obtainable, and the in-progress limit.
• Offered work. Next serves randomly from the reviewer pool by default (D4-19). Explicit assignment is an audited exception. Browse lists the pool when enabled. A direct link opens one Study. All three call the same admission decision, which is evaluated again at start and at submit.
• Dynamic. A Study that leaves the stage pool also leaves the reviewer pool at once. A Study that becomes unavailable to the reviewer (no place, batch not open, dependency unmet) leaves it too. Assignment records, review history and drafts stay. SyRF keeps the recorded causes of availability changes (pool events, assignments, allocation regime and batch records, settings versions, permission audit) with stage and reviewer context, and derives a reviewer's availability history from them. Whether per-reviewer availability changes also need their own events is ambiguity SP-AMB-13.
• Saved work outside the pool. Started work that may continue after a departure appears in a separate Saved work list (§3.9). It is not in either current pool.

Browsing (owner addition and clarifications).

Aspect	Rule
Enablement	Optional and explicitly enabled. PROPOSAL: a stage setting, off by default, under the Design stage capability. The owner left configuration ownership to the brief
Content	The reviewer pool only, never an unrestricted assignment list
Per row	Bibliographic details (hidden where the profile's bibliographic blinding is on), the reviewer's own status per step (Not started, Draft auto-saved, Version checkpoint saved, Completed; final wording per U1), the reviewer's step availability ("Available", "Waiting for the team's screening result", "Enough reviewers", "Stopped by exclusion"), applicable accepted results under their visibility rules, and the active reviewer count (D3-20)
Never shown	Other reviewers' candidate decisions, candidate answers, vote tallies, identities or identity-revealing metadata such as their submission times
Ordering	PROPOSAL: a stable per-reviewer shuffle or bibliographic sort. Never an order derived from other reviewers' activity
Freshness	Re-evaluated on load and on invalidation hints. Starting or resuming re-checks admission on the server
Stale items	Opening a Study that left the pool returns a typed reason, rendered under blinding (for example "No longer available in this stage")
Rights	Browsing grants nothing. Pool membership alone never allows starting or submitting

• What it is not. The browse list is not a reservation and not a permission. Removing an item never revokes permitted continuation.

3.7 Work release, allocation and batches

• WorkFirstReleased. The first time work in a stage was released to anyone for a Study. This renames the round-2 StudyEnteredPool (FEAT-011's pool-entry event), so that it no longer clashes with stage pool entry. Exactly one per (Study, stage), with releaseKind:

releaseKind	Written by
SharedBatchOpened	The shared batch opening command (CAS on the batch plan); a large batch runs as an operation
PersonalBatchGrant	The personal grant command (CAS on the access row)
ExplicitAssignment	An assignment that releases work for a Study nobody could take before
UnbatchedAvailability	For a stage without batches, the transaction that first makes the Study a member of an Active stage's pool while some step activity has remaining work for anyone. The trigger can be a pool entry, a stage activation or a target increase that creates work (PROPOSAL; ambiguity SP-AMB-10)
InheritedThroughMerge	The activation of a StudyMerge, for each stage where an input had already been released; the event links the earliest input release, so the consolidated Study is never delayed behind work already released (DM §3.8; PROPOSAL). Restored Studies after an unmerge keep their original release records

Later shared openings and personal grants for the same Study stay in the batch plan's own durable records. Only the first release becomes WorkFirstReleased.

• What it is not. It is not pool entry, a review start or a completion (D3-13 treatment). A Study can enter a pool and never be released, because its evidence is already sufficient.
• Allocation (D3-13a, brief). Proportional allocation stays refused on canonical stages until AL1. AL1 then restricts the reviewer pool through the form-keyed regime.
• Additional reviews (consolidation §1; D3-13 context update). A request for additional reviews raises the effective Study and form target through StudyTargetOverride (RD spec), may name people or groups and counts qualifying reviewers once across routes. The original D3-13© "bypass once, audited, target unchanged" is superseded. With the capacity cap following the effective target (§3.11), the requested reviewer has a place.
• "Who is offered what" (D3-13d). Pool-level counts by refusal reason until the out-of-request resolver (X-AUTH-RESOLVER) exists. Per-reviewer rows follow it.
• Batches (D3-13b, e, f). Batch membership is defined over stage pool episodes (StagePoolEntered and baseline members). Late entrants join as separately shuffled cohorts. Sufficiently excluded Studies stay in the denominator and count as finished, and restored scope returns to its original membership (the #3939 disposition, still to be recorded in the ledger). Departures for other reasons are ambiguity SP-AMB-09. Openings and grants are durable CAS transitions; status reads never mutate. A performance gate precedes any enablement.

3.8 ReviewStartEligibility and the completion basis

• What it is. The record of why a reviewer was allowed to start work at the moment they started. Pool membership alone does not show why a particular reviewer was offered work, so this is recorded separately (owner amendment).
• When. On the first start of a session through a route, meaning the first command that creates the reviewer's work for that Study activity through that stage and step. For a form that is the first autosave, which creates the FormSession, or the first explicit Save if that comes first. For a screening-only step it is the first draft of eligibility answers, or the decision submission itself. Reaching the same shared session later through another stage writes one more start for that route.
• Fields.

Group	Fields
Route	stageId, stageSettingsVersionId, stepId, activity (profileId or formId), sessionId
Pool basis	filterVersionId, compact clause evaluation, input versions (outcome and accepted result versions), current episode reference
Step basis	Each dependency's result and basis (own decision revision ID, collective outcome version or sufficiency facts); exclusion-stop evaluation; progression basis in force
Allocation basis	Allocation regime ID and version (or "none"), batch plan ID, revision and ordinal or personal grant, assignment ID, StudyTargetOverride or additional-review request ID
Availability basis	Capacity cap version, places before start, claim reference, or NotEnforced (tracking off); in-progress limit version and count; the capability evaluated and the authorization audit reference
Decision	Admission decision digest; actor (the reviewer); effective and recorded time

• Storage (PROPOSAL). A ReviewStarted HistoryEvent whose payload is the ReviewStartEligibility. Its ID is deterministic over (session, route stage, route step) and it is inserted with $setOnInsert, so a start is written exactly once. It is written outside the Study transaction when the start is an autosave (autosave never writes Study).
• Completion basis (PROPOSAL). Each explicit session version and decision revision gains admissionBasis, which lists every basis that applied: InPool, ContinuationAfterExclusion {outcomeVersion, settingVersion} and ContinuationAfterDeparture {departureEventId, settingVersion}. When both continuation triggers applied, both entries are present. The RD spec owns the version records; this page adds the field. It gives the admin the explicit explanation the owner asked for when started work was completed after departure.
• Reconciliation starts keep the existing ReconciliationStarted record with its readiness basis (RS spec) and appear in the same timeline through the envelope adapter. Adjudication claims (RS §4.11) appear the same way.
• What it is not. It is not an offer log. Opening a Study and leaving without editing records no start.

3.9 Finishing started work after exclusion or pool departure

Two triggers can end new work on a Study while a reviewer has work in progress.

Trigger	Default	Restriction	Source
A screening exclusion inside the stage stops progression (exclusion-stop)	Saved work may be completed	PreserveOnly on the step (stage default with step override) keeps drafts and refuses completion	Q-28; EW1 (owner)
Any filter-driven departure from the stage pool	Started work may continue and be completed	An authorised admin can configure a restriction that prevents continuation and completion	Owner amendment (4 October)

Rules for both:

• "Started" means a ReviewStarted exists for that session and route before the trigger, so a draft counts (PROPOSAL). Opening without editing does not count.
• Continuation never restores pool membership and never admits new reviews. Permissions and capacity still apply. A reviewer whose place lapsed on timeout must re-acquire one when the cap is on (D2-07; Q-28).
• Drafts are preserved in every case.
• Continuation work is shown in Saved work with its reason, rendered under blinding.
• When both triggers apply, completion is allowed only if every applicable setting allows it (PROPOSAL).
• Before an admin changes either setting, SyRF shows which active reviewers are affected. Affected reviewers are told afterwards. The change, its actor and its time are recorded in the settings version.

Placement of the departure setting. The owner said the exact placement is not yet specified and must not be inferred silently. Options and a recommendation are in §12.4 (SP-AMB-01).

3.10 Stage lifecycle: automatic and static completion

• Modes. Automatic or manual (static), in the lifecycle part (RX2, LC1).
• Automatic readiness. No current pool member has remaining work for anyone (§3.4), and no adjudication work is open in the stage's adjudication steps (RS-R59). No unresolved drafts, outstanding corrections or pending change requests remain (LC1). Permitted continuation drafts count as unresolved work while continuation is allowed (PROPOSAL). Pool membership alone never counts as remaining work (Q-02).
• Recalculation. A durable intent re-evaluates readiness for the affected stages after any change that can alter remaining work: pool entries and departures, outcome and accepted-answer changes, target changes, step setting changes and continuation changes. Completion keeps the two-step protocol (Completing fence, drain, verify, Completed).
• Static completion. A manually completed stage stays Completed even when more work appears. Reopening is a separate authorised action (Q-02).
• Admin changes. Before an admin confirms a change that adds Studies with remaining work (an import, a filter edit, a target increase), SyRF shows the additional work per stage and the completion effect, and rechecks at commit (Q-02). A protected change acting on a Completed stage itself (its settings, filter, Fix or corrections) also needs that specific change approved, as LC1's change request already provides; Q-02 calls this "approve the specific protected change".
• When remaining work appears (decided, Q-02; consolidation §3). An automatic Completed stage is recalculated as soon as remaining work appears, whether the cause is a confirmed admin change or evidence recorded elsewhere. It goes back through the two-step lifecycle with no further confirmation hold, and admins of the stage are told. A manually or statically completed stage stays Completed until an explicit authorised reopening. A pool entry into a Completed stage never blocks the upstream command. This supersedes LC1's "obtain confirmation before admitting a change that would reopen a Completed stage" for automatic stages (AC-R3c-03 amendment in §13); SP-AMB-05 is closed.
• Merges. A merge changes review evidence. Stage membership changes only through ordinary reevaluation, and status changes only through these readiness rules (Q-02).

3.11 Places, capacity cap, inactivity timeout and in-progress limit

• Place. A reviewer's held position on a Study for one form (or profile). One shared session holds one place across every tab, device and stage route (D2-08, Q-28). Places are held by a draft-backed claim while the reviewer is active, and by saved-incomplete, completed and Needs updating sessions; withdrawal frees the place (C7, PROPOSAL). Claims follow claim contract v2, keyed by form identity, never by version.
• Effective target and capacity cap. The effective target (RD spec) is the minimum evidence. The CapacityCap is the maximum number of places. They are separate concepts (D3-17; consolidation §1).

Setting	Owner	Values	Default	Status
CapacityCap	Form baseline, applied through every route	Off, EffectiveTarget, EffectiveTargetPlus(n)	Off; when enabled, EffectiveTarget	Separation and baseline decided (Q-28, D3-17); defaults proposed, not approved
Route capacity cap	Stage, per bound form	Stricter than the form baseline only	None	Q-28 allows stricter stage rules (owner); shape PROPOSAL
Inactivity timeout	Form	Minutes	Today's idle-timeout default, value to read from code	Ownership decided (D2-07, Q-28); default not approved
Per-reviewer in-progress limit	Form	Count or unlimited	Unlimited	Ownership decided (D2-07, Q-28); default not approved

• Shared count. One place count per Study and form across all routes. A route cap only refuses admission through that route.
• No eviction. Lowering or enabling a cap never removes a held place. New acquisitions are refused until the count falls below the cap. Temporary reservations that conflict can be released only through explicit Apply anyway (Q-24, §7). A cap never falls below a Study's effective target, so authorised target increases and requested reviews are never blocked (PROPOSAL, following D3-17's "respect study-specific target changes").
• In-progress. PROPOSAL: a Study counts as in progress for a reviewer and form while they hold a place there without a completed version. A shared session counts once. Legacy MaxInProgress semantics are verified during conversion.
• Timeout. Activity on any connection keeps the shared place. An idle or closed tab never releases it while another connection is active (Q-28). When the session times out, SyRF releases the place and keeps the draft (D2-07). Completing it later re-checks capacity.
• No stage override for timeout or limit. The old rules ("the most restrictive bound stage sets the cap and the idle timeout; the stage in use sets the in-progress limit") are removed (D3-18).
• Screening. Screening capacity follows the profile's collective rule (eligibility D6). Who owns the timeout and limit for screening-only work is ambiguity SP-AMB-03.
• Dependent places (D3-19). No place is held on a dependent form while the reviewer is still screening. The reviewer's own Include (or own Unsure, under the RS-R47 PROPOSAL) tries the dependent claim atomically in the decision transaction. If no place is free, the step shows "Enough reviewers are already working on this" and the screening decision stands. Under CollectiveIncludeRequired, the claim is tried when the reviewer next opens the step after the collective Include (PROPOSAL).
• Enforcement exists only when tracking is on. Claims and capacity guards exist only while active reviewer tracking is effective, which is off in every deployed environment. The production route is D3-16 (§12.1). Where tracking is off, the admin UI says "capacity not enforced", and ReviewStartEligibility records NotEnforced (tracking off).
• Storage (PROPOSAL). Form-level settings live in the AnnotationForm's audited operational settings record (not pinned by sessions; D2-05 classification). The route cap lives in the stage settings version. Claims stay on Study.
• What it is not. The cap is not the target. A timeout never deletes a draft. The in-progress limit never blocks completing work already held.

3.12 The HistoryEvent envelope

• What it is. The common, versioned shape for structured history records (C20, new contract). New facts that no existing immutable record carries are stored as HistoryEvents: pool transitions, first release and review start. Existing immutable records (session versions, decision revisions, outcome history entries, adjudication versions, accepted result versions, stage settings versions, lifecycle and change-request entries, assignments, StudyTargetOverride, ContributionExclusion, StudyMerge, StudyUnmerge, search withdrawals, external screening runs) stay where they are. Timeline and reporting projections read them through adapters into the same shape, so nothing is copied and source history never changes.
• This is not an event-sourced application. Current state keeps its own authoritative records.

Fields.

Field	Content
eventId	CSUUID, deterministic: SHA-256 over (event type, project, idempotency key)
eventType	Closed string set, extended only through C20: StagePoolBaselineMember, StagePoolEntered, StagePoolDeparted, WorkFirstReleased, ReviewStarted (adapters add the types of existing records; see the note below the table)
family	PoolTransition, WorkRelease, ReviewerEligibility, ReviewActivity, Configuration
schemaVersion	Integer per event type; old versions stay readable forever
projectId, studyId	Always present for the event types above
lineage	StudyMerge or StudyUnmerge reference and the related Study IDs, where identity changed
stageId, stepId, activity	Structured and indexed; the owner requires stage identity and event type as queryable fields
subjectReviewerId	Whose work or eligibility the event concerns, if any
actor	{kind: Member, SystemRule, AIScreeningModel, ExternalSource or Operator; id}. An AI screening model is a source identity, never a member login
effectiveAt	{hlc, utc}: when the causal change became current
recordedAt	{hlc, utc}: when this record was written
cause	{kind, commandId or operationId, causeRecordRefs}. Kinds: Import, ScreeningOutcomeChanged, AcceptedAnswerChanged, FilterVersionActivated, StageActivated, StudyMerged, StudyUnmerged, SearchWithdrawn, SearchReinstated, LifecycleChanged, ContributionExcluded, ProfilePublicationApplied, FormPublicationApplied, ExternalScreeningAccepted, TargetChanged, BatchOpened, PersonalGrant, AssignmentCreated, ReviewerAction, TrackingBaseline, BaselineConversion
sourceVersions	Filter version, stage settings version, profile and form versions, outcome versions, accepted result versions, regime, batch plan, capacity and continuation setting versions, as relevant
before, after	For pool events {member, episodeSeq}; for others the relevant state
reasonCodes	Ordered, closed set (§3.5.3 for departures; entries use ALL_CLAUSES_SATISFIED plus the cause)
clauseEvaluation	Tree mirroring the filter: {nodeId, kind, result (True, False or Unknown), inputs [{kind, ref, version, observedValue}], children}
coverage	Complete, BaselineAtTrackingStart, ReconstructedFromRetainedInputs, NotRecordedInLegacy or CurrentSnapshotOnly
seq	Per (Study, stage) monotonic sequence taken from the tracking marker
explanationText	Optional plain text. It supplements the structured fields and never replaces them

Event types named in other specifications. RD, DM, RS, BC, TI, RI and AC name further event types (for example FormVersionPublished, StudyMerged, AcceptedResultVersionCreated, BaselineConverted, TrainingAttemptStarted, ContributionExcluded; all PROPOSAL names). Each is either an adapter type over the existing immutable record that already carries the fact, or, where no such record exists, a new HistoryEvent type added to the closed set through the C20 contract. The C20 freeze lists which is which (PROPOSAL, added in the 5 October harmonisation).

Ordering. Events order by effectiveAt.hlc, then studyId, then stageId, then seq. Because every filter-input change writes the Study (CR-1), stamps and sequences on one Study increase strictly. A filter sweep that reaches a Study after a later evidence change has already recorded the filter transition (§4.1) never inserts out of order.

Idempotency keys.

Event	Key
StagePoolEntered, StagePoolDeparted	(Study, stage, cause command or operation ID, filter version, episode)
StagePoolBaselineMember	(Study, stage, tracking start ID)
WorkFirstReleased	(Study, stage)
ReviewStarted	(session, route stage, route step)

A duplicate key on insert is success. Retries, re-executions and operation takeovers therefore never create duplicates.

Effective and recorded time. Events written in the transaction that changed the evidence have effectiveAt equal to recordedAt. Events written by a filter sweep take the filter version's activation stamp as effectiveAt and the item's stamp as recordedAt. Baseline events take the tracking start. Converted legacy facts take the conversion time with coverage NotRecordedInLegacy for anything earlier. Wall-clock values are shown to people; HLC stamps order records.

Current reads never trust delayed history. Admission, selection, counts and readiness read authoritative current inputs or a cache proven current. History explains the past and is never a second source of current truth.

Storage (PROPOSAL). One append-only collection, pmHistoryEvent, replacing the planned pmStudyPoolLedger. Indexes: unique _id; {projectId, stageId, eventType, effectiveAt.hlc}; {projectId, studyId, effectiveAt.hlc}; {projectId, subjectReviewerId, eventType, effectiveAt.hlc}. The F1a storage ADR may instead split families into collections. Inserts only, no TTL, retained while the project exists (reversible deletion retains it; permanent erasure is an unapproved policy).

3.13 Event queries and projections

Query	Returns	Counting rule
Entered stage pool	Distinct Studies with StagePoolEntered in the period (optionally with baseline members), each with its episodes and reasons	One row per distinct Study, whatever the number of entries
Exited stage pool	Distinct Studies with StagePoolDeparted in the period, with episodes and departure reasons	As above
Ever in pool during a period	Members at the period start (from the last event at or before it) plus Studies entering during it	Distinct Studies
Membership as of T	Members at T	Distinct Studies
Episodes for a Study	Every entry and departure with justification	All rows
Departure reasons	Distinct Studies per reason in the period	Reasons can overlap and are labelled as overlapping; never summed as a distinct total
Reviewed through the stage	Distinct Studies with a ReviewStarted or completed version routed through the stage, with eligibility provenance	Separate from pool membership; evidence collected elsewhere is listed as "satisfied elsewhere" and never counted as reviewed here

• Identity modes. RecordedIdentity counts the Study IDs as recorded. ConsolidatedLineage resolves Studies tombstoned by a merge to the consolidated Study current at the report point. Which mode a PRISMA box uses is a specialist decision (T-SI-05, with the DM and RI specs; SP-AMB-08).
• As-of watermark for history. An as-of view at T is offered only when the C11 watermark allows T and no filter sweep with an activation at or before T is still running or stalled (PROPOSAL). Frozen report snapshots store their computed result and watermark and never change.
• Projections. Start with indexed queries over events. A rebuildable episode projection is added only if the benchmark requires it, and it must rebuild identically from events.
• Access. Stage pool history and other reviewers' eligibility need the Monitor capability. Reviewers see their own starts and the explanations for their own availability (§6).

3.14 The admin eligibility explanation

• What it is. A permission-aware Study timeline that explains why a Study was available, reviewed, not reviewed or no longer available, so that apparent inconsistencies are not mistaken for platform errors (owner goal).
• Inputs. Pool events with their clause trees; ReviewStarted records and completion bases; session versions, decisions, outcomes and accepted results through adapters; relevant configuration versions (filter, steps, exclusion-stop, sufficiency, continuation, capacity, allocation regime, batches, assignments, permission audit) when they explain a change in work eligibility; and a current evaluation of the admission decision.
• Current reason categories (closed set, extending AccessDenialReason append-only): OutsidePool, NoRemainingWork (already sufficiently reviewed, possibly through another stage), TerminatedByExclusion, AwaitingPriorStep, AwaitingCollectiveInclude, StageNotActive, StageCompleted, PublicationInProgress, NotAllocatedToReviewer, BatchNotOpen, NoPermission, AtCapacity, InProgressLimitReached, ContinuationRestricted and SavedWorkOnly.
• Honesty rules. Historical explanations use the versions in force at the time and never substitute current settings. A recorded block reason is shown as recorded. When the Study was eligible and nobody reviewed it, the timeline says "No review is recorded" and invents no cause. Historical availability for a specific reviewer is reconstructed only from retained inputs. Claims and refused page queries are not retained, so a past "no place free" cannot be shown and the gap is stated. Periods before tracking are labelled ("Pool history before 20 September 2026 is not recorded; this project was converted then").
• What it is not. It does not log page queries, and it is not a second source of current access truth.

3.15 Storage summary

Concept	Stored as (PROPOSAL)	New collection?
Filter version	Embedded in pmStageSettingsVersion	No
Steps and stage-level settings	Embedded in pmStageSettingsVersion	No
Current stage pool	Not stored	No
Filter inputs	Study.CanonicalSummary.filterInputs[]	No
Tracking marker	Study.CanonicalSummary.stagePoolTracking[]	No
Pool events, first release, review start	pmHistoryEvent (replaces pmStudyPoolLedger)	One, replacing a planned one
Completion basis	admissionBasis on existing version records	No
Capacity, timeout and limit	AnnotationForm operational settings record; route cap in the stage settings version	No
Reviewer pool, offered work, explanation	Derived on read	No

4. What loads and writes when

Every interactive command follows the consistency model's commit shape: ledger check, uncached snapshot reads, refusals before any write, pure derivation, one bulk write per collection and one transaction (consistency model §4.1). The tables below add what this specification needs.

4.1 An admin publishes a filter change

Step	Reads	Writes	Notes
Preview	Current settings version, the draft filter, compiled old and new predicates over Study summaries, lifecycle status, started work on departing Studies, capacity settings	Nothing	Shows Studies entering and departing with reasons, started work affected (counts; names only for Monitor holders), and the completion effect on automatic and manual stages
Prepare	Questions the new version reads that no current filter reads	filterInputs[] entries on Studies with an accepted answer to them (version-guarded Study writes in an operation)	Activation waits until preparation completes. Accepted-answer commands read the running preparation operation and also write entries for the questions it is preparing
Commit	Stage head, fence state, preview digest	Fence, drain, digest recheck; then one transaction: insert the settings version with its embedded filter version, CAS the pointer, write the sweep operation record (durable intent), release	If the digest changed, release and ask the admin to confirm again. The commit stamp is the activation stamp
Immediately after	None	None	Selection, browsing and admission read the new filter at once
Sweep	Studies matching the old or the new predicate (or all current Studies), in stable studyId order	Per Study, one short transaction: read the marker; skip if already at the new version; evaluate the new version and compare it with the marker's recorded membership (no marker entry means not a member); on a difference insert StagePoolEntered or StagePoolDeparted (effectiveAt = activation stamp, cause FilterVersionActivated, both clause trees); update the marker; Study version CAS	Operation record with lease, generation and final pass; locked Studies are deferred
Derived	Readiness for the stage	Readiness intent; notices to reviewers with started work on departing Studies (when notification delivery is enabled)	Automatic and manual stages follow §3.10

A Study that enters only under the new version is found, because the sweep reads the new predicate as well as the old one. Evaluating against current evidence is correct for the activation time: if the Study's evidence had changed since activation, that change's own transaction would already have caught the marker up to the new version (§3.5.4), and the sweep would skip the Study.

4.2 A reviewer submits a screening decision

This walkthrough covers the case where the reviewer's own result makes the Study leave the pool.

Phase	Content
Reads	Study (summary, outcomes, tracking marker, clock, claims), stage settings pointer and version (filter, steps), profile version, membership facts, the reviewer's own session, drafts
Refusals before writing	The consistency model's set, plus StepLocked (dependency unmet for a new start), TerminatedByExclusion (new start in a terminal scope) and ContinuationRestricted (started work after a trigger, restricted)
One transaction	Decision revision; profile session version with admissionBasis; ScreeningOutcome recomputed by the collective outcome policy; Study summary. If the outcome's current value changed, then for each filter whose dependency set contains the profile: first record any filter-version catch-up from the marker, then evaluate before and after, insert pool events (cause ScreeningOutcomeChanged, command ID, decision revision ID) and update the marker. Also ReviewStarted on a first start, the dependent form claim at own Include (D3-19), WorkFirstReleased for entries into an Active unbatched stage with remaining work, and the command ledger record
What is not done	The submission is never rejected because its own result removes the Study. Evidence is never rolled back. No other filters are evaluated
After commit	Claims of reviewers with no started work on the departed Study are released through the revocation outbox; notices to reviewers with started work; readiness intent; invalidation hints

Concurrent submissions on the same Study serialise on the Study document (CR-1). A command that loses re-executes from a fresh snapshot. If the Study has meanwhile left the pool, its work counts as started work under the continuation rules: accepted with basis ContinuationAfterDeparture, or refused with ContinuationRestricted and the draft kept.

4.3 Accepted answers change

Phase	Content
Writers	Gold publication (HumanReconciled), target-one automatic acceptance (SingleAnnotator), adjudication of profile-owned screening annotations (Adjudicated), merge resolution (MergeResolved), explicit reconsideration after a correction or contribution exclusion
One transaction	The accepted result version and pointer; Study summary including filterInputs[] for referenced questions; pool events for filters whose dependency set contains a changed question; marker update
Pre-commit warning	A reconciler who can see the evidence is told which stages the Study would leave or enter and how many reviewers have started work there (counts only, D3-20)

4.4 Imports, withdrawal, lifecycle, merge, unmerge and publication treatments

Cause	Writer	Pool effect	Events
Import of new Studies	Import job (batches)	New Studies evaluated against every current filter	StagePoolEntered (cause Import, effectiveAt = Study creation stamp), written in the Study creation write or by a durable intent per batch
Search withdrawal or reinstatement	Withdrawal command	Base predicate changes for Studies with no other current search	Departure HIDDEN_BY_SEARCH_WITHDRAWAL, or re-entry
Lifecycle change	Lifecycle policy	Base predicate	Departure LIFECYCLE_NOT_ACTIVE, or re-entry
Merge	StudyMerge operation (DM spec)	Tombstoned originals stop being current; the consolidated Study is evaluated	Departures STUDY_NOT_CURRENT_MERGED with lineage; entries for the consolidated Study with cause StudyMerged where it matches
Unmerge	StudyUnmerge operation	The consolidated Study is tombstoned; restored originals are evaluated	Departure STUDY_NOT_CURRENT_UNMERGED; entries for restored originals with cause StudyUnmerged
Contribution exclusion (O1)	ACD spec command	Candidate facets are recomputed; adjudicated final facets and accepted results stay current, flagged, and change only through explicit reconsideration (RS-R58; ACD §3.2)	As §4.2 when an outcome changes
Profile or form publication treatment	Publication phase 2 items	Outcomes or accepted values change under the recorded treatment, including results suspended below a raised target, which filters read as absent (RS-R10)	Pool events per study item, cause ProfilePublicationApplied or FormPublicationApplied
AI or external screening decisions accepted (E3)	Import acceptance command	Outcomes change under the declared profile source policy	As §4.2, with the actor kind AIScreeningModel or ExternalSource and the importer recorded separately
Project deletion and restoration	ACD spec	None per Study; review is blocked while the project is deleted	None per Study. Restoration rechecks availability and capacity

4.5 A reviewer asks for the next Study, opens one or browses

Phase	Content
Reads	Compiled pool predicate, the reviewer's membership facts, step settings, batch and allocation records, capacity and limit settings, permissions
Next	Random choice from the reviewer pool (D4-19); with tracking on, a claim acquisition in one conditional Study update (AtCapacity, EnoughReviewers or StepLocked if refused); no study left means "No more studies available"
Browse	The same predicate and admission per row, without claims; a payload containing no other reviewers' candidate data
Direct open	The same admission for one Study; a typed reason if refused
Writes	A claim only. No history event: page queries and offers are not logged

4.6 A reviewer starts work, and an own Include reserves the next step

Phase	Content
First autosave on a form	The FormSession is upserted by its deterministic ID with $setOnInsert and the draft is written (no Study write). Admission is evaluated in the snapshot, and ReviewStarted is inserted with its eligibility payload
Own Include on a screening step with a dependent form	Inside the decision transaction (§4.2), an atomic conditional claim for the dependent form is attempted. If refused, the decision commits, the dependent step shows "Enough reviewers are already working on this", and the refusal reason is returned (D3-19)
Under CollectiveIncludeRequired	No dependent claim at own Include. The dependent step shows "Waiting for the team's screening result"

4.7 A reviewer saves or completes, inside the pool or by continuation

Situation	Admission at commit	Writes
Study in the pool, step available	Normal admission	Session version with admissionBasis = InPool
Study in the pool, exclusion-stop applies, work started before the exclusion	Saved-work setting	ContinuationAfterExclusion if allowed; otherwise ContinuationRestricted with the draft kept
Study left the pool, work started before the departure	Departure continuation setting, permissions, capacity	ContinuationAfterDeparture with the departure event ID; or ContinuationRestricted
Study left the pool, no start recorded	Refused: no new reviews outside the pool	Nothing; the draft (if any) is kept

4.8 An admin changes a continuation, capacity, timeout or limit setting

Phase	Content
Preview	Affected active reviewers and sessions: continuation work that would be refused; places above a new cap; temporary reservations that conflict; sessions that a shorter timeout would release; reviewers over a lower limit (counts, with names for Monitor holders)
Choice	Cancel, or Apply anyway where temporary reservations conflict (Q-24)
Commit	Recheck the impact against current state; in one transaction write the new settings version and release only the affected temporary reservations (revocation intents); drafts and completed work are kept
After	Affected reviewers are told; the settings version records actor, time and whether Apply anyway was used

4.9 A shared place times out

The PM timer reads draft activity and every connection for the session in one snapshot. If no connection is active beyond the form's timeout, it releases the claim (a Study claim-set update) and keeps the draft. No history event is written. A later Complete records its own admission basis, including any re-acquired place.

4.10 An admin opens the eligibility explanation

It reads the Study's events, the adapters over existing records, configuration versions that explain eligibility changes, coverage metadata and a current admission evaluation. That evaluation is pool-level, or per reviewer once X-AUTH-RESOLVER exists. It renders an ordered timeline with plain sentences generated from structured fields and a details view of each clause tree. It writes nothing.

4.11 Stage completion and reopening

A readiness intent per affected stage runs the two-step completion for automatic stages, and runs the reopening of an automatic Completed stage as soon as remaining work appears (§3.10; Q-02). A manual Reopen is an authorised command that writes status history.

4.12 Reporting and audit queries

Queries run against pmHistoryEvent indexes and adapters, at a watermark (§3.13). Frozen snapshots store their results. Nothing on the interactive path reads them.

5. Rules

5.1 Filter and pool

• SP-R01 The stage study filter alone defines the stage pool. No separately configured incoming dependency gate into a stage exists. Owner decision Q-15 (consolidation §3, item 1; stage filters §1).
• SP-R02 Filter clauses read current screening-profile outcomes and current accepted answers to specified annotation questions, combined with nested AND/OR groups. Owner decision Q-15.
• SP-R03 No filter clause depends on the reviewer asking, on another stage's pool, on remaining work, on capacity or on allocation. The reviewer-dependent part is the owner's boundary (stage filters, Q-15 section); the other exclusions are PROPOSAL.
• SP-R04 Every filter includes the implicit base predicate: the Study is current, its lifecycle status is Active and search withdrawal does not hide it. PROPOSAL, following the existing rule that only Active Studies appear in stage pools and Q-33/D3-12.
• SP-R05 Evaluation is three-valued and fails closed on Unknown, and explanations show the Unknown clause. PROPOSAL.
• SP-R06 Filter versions are immutable. A filter change publishes a new filter version inside a new stage settings version under the settingsChange fence, and its activation stamp is its effective time. PROPOSAL, consistent with PV2.
• SP-R07 Pool membership means neither that review is needed nor that it occurred. Owner decision (consolidation §3, item 3).
• SP-R08 Current pools are calculated at query time from authoritative current inputs, or from a cache proven current for its input vector, and never from history. Owner amendment: targeted pool history.
• SP-R09 Filters and step eligibility read project-wide evidence. Stages that use one profile share its outcome (DP4). Owner decision (stage filters, "pool membership versus actual review").
• SP-R10 The designer explains the feedback effect whenever a clause reads an activity bound in the same stage. Owner requirement (stage filters, "results produced through a stage"); wording PROPOSAL.
• SP-R11 A filter failure is not a screening exclusion. Every departure carries its actual reason. Owner requirement (historical pool coverage).
• SP-R12 Leaving a pool never erases, invalidates or rolls back the evidence that caused the departure. Owner decision (consolidation §3).

5.2 Steps and progression

• SP-R13 A step contains screening, annotation or both. Dependencies are configured explicitly, and display order creates none. Owner decision Q-15 (stage filters §2).
• SP-R14 Dependencies exist only between steps inside a stage. Owner decision Q-15.
• SP-R15 By default a reviewer progresses after their own Include while the collective result is pending. Owner decision Q-01.
• SP-R16 A stage setting can require collective Include before progression. It is off by default. Owner decision Q-01.
• SP-R17 A step may tighten progression to collective Include, and can never loosen it. PROPOSAL (Q-01's original recommendation, retained with pilot validation).
• SP-R18 Pending never ignores an eventual Exclude. When a collective Exclude arrives, the configured exclusion-stop applies. Owner decision Q-01 and consolidation §3.
• SP-R19 Exclusion-stop is a separate step setting with an explicit personal basis, collective basis and scope. Owner decision Q-15 (stage filters §3).
• SP-R20 Exclusion-stop defaults: personal on, collective terminal on, scope DependentSteps. PROPOSAL (from the confirmed within-stage table in C6 and Q-01; the owner requires stated defaults).
• SP-R21 Independent steps stay independent unless a dependency is configured. Termination never silently blocks activities outside its scope. Owner decision Q-24 and stage filters ("termination scope").
• SP-R22 Collective satisfaction admits a reviewer without a decision and records no vote. Confirmed within-stage table (C6); stage filters ("do not fabricate").
• SP-R23 An annotation prerequisite is satisfied by the reviewer's own completed session or by the activity already being sufficient. PROPOSAL.
• SP-R24 New combined steps stop offering extra screening once the profile's sufficiency rule is met. A designer can choose Allow, and annotation follows its own target and dependencies. Owner decision Q-24.
• SP-R25 No step dependency conditions on accepted answer values in MVP. Deferred, D4-15.
• SP-R26 When access or activity settings change, newly disallowed actions are refused while drafts and saved work are kept, subject to continuation rules and current permissions. Owner decision Q-24.

5.3 Sufficiency and terminal exclusion

• SP-R27 Already-sufficient forms and profiles need no duplicate work in any stage. Binding them into a new stage creates no new evidence target. Owner decision (stage filters, "already sufficient evidence"; consolidation §3).
• SP-R28 A Study with no remaining work stays in the pool and is not offered. SyRF fabricates no stage-local review, vote or submission. Owner decision (stage filters).
• SP-R29 A terminal collective exclusion applies before any offer in its scope, even if nobody reviewed the Study through this stage, and the Study stays in the pool. Owner decision (consolidation §3; stage filters, "existing collective exclusion").
• SP-R30 Explanations and counts distinguish no remaining work, terminal exclusion and temporarily unavailable work. Owner decision (stage filters).
• SP-R31 Effective targets and publication treatment still apply. An authorised target or requirement change can create new work later. Owner decision (stage filters).

5.4 Finishing started work

• SP-R32 Saved work may be completed after a screening exclusion by default. A step setting can prevent it while keeping drafts. Owner decision Q-28; EW1.
• SP-R33 Already-started work may continue after any filter-driven departure by default. An authorised admin can configure a restriction that prevents continuation and completion. Owner amendment: finishing after pool departure.
• SP-R34 Continuation never restores membership of either current pool and never admits new reviews. Permissions and capacity still apply. Owner amendment.
• SP-R35 Continuation work is shown separately as saved work. Owner definition of the reviewer study pool.
• SP-R36 "Started" means a ReviewStarted recorded before the trigger. PROPOSAL.
• SP-R37 When both triggers apply, completion needs every applicable setting to allow it. PROPOSAL.
• SP-R38 A change to either setting first shows its effect on active reviewers, then notifies them, and records actor and time. Owner amendment.

5.5 Pool history and structured events

• SP-R39 SyRF records initial tracking membership, every entry, departure and re-entry, with causes and exact filter and evidence versions. Owner decision (consolidation §3, structured justification).
• SP-R40 When a current outcome or accepted answer changes, SyRF reevaluates only the filters whose dependency set contains the changed profile or question, and it evaluates the whole filter. Owner amendment: targeted pool history.
• SP-R41 Ordinary draft saves and page queries trigger no reevaluation and no history. Owner amendment.
• SP-R42 A filter change evaluates the potentially affected Studies under both the old and the new version, and never omits entering Studies. Owner amendment.
• SP-R43 Every other filter input triggers its dependent filters: import, merge, unmerge, withdrawal, lifecycle, contribution exclusion, publication treatments and accepted external or AI screening decisions. Owner amendment ("changes to any other inputs").
• SP-R44 Each entry records its effective time, filter version, satisfied clause and group evaluation, input versions, causal change and actor. Owner amendment: explicit entry justification.
• SP-R45 Departures distinguish a screening Exclude from other clause failures, filter reconfiguration, withdrawal, merge, unmerge and lifecycle changes. Owner requirement.
• SP-R46 Effective time is when the causal change became current, and recorded time is kept separately. Owner amendment.
• SP-R47 Processing is ordered and idempotent: deterministic IDs, a per-(Study, stage) sequence and marker catch-up. Owner requirement; mechanism PROPOSAL.
• SP-R48 Events are immutable, keep their original schema versions and are queried through projections that never change source history. Owner requirement (structured events).
• SP-R49 Admission, selection, counts and readiness never read history or the tracking marker. Owner amendment.
• SP-R50 Baseline events never invent an earlier entry time or cause, and coverage limits are disclosed. Owner amendment.
• SP-R51 A Study tombstoned by a merge departs. Current Studies are reevaluated, lineage is kept, and a merge changes evidence without directly changing membership or status. Owner decisions (consolidation §3; historical coverage).
• SP-R52 Access control and blinding apply to event queries and to displayed provenance. Owner requirement.

5.6 Reviewer pool, serving and browsing

• SP-R53 The reviewer study pool is the stage-specific subset of the current stage pool allocated or assigned to the reviewer and currently available. Owner definition.
• SP-R54 A Study leaving the stage pool leaves the reviewer pool. The reviewer pool is re-evaluated dynamically. Assignment records, review starts and the recorded causes of availability changes are kept with stage and reviewer context. Owner clarification; the granularity of availability history is SP-AMB-13.
• SP-R55 Random serving is the default, and explicit assignment is an audited exception. Owner decision D4-19 through O4.
• SP-R56 Browsing is optional and explicitly enabled. Owner addition; the stage-level, off by default placement is PROPOSAL.
• SP-R57 Browsing grants no rights beyond the reviewer's scope, and starting re-checks current eligibility. Owner addition and clarification.
• SP-R58 Browsing hides other reviewers' candidate decisions, answers and identity-revealing metadata. Reconciled results appear only under their visibility rules. Owner clarification.
• SP-R59 Removal from the browse list never silently revokes permitted continuation, and the reason is shown. Owner clarification.

5.7 Release, allocation and batches

• SP-R60 WorkFirstReleased, StagePoolEntered, ReviewStarted and completion are distinct events. D3-13 treatment (brief item); owner requirement.
• SP-R61 First release to anyone is recorded once per Study and stage, with shared openings and personal grants recorded separately. D3-13e recommendation (brief item).
• SP-R62 Proportional allocation stays refused on canonical stages until AL1. D3-13a recommendation (brief item).
• SP-R63 Additional-review requests raise the effective Study and form target, may name people or groups, and count reviewers once across routes. No invisible bypass exists. Owner decision (consolidation §1; D3-13 context update).
• SP-R64 Sufficiently excluded Studies stay in a batch's denominator and count as finished, and restored scope returns to its original membership. D3-13b (brief item; the ledger record is still pending).
• SP-R65 "Who is offered what" shows pool-level counts by refusal reason until X-AUTH-RESOLVER exists. D3-13d (brief item).

5.8 Places, capacity, timeout and limits

• SP-R66 The capacity cap is separate from the effective target, and the target stays a minimum. Owner decision (consolidation §1); D3-17.
• SP-R67 The form owns the capacity baseline, applied through every route. A stage may be stricter, and one shared count applies. Owner decision Q-28.
• SP-R68 The cap is off by default, and an enabled cap defaults to the effective target. Proposed, not approved (D3-17).
• SP-R69 No cap evicts existing work, and caps respect authorised Study-specific target changes and requested reviews. D3-17 (brief item); owner decision on targets.
• SP-R70 The form owns the inactivity timeout and the per-reviewer in-progress limit across all stages and tabs, with no stage override. Owner decisions Q-28 and D2-07; D3-18 alignment.
• SP-R71 One shared session and place covers all tabs, routes and devices. An idle tab never releases the place while another connection is active, and timeout releases the place but keeps the draft. Owner decisions Q-28, D2-07 and D2-08.
• SP-R72 The dependent annotation place is reserved at personal Include (and at personal Unsure under the RS-R47 PROPOSAL), never while screening is underway, and a refusal keeps the screening decision. D3-19 (brief item).
• SP-R73 Reviewers see active counts and their own place. Names require the Monitor capability, and nothing defeats reconciliation identity blinding. D3-20 (brief item).
• SP-R74 Apply anyway releases affected temporary reservations only, atomically with the setting, and never bypasses authorisation, allocation constraints or invalid configuration. Owner decision Q-24.
• SP-R75 Capacity protection reaches production through admitted pilot projects first and is never silently enabled fleet-wide. D3-16 recommendation (brief item).

5.9 Stage lifecycle

• SP-R76 Automatic completion follows remaining-work rules, and pool membership alone is never remaining work. An automatic Completed stage is recalculated as soon as remaining work appears, with no further confirmation hold. Owner decision Q-02; consolidation §3 (supersedes LC1's hold for automatic stages).
• SP-R77 A manually or statically completed stage stays Completed until an explicit authorised reopening. Owner decision Q-02.
• SP-R78 Admin changes that add work show the additional work and completion effect before confirmation, and are rechecked at commit. Owner decision Q-02.
• SP-R79 A merge changes review evidence and never directly changes stage membership or status. Owner decision (consolidation §3; Q-02 context).
• SP-R80 A pool entry into a Completed stage never blocks the upstream command. PROPOSAL, consistent with Q-02 (§3.10).

5.10 Explanation and reporting

• SP-R81 The admin eligibility explanation combines pool events, review starts and submissions with their routes, the relevant configuration changes, current reason categories and explicit continuation explanations. Owner goal.
• SP-R82 Historical explanations use the versions in force at the time. Owner goal.
• SP-R83 "No review is recorded" is shown when the Study was eligible and unreviewed, and no cause is invented. Owner goal.
• SP-R84 Coverage gaps are shown honestly, and pre-tracking history is never fabricated. Owner goal and historical coverage requirement.
• SP-R85 Queries return the distinct Studies that entered or exited a stage pool, with optional periods and access to every episode and reason, and re-entry never double counts. Owner requirement (required event queries).
• SP-R86 Actual review through the stage is measured separately from pool history, and evidence collected elsewhere is never counted as reviewed there. Owner clarification (reporting priority).
• SP-R87 Frozen report snapshots never change, and as-of views are reproducible at a watermark. Owner requirement.

5.11 Legacy mapping

• SP-R88 Legacy stages have no steps. The opt-in wizard maps their actual behaviour to steps and invents no historical step settings. Owner decision Q-24.
• SP-R89 The wizard preserves and maps the actual excluded-work policy, stage mode and Allow or Stop value explicitly, and explains behaviour changes for authorised confirmation. Owner decision Q-24.
• SP-R90 Conversion starts pool history with labelled baseline events, and earlier history is marked as not recorded in legacy. Owner direction R4 (BC spec); owner amendment on baselines.

5.12 Step kinds (added in the 5 October harmonisation)

• SP-R91 Besides review steps (screening, annotation or both), a stage may hold a system-defined adjudication step beside each screening step (RS-R59) and training steps (TI §3.1). Neither kind creates an evidence target or a stage-entry dependency. A live step depends on a training step only if TI-R23's optional dependency is adopted. Owner: tie amendment ("a separate explicit adjudication step ... part of the configured workflow"); S4 expansion ("a dedicated training step"); placement and mechanics PROPOSAL.
• SP-R92 An adjudication step offers its profile's open AdjudicationTasks, only to eligible adjudicators, including tasks whose Study left the stage pool because of the outcome being adjudicated. Designers add no dependency edge to or from it; downstream steps depend on the screening step and read its outcome. It has no exclusion-stop setting; the screening step's collective exclusion-stop applies once the adjudicated outcome is a definite Exclude. Open adjudication work is remaining work for automatic completion. PROPOSAL (the tie amendment asks the brief to map adjudication into the step model; RS-R57, RS-R59).

6. Authorisation, blinding and provenance

• Who configures. Editing a filter, steps, exclusion-stop, progression basis and browsing needs the Design stage capability. Restricting continuation, completing and reopening stages need Manage stage. Changing form capacity, timeout and limit settings needs the form's design or publish authority. The exact capability IDs come from the C10 catalogue (Q-03); this page names no new role.
• Who sees history. Stage pool history, other reviewers' starts and per-reviewer explanations need the Monitor capability. Reviewers see their own starts, saved work and the reasons for their own availability. Monitor holders may see personal votes (OD5); reviewer-facing messages never reveal them.
• Clause inputs. Pool events cite collective outcomes and accepted results, never one reviewer's candidate decision. When shown to reviewers, they follow the configured visibility of reconciled screening decisions and the form baseline with step hide-only narrowing (RS spec).
• Reconciliation identity blinding (form- or profile-owned, RS spec) applies to timelines, presence, browse rows and notices. PROPOSAL: the Monitor capability never reveals candidate identities for a Study whose blinded reconciliation the viewer holds or is assigned (SP-AMB-07).
• Predictive warnings to reviewers. A candidate reviewer is never told in advance that their decision will complete an outcome or move the Study out of a pool when that would reveal other candidates' decisions. The designer's static explanation covers that case. Admins and reconcilers, who can already see the inputs, get full previews (PROPOSAL).
• Presence (D3-20). Presence payloads carry counts and the recipient's own place. Names go only to Monitor holders, and never across reconciliation blinding (AC-T-08).
• Actor provenance. Every event names its actor kind. An AI-model-generated screening decision names the AI screening model as its source, separately from the importing user (E3). System rules name the rule and its version.
• Exports. History events are a versioned dataset exportable under the audit and export permission with the manifest rules of C11 (RI spec for reporting use).

7. Active-work impacts

Action	Warned before commit	Rechecked at commit	Told afterwards	Apply anyway
Filter edit	Entering and departing Studies with reasons; started work on departing Studies; completion effects	Preview digest under the fence	Reviewers with started work on departing Studies; admins of affected stages	Not needed: temporary reservations on departing Studies are released as part of the change
Progression basis or exclusion-stop change	Reviewers whose dependent steps would lock; started work becomes saved work under the continuation settings	Digest under the fence	Affected reviewers	Releases temporary reservations on newly locked steps only
Continuation restriction (either trigger)	Active reviewers whose continuation would be refused; drafts are kept	Current continuation work	Those reviewers	Not applicable
Enabling or lowering a capacity cap	Places above the cap (kept); conflicting temporary reservations	Current claims	Reviewers whose reservations were released	Releases conflicting temporary reservations only (Q-24)
Shorter timeout	Sessions a shorter timeout would release at the next check (counted from the change, never retroactively)	Current activity	None until a release happens	Not applicable
Lower in-progress limit	Reviewers over the new limit (they keep their work; new acquisitions are refused); temporary reservations above the new limit	Current counts	Those reviewers	Optional: releases temporary reservations above the new limit only (Q-24); without it, held work stays and new acquisitions are refused
Accepted-answer publication	Stages the Study would leave or enter; count of reviewers with started work	Inputs and gold pointer	Reviewers with started work there	Not applicable
Reviewer decision	Nothing that reveals other candidates' decisions (§6)	Standard admission	Reviewers with started work, after a departure	Not applicable
Manual completion or reopening	Remaining work and drafts	Readiness	Stage reviewers	Not applicable
Merge or unmerge (DM spec)	Pool effects per stage, as part of the DM preview	Inputs	Affected reviewers	Per DM spec

Apply anyway never bypasses permissions, allocation constraints or invalid configuration, and never deletes drafts or completed work (Q-24). General active-work previews are specified in the ACD spec; the screens are in the UX spec.

8. Failure and recovery

Failure	Effect	Handling
Sweep operation crashes	History lags behind; current pools are correct	Lease takeover with generation fencing; idempotent items; the marker skips done Studies; as-of views refused until the sweep has applied
Sweep stalls at its limit	As above	stalled state; the owner is notified; current reads unaffected; as-of views for later T refused
Event insert retried	Possible duplicate	Deterministic ID; duplicate key treated as success
Study transaction aborts	No evidence and no event	Re-execution from a fresh snapshot (C18)
Indeterminate commit	Unknown	Command ledger returns the original result or OutcomeUnknown
filterInputs[] stale or missing	Clause Unknown, not a member	Vector check fails closed (StaleProjection); preparation or the sweep repairs it
Clock skew between hosts	Ordering risk	HLC stamps with the drift refusal (A-28)
Restore from backup	Events after the restore point are lost	History-discontinuity record per project; the integrity checker compares markers with events and rebuilds markers from events; current pools are recomputed
Marker and events disagree	Possible missed transition	Integrity checker detects it; repair records the transition with coverage ReconstructedFromRetainedInputs
Study left the pool between listing and click	Stale browse row	Typed reason on open; list refresh
Continuation restricted while a reviewer edits	Save or Complete refused	ContinuationRestricted; draft kept; the form becomes read-only with an explanation
Batch opening partly applied	Partial release	CAS on the plan; large openings run as operations with deterministic WorkFirstReleased IDs
Capacity race between routes	Over-allocation risk	Atomic claim filter on Study (AtCapacity, EnoughReviewers)
Legacy writer touches a canonical scope	Inconsistent history	Refused by the ownership marker (C16)
Episode projection corrupted (if built)	Wrong query results	Rebuild from events and verify parity

9. User flows and examples

Cast. Dev is the project admin (Design stage and Manage stage). Ellen is a reconciler with the Monitor capability. Alice, Bob and Chandra are reviewers. Femi is the methodologist who prepares reports.

Project. A stroke neuroprotection review. Profiles: TA (title/abstract; two agreeing decisions; Unsure on; extra review with a bound of one) and FT (full text; two agreeing decisions; extra review with a bound of one; RS-R50 requires the tie policy to be explicit). Forms: Design (effective target 2), Outcomes (target 1 with automatic acceptance), Funding (target 1) and Risk of bias (target 2).

Stage	Filter	Steps
1 Title and abstract	Base predicate only	1.1 TA screening
2 Full text	TA in {Included} AND FT notIn {Excluded}	2.1 FT screening with the Design form (combined); 2.2 Outcomes, depends on 2.1; 2.3 Funding, independent. Exclusion-stop on 2.1: personal on, collective on, scope DependentSteps (2.2)
3 Rodent synthesis	FT in {Included} AND (Species anyOf {rat} OR Model in {MCAO})	3.1 Risk of bias

9.1 Own Include and the collective-Include setting (Smith 2019)

1. Alice opens Smith 2019 in stage 2. The step strip shows 2.1 as available (state: loading, then available). She records Include under FT and completes the Design form. Bob has not screened yet, so the FT result is pending.
2. With the default OwnIncludeSufficient, step 2.2 opens for Alice at once. Tracking is still off in this project, so no claim is made and capacity is not enforced. With tracking on, her Include would try the Outcomes claim in the same transaction (D3-19).
3. If Dev had set stage 2 to CollectiveIncludeRequired, step 2.2 would show "Waiting for the team's screening result" (state: pending), and no Outcomes place would be held.
4. Bob later Includes. FT becomes Included. Smith 2019 enters stage 3 only if its accepted species is rat or its model is MCAO. Stage 2 membership does not change (it was already a member).

9.2 A result recorded through a stage makes its own Study leave (Okafor 2021)

1. Okafor 2021 is in stage 2. Chandra Included it under FT on 2 October and started step 2.2. Her ReviewStarted records the pool basis (filter version 3, TA outcome version 5), her own Include revision as the step basis, and "capacity not enforced (tracking off)".
2. On 4 October Alice Excludes. The FT result stays unresolved with one Include and one Exclude (state: AwaitingExtraReview, one more decision needed, hidden from candidates).
3. Bob Excludes. His command validates against the current state and commits his decision. The collective outcome policy sets FT to Excluded (two agreeing Excludes).
4. In the same transaction SyRF looks up the filters that read FT: stages 2 and 3. Stage 2 now fails (FT notIn {Excluded} is False), so SyRF inserts StagePoolDeparted with cause ScreeningOutcomeChanged, Bob's command and decision revision as cause records, reason SCREENING_OUTCOME_EXCLUDED, the clause tree and the input versions. Stage 3 was not a member, so nothing is written for it. Bob's decision is not rejected and nothing is rolled back.
5. Bob sees "Decision saved". Okafor 2021 leaves his reviewer pool. He is not told in advance that his decision would complete the result, because that would reveal Alice's vote.
6. Chandra's Saved work list shows "Okafor 2021: no longer in the Full text stage. You can finish your saved work." Both triggers apply: the collective exclusion-stop covers 2.2, and the Study left the pool. The saved-work setting (AllowCompletion) and the departure continuation setting (Allow) both allow completion, so she may finish. Her Complete on 6 October records both continuation bases, with the departure event ID (state: completed, historical).
7. Step 2.3 (Funding) is independent, but Okafor 2021 is out of the stage 2 pool, so no new Funding work is offered either. Only started work may continue.
8. PRISMA reports Okafor 2021 as excluded at full text (PR1). Chandra's extraction is preserved as evidence and is not counted as an inclusion.

9.3 A restricted continuation (Okafor 2021, variant)

Dev restricts continuation after departure for stage 2. The preview says "1 reviewer has started work that would no longer be completable; their drafts are kept". Dev confirms. Chandra's form turns read-only with "An admin has restricted finishing work on Studies that left this stage. Your draft is kept." (state: unavailable). Her draft stays recoverable. If Dev later lifts the restriction, she can complete it and the version records the setting version that allowed it.

9.4 Leaving and re-entering through accepted answers (Lindqvist 2018)

1. Lindqvist 2018 is in stage 3 because its accepted species is rat.
2. Ellen reconciles a correction. The accepted species becomes zebrafish and the model is not MCAO. Before publishing, she sees "This Study will leave Rodent synthesis; 1 reviewer has started work there". She publishes. In the same transaction SyRF records StagePoolDeparted with reason ACCEPTED_ANSWER_NOT_MATCHING, closing episode 1.
3. A query later shows the species was rat after all. Ellen publishes a new accepted result. SyRF records StagePoolEntered, episode 2, with cause AcceptedAnswerChanged.
4. Femi's query "Studies that entered Rodent synthesis in October" returns Lindqvist 2018 once, with episodes 1 and 2 listed beneath it.

9.5 A filter edit finds newly matching Studies (stage 3)

1. Stage 3 is automatic and Completed. Dev edits the filter from Species anyOf {rat} to Species anyOf {rat, mouse}.
2. The preview shows 14 Studies entering and none departing. Nine of the 14 have remaining Risk of bias work. Stage 3 is automatic, so the preview says it will reopen when Dev confirms (Q-02). Dev's confirmation of this preview is the approval of the specific protected change; no second confirmation is asked before the stage reopens.
3. mouse uses the Species question already read by the current filter, so no preparation is needed. Dev confirms. The fence, drain and digest check pass, and filter version 2 activates at 10:02.
4. Selection uses version 2 at once. The sweep records 14 StagePoolEntered events with effectiveAt 10:02 and recordedAt between 10:02 and 10:04. An as-of view for 10:03 is refused until the sweep has applied (state: pending), then becomes available.
5. Stage 3 reopens through the two-step lifecycle. Bob sees the new work in My work.

9.6 Evidence that is already sufficient (Tanaka 2020)

Dev adds stage 4 "Risk of bias review" with the filter FT in {Included}, binding the Design form and a new Risk of bias form. Tanaka 2020 enters stage 4. Alice and Bob completed the Design form through stage 2, which meets its target of 2, so no Design work is offered in stage 4. Risk of bias work is offered. If Risk of bias were also already sufficient, Tanaka 2020 would stay in the stage 4 pool with nothing to do. The explanation would read "Already sufficiently reviewed (evidence collected through Full text)". Femi's "reviewed through stage 4" query would list it as satisfied elsewhere, never as reviewed in stage 4 (state: empty, meaning no work).

9.7 Terminal exclusion in a one-stage design (Reyes 2017)

Another project uses one stage "Screening and extraction": its filter is the base predicate, 1.1 is TA screening, 1.2 is the Design form depending on 1.1 and 1.3 is an independent Funding form. Exclusion-stop on 1.1 has collective on and scope DependentSteps. Reyes 2017 is collectively Excluded under TA. It stays in the pool, but step 1.2 is never offered to anyone, and step 1.1's extra screening is not offered either. Step 1.3 is still offered because it is outside the scope. The explanation for 1.2 reads "Progression stopped by exclusion: TA team result Excluded (profile version 2)".

9.8 Places, timeout and the dependent claim

This example follows §9.1 and §9.6: Smith 2019 is Included at full text, and stage 4 exists. By now the project is an admitted tracked pilot (D3-16), so places and caps are enforced. Chandra's start in §9.2 came earlier and recorded "not enforced".

1. The Design form is bound in stage 2 (step 2.1) and stage 4. Garcia 2019 is Included at full text by others, so only its Design work remains. Alice has a Design draft for Garcia 2019 open through stage 2 in one tab and through stage 4 in another. She holds one place.
2. Alice closes the stage 2 tab and keeps typing in the stage 4 tab. Her place stays, because the other connection is active.
3. Dev enables the Outcomes form's cap at EffectiveTarget (1). Places already held stay; the cap evicts nobody.
4. On Novak 2022, Alice has a saved-incomplete Outcomes session, which holds the only place. Bob records his own FT Include on Novak 2022 at step 2.1. His Include tries the Outcomes claim in the same transaction and is refused. Step 2.2 shows "Enough reviewers are already working on this", and his FT decision stands.
5. Alice leaves her Garcia 2019 draft for an hour, beyond the Design form's timeout. Her place is released and her draft kept (state: Draft auto-saved). When she returns, her Complete re-checks capacity. The Design form has no cap, so it succeeds as an extra contribution if the target is already met (D2-07). With a cap and no free place, she would be told and could keep or discard the draft.

9.9 Browsing (Bob)

Dev enables browsing for stage 2. Bob opens Browse and sees his reviewer pool: Smith 2019 ("Draft auto-saved"), Novak 2022 ("Version checkpoint saved" for 2.1; "Enough reviewers" for 2.2) and Patel 2016 ("Not started"; 2.1 available). He sees the accepted TA result "Included" because reconciled screening results are visible in this project. He never sees Alice's or Chandra's decisions, names or times. While he browses, Okafor 2021 leaves the pool. When he clicks its stale row, SyRF says "No longer available in this stage" (state: unavailable). It does not explain why, because the FT result is not visible to candidates in this project.

9.10 The admin explanation (Okafor 2021 and Ibrahim 2015)

Dev asks why Chandra completed Okafor 2021 on 6 October when it is not in stage 2. The timeline reads:

1. "1 Oct 09:14: entered Full text. TA team result Included (outcome version 5, decisions by 2 reviewers); FT not Excluded. Filter version 3."
2. "2 Oct 11:40: Chandra started Outcomes through Full text, step 2.2. Allowed because the Study was in the pool, her own FT Include (revision 1) satisfied the dependency, and capacity was not enforced (tracking off)."
3. "4 Oct 16:05: left Full text. FT team result became Excluded (Bob's decision). Clause FT notIn {Excluded} failed."
4. "6 Oct 10:22: Chandra completed Outcomes. Allowed as work started before the Study left the pool (continuation setting version 1: Allow)."

For Ibrahim 2015, in another project converted on 20 September, the timeline reads "Pool history before 20 September 2026 is not recorded (converted from legacy). 20 Sep: in Full text at conversion (baseline). In pool since; no review is recorded." It suggests no reason for the absence of review.

9.11 Merging duplicates (Ahmed 2020a and Ahmed 2020b)

Both duplicates were in stage 2. Dev merges them (DM spec). SyRF records StagePoolDeparted for each original with reason STUDY_NOT_CURRENT_MERGED and the StudyMerge reference. The consolidated Study is evaluated, matches and gets StagePoolEntered with cause StudyMerged and lineage to both originals. Stage 2's status does not change because of the merge itself. Femi's "entered stage 2" count is 3 in RecordedIdentity mode and 1 in ConsolidatedLineage mode. Which one a PRISMA box uses is T-SI-05's decision.

9.12 Reporting (Femi)

Femi runs three queries for stage 2 for October. "Entered": 412 distinct Studies (Lindqvist-style re-entries counted once). "Exited": 37 distinct Studies, broken down by reason (31 SCREENING_OUTCOME_EXCLUDED, 4 STUDY_NOT_CURRENT_MERGED, 2 FILTER_RECONFIGURED). "Reviewed through Full text": 298 distinct Studies, each with its start eligibility. The PRISMA mapping of these datasets awaits T-SI-05. The report snapshot she freezes keeps its numbers whatever happens later.

9.13 A failure (sweep stalls)

A filter sweep on a 100,000-Study project stalls when a bulk-update lock holds 2,000 Studies past the operation's limit. Dev sees "Pool history is catching up (stalled; 2,000 Studies deferred)". Reviewers are unaffected because selection uses the new filter. As-of views after the activation are refused until the operation completes on retry (state: failure, then recovered).

10. Rollout and adoption

10.1 Baseline and MVP placement

Capability	Release	Depends on	Flag decision (PROPOSAL)
HistoryEvent envelope, idempotency, ordering and effective/recorded time	Contract at F1a (with C18 and C19); stage-pool and eligibility event types at F3	C18 HLC stamps; C19	No flag: a contract
Shared place across tabs and routes; form-owned timeout and in-progress limit; capacity cap separate from target	R2b (claims v2, form-keyed); production enforcement through X-CLAIMS	Claim contract v2 at F1a; D3-16 route	Rides R2b's per-project enrolment; enforcement needs tracking on
Stage study filter with profile-outcome clauses and AND/OR groups; filter versions	R3a	F3; R2a; X-ELIG for production	Rides R3a's per-project enrolment; legacy stages unchanged
Steps, dependencies, own-Include default, exclusion-stop, Stop/Allow extra screening, saved work after exclusion	R3a	F3 (C6 rewrite)	As above
Continuation after pool departure (default Allow) and its restriction setting	R3a (default behaviour); restriction UI once SP-AMB-01 is answered	SP-AMB-01	As above
Pool history (entries, departures, baseline), tracking marker, targeted reevaluation, filter-change sweep	R3a	F3; consistency-model amendments	History writes are not flagged inside canonical scopes: switching them off would create unexplainable gaps
ReviewStartEligibility and completion basis	R3a (optionally from R2a for pilot coverage; the rollout drafter decides)	C5 version records (RD spec)	Not flagged, as above
WorkFirstReleased	R3a (unbatched), R3c with X-BATCH (batched)	X-BATCH	As above
Required event queries and the basic admin explanation	R3a (API); the timeline screen behind a UI flag until staging acceptance	X-AUTH-RESOLVER for per-reviewer rows	UI flag stageEligibilityTimeline
D3-19 dependent claim at Include; D3-20 disclosure	R3a	Claims v2	With claims
Collective-Include stage setting (Q-01)	R3c, after pilot validation (SP-AMB-11)	R3a	Behind R3c's designer flag
Automatic and static completion, reopening (Q-02, LC1)	R3c	R3a; readiness seam	Existing R3c gating
Reconciled-answer filter clauses	With or after R4a (accepted results must exist); the delivery timing is a separate rollout decision (owner)	R4a, filterInputs[]	Release flag stageFilterAcceptedAnswerClauses
Reviewer pool browsing	After R3a as a small opt-in slice (candidate R3c; the rollout drafter places it)	R3a	Release flag reviewerPoolBrowsing plus the per-stage setting, off by default
As-of pool membership and reporting use	R5a (as-of), R5b (PRISMA, after T-SI-05)	C11 watermark; T-SI-05	Existing R5 gating
Allocation restricting the reviewer pool	AL1	Allocation Phase 2; X-AUTH-RESOLVER	Existing AL1 gating

10.2 Optional and opt-in

Reviewer pool browsing is opt-in per stage. The collective-Include setting is optional per stage. Both default off. Neither is a beta of the engine; both are ordinary settings once shipped.

10.3 Deferred

• Accepted-answer branching between steps (D4-15): a later lane after R4a, with no delivery commitment until its brief is approved.
• Entity-scoped accepted-answer clauses (SP-AMB-06).
• Retained claim and refusal history for reconstructing past per-reviewer availability (§3.14).
• A stored current-membership cache, unless the F3 benchmark needs it.

10.4 Adoption and legacy stages

• New canonical stages start full coverage at activation (§3.5.5).
• Existing canonical stages created before pool history ships get baseline events when it ships.
• Legacy stages map through the opt-in wizard (Q-24), and later the universal baseline conversion waves (R4 direction, BC spec). The wizard inspects actual stage behaviour: mode, implicit or explicit filter, Allow or Stop for extra votes (a missing value maps as Allow per eligibility D1, to be verified), excluded-work policy (D5), the hide-excluded setting, MaxInProgress, the target, enforcement and idle timeout. It shows the step mapping and the behaviour changes, and an authorised admin confirms. A-16 (combined stages map to steps without a dependency edge) is a candidate mapping to verify per project, never an assumed rule.
• Where a mapping converges several legacy stages on one shared form with different timeouts or limits, the wizard shows the conflict and asks for an explicit choice (PROPOSAL).
• Conversion writes baseline events with coverage BaselineAtTrackingStart, and earlier history is labelled NotRecordedInLegacy.

10.5 Pilots and dependencies

Production pilots need X-ELIG (R3a) and, for capacity promises, X-CLAIMS through the D3-16 route. Pilots run on admitted projects only (D1-07). Capacity is piloted on shared forms before broader opt-in (D3-16 treatment). The tester panel is unchanged (D3-08). Staging seeds add a "stage pools" seed project with the §9 cast and studies (D3-14 allows additive seeds).

11. Acceptance evidence

ID	Evidence	Method	Amends
SP-AE01	The filter evaluator gives the expected result for every row of a truth table covering nested AND/OR groups, three-valued logic, profile-outcome clauses (including unresolved sub-states) and accepted-answer clauses; the compiled query and the in-memory evaluator agree on a shared corpus	Unit, integration	New
SP-AE02	Filter versions are immutable; a settings version that changes only steps keeps its filterVersionId; a Completed stage refuses a filter change outside a change request	Integration	New
SP-AE03	A clause reading an activity bound in the same stage shows the feedback notice in the designer	E2E, user test	New
SP-AE04	The filter schema has no reviewer-dependent, pool-membership, remaining-work, capacity or allocation clause kinds (schema test)	Inspection, unit	New
SP-AE05	A decision under profile P evaluates only filters whose dependency set contains P (instrumented evaluation count) and evaluates the whole filter	Integration	New
SP-AE06	Autosave, draft saves and page queries write no pool events and evaluate no filter	Integration	New
SP-AE07	Self-departure: the valid submission commits; the outcome changes; one StagePoolDeparted names the command, the decision revision, SCREENING_OUTCOME_EXCLUDED and the clause tree; the evidence is intact; no new offers follow; started work appears as saved work	Integration, E2E	AC-R3a-05
SP-AE08	Re-entry opens episode 2; the "entered" query returns the Study once with both episodes	Integration	New
SP-AE09	A filter edit's preview counts equal the events the sweep records; a Study matching only the new version is entered	Integration	New
SP-AE10	At least 1,000 randomised interleavings of a filter activation and an evidence change on one Study yield the filter transition before the evidence transition in seq, with no duplicates	Integration	New
SP-AE11	Retries, re-executions and operation takeovers create no duplicate events	Integration	New
SP-AE12	An architecture test proves that admission, selection, counts and readiness never read pmHistoryEvent or the tracking marker; after activation, selection uses the new filter while the sweep is still running	Inspection, integration	New
SP-AE13	Sweep events carry the activation stamp as effectiveAt and the item stamp as recordedAt; an as-of request is refused while a sweep with an earlier activation is running	Integration	New
SP-AE14	Every StagePoolEntered has a filter version, a clause tree marking satisfied nodes, input versions, a cause and, where applicable, an actor (schema validation over fixtures)	Unit	AC-R3a-19
SP-AE15	Tracking start writes one StagePoolBaselineMember per current member with coverage BaselineAtTrackingStart and no earlier time	Integration	New
SP-AE16	Departure reasons are classified correctly for screening Exclude, other outcome change, accepted-answer change, Unknown, reconfiguration, withdrawal, merge, unmerge and lifecycle fixtures	Unit, integration	New
SP-AE17	The entered, exited, ever-in-pool, as-of, episode, reason and reviewed-through-stage queries match fixture expectations, including re-entries and merges; p95 under the proposed budget (not approved) at 100,000 Studies on Bramble	Integration, benchmark	New
SP-AE18	The RecordedIdentity and ConsolidatedLineage modes give the fixture counts on a merge and unmerge fixture	Integration	New (default pending T-SI-05)
SP-AE19	ReviewStartEligibility is written once per session and route at first start with every field group; with tracking off, the capacity basis reads NotEnforced (tracking off)	Integration	New
SP-AE20	A completion after departure records ContinuationAfterDeparture with the departure event ID and setting version; after an exclusion it records ContinuationAfterExclusion	Integration	New
SP-AE21	Continuation after a filter-driven departure is allowed by default; with the restriction on, Save and Complete are refused with ContinuationRestricted and the draft is kept; no new review starts outside the pool; the Study is in neither current pool	Integration, E2E	New
SP-AE22	Saved work after a screening exclusion completes by default; PreserveOnly refuses completion and keeps the draft; neither admits new work nor invents votes	Integration, E2E	AC-R3a-35
SP-AE23	The step truth table holds: own-Include progression while the result is pending; the collective-Include setting waits; collective satisfaction admits unvoted reviewers with no vote; personal Exclude stops that reviewer; collective Exclude is terminal in scope; independent steps are unaffected; results are identical for selection, reservation, direct access and submit	Unit, integration	AC-R3a-02, AC-R3a-22
SP-AE24	New combined steps default to Stop extra screening; Allow offers extra screening; a mapped legacy value is preserved	Integration	AC-R3a-07
SP-AE25	Binding a sufficient form into a new stage offers no work and writes no stage-local record; the explanation reads NoRemainingWork; "reviewed through the stage" lists it as satisfied elsewhere	Integration	New
SP-AE26	A collectively Excluded Study with a terminal rule is never offered in scope, including extra screening at the governing step, while it stays in the pool; an independent step is still offered	Integration, E2E	AC-R3a-22
SP-AE27	The reviewer pool equals the stage pool restricted by allocation or assignment and current availability; a departing Study leaves it at once; continuation work appears only in Saved work	Integration	New
SP-AE28	Browsing is off by default; when on, it lists exactly the reviewer pool; payload inspection finds no other reviewers' candidate decisions, answers, tallies, identities or times; starting re-checks admission; a stale row opens with a typed reason	Integration, E2E	New
SP-AE29	Next serves randomly by default; explicit assignment is audited	Integration	AC-R3a-41
SP-AE30	WorkFirstReleased is written once per Study and stage with the right releaseKind, separately from StagePoolEntered; shared openings and personal grants are distinguished; an entry with no remaining work writes no release	Integration	AC-R3a-10, AC-R3c-17
SP-AE31	The capacity cap is separate from the target; off by default (proposed); an enabled cap follows the effective target; enabling or lowering it never evicts; an additional-review request raises the effective target and its reviewer is admitted	Integration	AC-R2b-16, AC-R4a-38
SP-AE32	Two tabs through two stages hold one place; an idle tab does not release it while the other is active; timeout releases it and keeps the draft	Integration, E2E	AC-R2b-03
SP-AE33	The form's in-progress limit counts a shared session once across routes, with no stage override; every former per-stage setting behaves as the new placement table says when stages bound to one form differ	Integration	AC-R2b-10, AC-R3a-37
SP-AE34	An own Include tries the dependent claim atomically; a refusal shows "Enough reviewers" and the decision stands; no dependent place is held while screening is underway	Integration	AC-R3a-25
SP-AE35	Presence carries counts and the recipient's own place; names go only to Monitor holders; nothing crosses reconciliation blinding	Integration	AC-T-08
SP-AE36	A settings change that conflicts with temporary reservations shows the exact impact; Apply anyway releases only those reservations, atomically with the setting; drafts and completed work are kept	Integration	New
SP-AE37	An automatic Completed stage reopens through the two-step lifecycle as soon as remaining work arrives, with no confirmation hold, whether the cause is a confirmed admin change or evidence recorded elsewhere; a manual stage stays Completed until an explicit Reopen; an admin change preview lists additional work per stage; a merge changes no stage status directly	Integration, E2E	AC-R3c-03, AC-R3c-08
SP-AE38	For the §9 fixtures, the explanation gives the expected reason categories, uses historical versions, says "No review is recorded" where eligible and unreviewed, and labels coverage gaps; in a user test with three admins, nobody reads a fixture as a platform error	Integration, user test	New
SP-AE39	Stage history needs Monitor; reviewers see only their own starts and reasons; blinding holds in timelines	Integration	New
SP-AE40	Each legacy stage fixture maps to steps that reproduce its behaviour; no step setting is invented; an authorised admin confirms; converging stages with different timeouts need an explicit choice	Integration, rehearsal	AC-R3a-16, AC-R6-14
SP-AE41	The generated eligibility truth table gains filter, step, exclusion-stop and continuation columns and loses the DP6/DP7 cross-stage columns; a disabled or non-Active stage blocks only its own route	Unit	AC-R3a-03
SP-AE42	Selection p95 ≤ 400 ms at 100,000 Studies with a compiled filter (existing proposal); filter-sweep throughput and explanation latency within proposed budgets (not approved)	Benchmark	AC-R3a-26
SP-AE43	If an episode projection is built, it rebuilds from events with identical results	Integration	New
SP-AE44	Every filter-input writer records transitions, one test each: decision submit, correction, adjudication, gold publication, target-one automatic acceptance, import, merge, unmerge, withdrawal, lifecycle, contribution exclusion, profile publication phase 2 and external screening acceptance	Integration	New
SP-AE45	"Reviewed through the stage" counts a Study once across routes and re-entries and never counts evidence collected elsewhere	Integration	New
SP-AE46	The stage settings schema holds review, adjudication and training step kinds; an adjudication step accepts no designer dependency edge or exclusion-stop setting and offers exactly its profile's open adjudication tasks to eligible adjudicators (shared fixture with RS-AE33)	Unit, integration	New
SP-AE47	A merge activation writes WorkFirstReleased with releaseKind = InheritedThroughMerge for each stage where an input was already released, linking the earliest input release	Integration	New

AC-R3a-14 and AC-R3a-21 retire (cross-stage options replaced by Q-15). AC-R3c-07 is rewritten for the decided Q-01 stage setting. AC-R3a-15 and AC-R3a-23 move to the RS spec's form- and profile-owned blinding. AC-R3a-40 is rewritten for form-owned settings and the continuation rules.

12. Brief items, specialist inputs and unapproved proposals

12.1 The seven brief entries this specification owns

ID	Required treatment (consolidation §7)	This page's proposal for the brief
D3-09	Align the paused eligibility programme with the step and filter model; preserved work and early reconciliation stay distinct	R3a absorbs S6b (browser consumption) and, if the programme stays paused at F3, S4-B, S4-C and S6a as far as canonical stages need them. D8 maps as follows: a disabled or non-Active stage blocks its own route only (a shared session stays reachable through another active stage); hidden excluded saved work is a display sub-setting kept separate from the saved-work and continuation settings; authorised early reconciliation with a warning stays in R4a; deletion becomes versioned withdrawal; claim release carries over. The truth table gains filter, step, exclusion-stop and continuation columns (SP-AE41)
D3-13	Allocation and batch contracts, denominators and performance gates; first release, pool entry, review start and completion as distinct events	§3.7. Allocation refused on canonical stages until AL1; additional reviews raise the effective target (the original D3-13c bypass is superseded); pool-level "Who is offered what" until X-AUTH-RESOLVER; WorkFirstReleased with release kinds; batch membership over pool episodes; #3939 sliced with the performance gate (Next p95 at 100,000 Studies and 2,500 batches, proposed). The denominator for non-exclusion departures is SP-AMB-09
D3-16	Pilot shared-form capacity before broader opt-in; validate load and statistics integration	Enable tracking per admitted pilot project, never fleet-wide; API and PM switched together; orphan backstop; load and failover on Bramble (AC-T-03 to AC-T-07); FEAT-024 mode coordination. PROPOSAL: for canonical projects the tracking scope is the project's admission record. The binding-scope shape and "tracked if any bound stage is" are obsolete now that capacity is form-owned (SP-AMB-12)
D3-17	Capacity versus target, explicit defaults, audited reservation effects	§3.11. Cap defaults (off; enabled = effective target) are proposed, not approved. No eviction; caps never below the effective target; Apply anyway for temporary reservations
D3-18	Form-owned timeout, limit and shared connection rules; remove obsolete stage-derived rules	§3.11. Remove "most restrictive bound stage sets the cap and the idle timeout; the stage in use sets the in-progress limit; the form is tracked if any bound stage is". Default values for timeout and limit are proposed, not approved
D3-19	Annotation reservation at personal Include, preserving screening if capacity is unavailable	§3.11, §4.6. Under CollectiveIncludeRequired, the claim is tried at the next open after the collective Include (PROPOSAL)
D3-20	Active counts and own place for reviewers; Monitor names without defeating blinding	§6. SP-AMB-07 settles the overlap of Monitor and reconciliation blinding

12.2 Specialist inputs

• T-SI-05, PRISMA box mapping. Which boxes use "actual review through the stage" with its eligibility provenance, which use pool-history datasets, how distinct identity is counted across merge lineage (SP-AMB-08), and how coverage limits are disclosed. The owner has made actual review through the stage the reporting priority and kept pool history for audit. Owner: RI spec with methodologists.

12.3 Proposed numbers (not approved)

Number	Proposal	Where
Capacity cap default	Off; when enabled, equal to the effective target	§3.11
Inactivity timeout default	Today's idle-timeout default (value to read from code)	§3.11
In-progress limit default	Unlimited	§3.11
Filter group depth	4 levels	§3.3
Selection latency	p95 ≤ 400 ms at 100,000 Studies (existing proposal, AC-R3a-26)	SP-AE42
Pool-history query latency	p95 ≤ 1 s at 100,000 Studies and 4 stages	SP-AE17
Filter-sweep throughput	100,000 Studies in 15 minutes on Bramble	SP-AE42
As-of watermark lag	5 minutes (existing C11 proposal) plus "no running sweep"	§3.13
Batch performance gate	Next p95 at 100,000 Studies and 2,500 batches (existing proposal)	§12.1

12.4 Ambiguities, with options and a recommendation

ID	Question	Options	Recommendation
SP-AMB-01	Where does the "started work after leaving the pool" restriction live? The owner said the placement is unspecified	(a) One stage setting. (b) A step setting beside the saved-work setting. © A stage default with a step-level restrict-only override, matching EW1's pattern	©. Present both continuation settings together as "Finishing work already started". Needs owner or brief confirmation
SP-AMB-02	Do accepted-answer clauses count SingleAnnotator results as "reconciled answers"?	(a) Any authority. (b) Human-reconciled, adjudicated and merge-resolved only. © (a) by default with an optional per-clause restriction	©
SP-AMB-03	Who owns timeout, limit and capacity for screening-only work?	(a) The profile, mirroring the form. (b) The stage. © Project-wide	(a). In a combined step each activity follows its own owner
SP-AMB-04	Retired as a separate ambiguity (5 October harmonisation). Own-Unsure progression is now one PROPOSAL stated identically in §3.4 and RS-R47	The options are listed once, in RS §12 ("Own Unsure and progression")	See RS §12 (the single confirm item)
SP-AMB-05	Closed (5 October harmonisation): decided by Q-02 and consolidation §3	An automatic Completed stage is recalculated as soon as remaining work appears, with an impact preview before admin-initiated changes; a manually or statically completed stage stays Completed until an explicit authorised reopening; LC1 change requests remain for protected changes acting on the Completed stage itself	No owner question remains. §3.10, SP-R76, SP-R77 and SP-R80 apply; the AC-R3c-03 amendment is listed in §13
SP-AMB-06	Should accepted-answer clauses address entity-scoped answers (for example "any cohort is rat")?	(a) MVP. (b) Later, with explicit any or all quantifiers	(b)
SP-AMB-07	Can a Monitor holder who is also the blinded reconciler see candidate names for that Study?	(a) Yes, Monitor wins. (b) No, blinding wins for a task the viewer holds or is assigned	(b). RS-R28, ACD-R36 and UX-R37 already state that names never cross reconciliation blinding; confirm in the brief
SP-AMB-08	Default identity mode for distinct counts across merges	(a) RecordedIdentity. (b) ConsolidatedLineage. © Support both; PRISMA default set by T-SI-05	©
SP-AMB-09	How do batch denominators treat departures other than sufficient exclusion?	(a) Count as finished. (b) Remove from the denominator. © Show as "no longer in pool", excluded from remaining work, kept in the membership record	©; settle with the batch owner in the D3-13 brief
SP-AMB-10	When is work first released in a stage without batches?	(a) At the first pool entry while the stage is Active. (b) At the first moment there is also remaining work for anyone	(b), so that already-sufficient Studies are never reported as released
SP-AMB-11	Does the collective-Include stage setting ship in R3a or R3c?	(a) R3a. (b) R3c after pilot validation	(b), per Q-01's original recommendation; the setting itself is decided
SP-AMB-12	Tracking scope for canonical projects (D3-16 alignment)	(a) Binding-scope setting (#3876 reshaped). (b) Project scope through the admission record	(b), because capacity is now form-owned
SP-AMB-13	How granular must reviewer availability history be? The owner asked to retain assignment and availability history and reasons, and also to avoid logging every page query	(a) Derive it from recorded causes (pool events, assignments, regimes, batches, settings, permission audit); capacity at a past moment stays a stated gap. (b) As (a), plus an event whenever a Study becomes unavailable to a reviewer who holds an explicit assignment or started work. © An event for every reviewer-pool change	(a) for MVP, with (b) as the first extension if pilots show admins need it. © would log near page-query volume

12.5 Policies not approved

This page relies on no unapproved policy. History events are retained while the project exists. A permanent physical erasure policy (T-POL-01) and an identity-erasure process (T-POL-02) are not approved and would need their own design for history. Automatic acceptance of multiple agreeing candidates (T-POL-03) is not assumed; accepted-answer clauses read whatever accepted result exists.

12.6 Harmonisation notes (5 October 2026)

• §3.10, §4.11, SP-R76, SP-R77, SP-R80, SP-AE37: stage completion and reopening treated as decided by Q-02 and consolidation §3 (automatic stages recalculated when remaining work appears; manual or static completion kept until explicit reopening). SP-AMB-05 is closed, LC1's hold for automatic stages is superseded, and the AC-R3c-03 amendment is listed in §13.
• §3.4, §3.11, SP-R72 and SP-AMB-04: own-Unsure progression (and the D3-19 dependent claim it triggers) is one PROPOSAL, identical to RS-R47; the confirm item moved to RS §12.
• §3.4 (new "Step kinds" table), §5.12 (new SP-R91, SP-R92), SP-AE46, §3.10: the system adjudication step and the training step now fit the step model, matching RS-R57, RS-R59 and TI §3.1. Adjudication tasks stay reachable when the adjudicated outcome moved the Study out of the pool, and open adjudication keeps automatic completion open. §2 gained a row for the tie adjudication amendment's step mapping.
• §3.3: profile-outcome sub-states now use RS's resolutionState names; "current outcome" now reads the adjudicated or merge-resolved final facet (RS §3.8), including a flagged one (RS-R58).
• §3.7 and SP-AE47: added releaseKind = InheritedThroughMerge so DM §3.8's merge-time first release has a kind.
• §3.12: other specifications' event types are adapter types or C20 additions; the closed set is extended only through C20.
• §3.9: replaced the superseded "D2-07 middle ground" citation with D2-07 and Q-28.
• §4.3, §4.4: adjudication writers and contribution-exclusion effects aligned with RS-R58 and ACD §3.2; publication treatments include RS-R10's suspended results, which filters read as absent.
• §2: D3-17 and D3-18 labelled carry-forward alignment entries, as in the brief. §9: the example profiles state their tie policy (RS-R50) and the §9.2 state uses RS's names. SP-AMB-07 notes that RS-R28, ACD-R36 and UX-R37 agree.
• §13: added the AC-R3c-03 amendment, the C6 step kinds and the LC1 ledger annotation. §14: added the superseded LC1 hold.
• §7: a lower in-progress limit now offers the optional Apply anyway for temporary reservations above the limit (Q-24), matching ACD §7 and RD §7; without it held work stays.

13. Amendments to existing package documents

• contracts.md → C6. Replace "incoming cross-stage route policy (Collective Include required by default, own Include sufficient as advanced …)" with the filter version reference and the stage progression basis (Q-01). Add the exclusion-stop basis and scope, the saved-work and departure continuation settings and the route capacity cap to the review step element. Add the step kinds of §3.4 (review, system adjudication, training) with SP-R91 and SP-R92. Replace the DP6/DP7 evaluation table (with A-06 and A-18) by §3.4's dependency satisfaction table and exclusion-stop rules. In "Shared-evidence policies", move BL1 to the form or profile (RS spec), make VS1 a form baseline with step hide-only narrowing, and evaluate EW1 and departure continuation as §3.9 says. The admission decision returns reasons from §3.14's closed set. Retire conformance rows for A-06 and A-18.
• contracts.md → C7. "Capacity and target" row: form-owned baseline through every route, stage stricter, one shared count, cap off by default (proposed), enabled default equal to the effective target (proposed); delete the D3-18 sentence about the most restrictive bound stage. "Requested review (RA5)" row: an additional-review request raises the effective target through StudyTargetOverride; delete "never changes the target" and "bypass". "Progressive batches" row: membership over stage pool episodes; release recorded as WorkFirstReleased. "Tracking mode" row: note the project-scope PROPOSAL (SP-AMB-12).
• contracts.md → C12. "Entering screening" uses WorkFirstReleased; stage pool history is a separate dataset; reporting prioritises actual review through the stage (T-SI-05).
• contracts.md → new C20 Structured history events. Envelope fields (§3.12), event families, closed reason and cause sets, idempotency keys, ordering, effective and recorded time, the history watermark rule, adapters over existing records, access and blinding, required queries (§3.13) and conformance tests SP-AE05 to SP-AE19 and SP-AE44. Freeze: envelope at F1a, stage-pool and eligibility types at F3.
• contracts.md → C19. Pool events are facts written in the commit transaction; the filter sweep is an operation record (class b).
• domain-model.md → §4.2. Replace the StudyPoolLedger row with HistoryEvent (pmHistoryEvent), holding WorkFirstReleased (renamed from StudyEnteredPool) and the StagePool* events.
• domain-model.md → §4.4. Stage row: remove the route policies (DP6/DP7, Q-15) and BL1; add the filter version, progression basis, exclusion-stop, continuation settings, route cap and browsing setting. Placement table: target enforcement → form capacity cap; MaxInProgress and idle timeout → form; blinding → form or profile; VS1 → form baseline with step hide-only narrowing; tracking → project scope (PROPOSAL).
• domain-model.md → §6.2 and §6.3. StudyEnteredPool becomes WorkFirstReleased plus the StagePool* events; SubmitScreeningDecision, AdjudicateProfileDecision, PublishGold, merge, unmerge and import write pool events and the marker; PublishStageSettings writes the sweep operation; add the SweepStagePoolHistory operation; add ContinuationRestricted and TerminatedByExclusion to the typed refusal catalogue.
• domain-model.md → §7.1. Add pure policies StageFilterEvaluator, StepProgressionPolicy, ContinuationPolicy and PoolTransitionPolicy, each with fixtures.
• domain-model.md → §8. Add "stage pool", "reviewer study pool", "saved work outside the pool" and "work first released"; replace "pool availability (StudyEnteredPool)".
• domain-model.md → §10 and §12. Collection list: pmStudyPoolLedger → pmHistoryEvent. R3a row: HistoryEvent instead of StudyPoolLedger; Study gains filterInputs[] and stagePoolTracking[].
• consistency-model.md → §3.3. Add filterInputs[] and stagePoolTracking[] to the canonical summary.
• consistency-model.md → §4.2 and §4.3. Decision submit, adjudication, gold publication, import, merge, unmerge and withdrawal rows write pool events and the marker; stage settings publication writes the sweep operation; batch opening writes WorkFirstReleased.
• consistency-model.md → §7.6. Add the preparation step and the sweep.
• consistency-model.md → §11.2 and §11.4. Add the history watermark rule; HistoryEvent is a versioned dataset.
• consistency-model.md → §12 and §13.2. Rewrite the pool-entry capture paragraph for WorkFirstReleased and StagePool*; the integrity checker compares markers with events.
• programme-integration.md → §3.2. Update the RA5 scoped admission paragraph: additional reviews raise the effective target.
• programme-integration.md → §4.2. X-BATCH criterion 2 uses stage pool episodes; PRISMA pool entry becomes WorkFirstReleased.
• programme-integration.md → §5.2. D8 mapping row (4) points to the saved-work and continuation settings; the truth table adds filter, step, exclusion-stop and continuation columns and drops the cross-stage columns.
• programme-integration.md → §6.2. Rewrite "Capacity versus target" and "Shared-form tracking settings" for form ownership (D3-17, D3-18); add the project-scope tracking PROPOSAL to D3-16.
• acceptance-criteria.md. Amend AC-R3a-02, 05, 07, 10, 16, 19, 22, 25, 26, 35, 37 and 41; AC-R3c-03, 08 and 17; AC-R2b-03, 10 and 16; AC-R4a-38; AC-T-08 and 09; AC-R6-14. Retire AC-R3a-14 and AC-R3a-21. Rewrite AC-R3c-07 and AC-R3a-40. Move AC-R3a-15 and 23 to the RS spec. Add SP-AE01 to SP-AE47 to the traceability file.
• acceptance-criteria.md → AC-R3c-03 (Q-02 amendment). Replace "New arrivals to a Completed stage go through the same gate; manual mode needs an explicit Reopen" with "New arrivals with remaining work recalculate an automatic Completed stage at once, with no confirmation hold; admin-initiated changes show the additional work and completion effect before commit and are rechecked at commit; a manually or statically completed stage stays Completed until an explicit authorised Reopen (Q-02; consolidation §3)". Sources: LC1 → Q-02; status confirmed.
• integrated-plan.md → §2 and §5.5. R3a row: "Collective Include across stages by default" becomes "stage study filter; steps; own-Include default progression; pool history". R3a MVP boundary: replace the DP6/DP7 policies with the filter and step model and StudyPoolLedger with HistoryEvent. R3c: strict mode is the decided Q-01 stage setting, and the lifecycle follows Q-02. Coverage rows: stages and steps.
• prisma-amendments.md → A. Rename StudyEnteredPool to WorkFirstReleased; add stage pool history datasets; record the reporting priority and T-SI-05.
• versioning-model.md → §2 and §5.3. The stage settings version embeds the filter version; capacity, timeout and limit move to the form's operational settings.
• decision-register.md → §1.3 and §1.4. Mark the DP6/DP7 cross-stage part as replaced by Q-15; EW1 refined by Q-28 and the departure continuation amendment; LC1's flow per Q-02; BL1 moved (RS spec); update the D3b supersession row and the access-policy row; OD1 settled by Q-15 and Q-01.
• open-questions-and-assumptions.md. Retire A-06 and A-18; restate A-16 as a candidate mapping verified by the wizard; mark Q-15, Q-24, Q-01, Q-02 and Q-28 answered; list D3-17 and D3-18 as carry-forward and D3-09, D3-13, D3-16, D3-19 and D3-20 as brief items under T-SP-00.
• Owner ledger. Header note: the DP6/DP7 cross-stage routing is superseded by the stage study filter model (Q-15 replaced, 4 October). Annotate EW1 (Q-28 and continuation), BL1 (form or profile ownership) and LC1 (its confirmation hold before an automatic Completed stage reopens is superseded by Q-02; protected changes to a Completed stage still need approval).
• Access-policy proposal. Status note: "Incoming dependencies / progression between stages" and its personal/collective table are superseded by Q-15's model.
• FEAT-008 stage filtering. Feature-doc input for its own PR: Filter Set becomes the filter version schema v3; the Selection Subset becomes the reviewer study pool; HideExcludedStudiesFromReviewers, MaxInProgress and SessionCountTarget as stage settings are superseded for canonical stages; the circular-reference check becomes the no-recursion rule; the annotation rule type's timing is the separate rollout decision.
• ux-strategy.md. Copy deck terms: "Saved work", "No longer in this stage", "Waiting for the team's screening result", "Enough reviewers are already working on this", "Stopped by exclusion", "Already sufficiently reviewed", "No review is recorded". The timeline and browse screens are specified in the UX spec.

14. Superseded wording

Old wording	New wording	Where it appears today
"Cross-stage default is Collective Include required, with an advanced own Include sufficient option" (DP7)	The next stage's study filter defines its pool. No cross-stage progression setting exists. Dependencies are between steps inside a stage	decision-register §1.4 (DP7); contracts C6; owner ledger DP6 and DP7; integrated-plan §2 and §5.5 (R3a); AC-R3a-05, 14 and 21
"Stage → Incoming dependencies → Progression between stages"	No incoming dependency into a stage	Access-policy proposal
Q-15 parts (a) and (b), A-06 and A-18	Replaced by Q-15's recorded model; neither alternative is approved	open-questions; C6 evaluation table; AC-R3a-21
"The most restrictive bound stage sets the cap and the idle timeout; the stage in use sets the in-progress limit; the form is tracked if any bound stage is" (original D3-18)	The form owns the timeout and in-progress limit; the form's capacity baseline applies through every route and a stage may be stricter; one shared count	C7; domain-model §4.4 placement table and §4.11; programme-integration §6.2; AC-R2b-10
"Optional capacity cap (stage or route policy)"	Form-owned baseline with stricter route caps	C7; domain-model §4.11; programme-integration §6.2; AC-R2b-16
"Task blinding uses the most restrictive bound stage"; "BL1 is stage-owned"	Form-owned (profile-owned for screening reconciliation)	C6; domain-model §4.4; decision-register §1.3; AC-R3a-15 and 23
StudyEnteredPool in StudyPoolLedger as the pool-entry event	WorkFirstReleased for first release; StagePoolEntered for stage pool membership; separate events	prisma-amendments A; domain-model §4.2, §6.2, §6.3, §8 and §10; consistency-model §4.2 and §12; programme-integration §4.2; AC-R3a-05 and 10; AC-R3c-17
"A requestedReview claim … never changes the target"; "RA5 requested reviewer bypasses allocation buckets and the enforced target, once" (D3-13c)	An additional-review request raises the effective Study and form target, may name people or groups and counts across routes	C7; domain-model §4.3; programme-integration §3.2; AC-R4a-38
Every-ever-in-pool membership used as the PRISMA reviewed count	Actual review through the stage is the reporting priority; pool history is separate audit data	prisma-amendments A; C12
"Strict within-stage collective mode is a proposal only" (Q-01 open)	Decided: a stage setting can require collective Include; off by default	decision-register DP7 row; AC-R3c-07; integrated-plan §5.5 (R3c)
"Exact flow is PROPOSAL (Q-02)"	Decided per Q-02	decision-register LC1 row; AC-R3c-08
"Obtain confirmation before admitting a change that would reopen a Completed stage", applied to automatic stages and new arrivals ("the same gate")	An automatic Completed stage is recalculated as soon as remaining work appears; admin-initiated changes show their impact first; protected changes to the Completed stage still need approval; manual completion stays until explicit reopening (Q-02)	Owner ledger LC1; AC-R3c-03
"Circular references … are detected at save time"	Filters read preserved evidence only, so recursion cannot arise	FEAT-008
The interim recommendation to omit continuous membership history	Targeted transition history with query-time current pools	Session register only; no package text found

15. Existing work reused

No earlier work is reused in this specification. The QM v2 stack modelled per-stage question sets, stage-keyed publication and a leased stage-transition job that rewrote sessions (PR-A #2572, PR-B #2573, PR-C #2574), and its designer and #2387 selected questions per stage. Here a stage owns no evidence, target or session (§3.2), its filter alone defines its pool (SP-R01), and a filter change sweeps pool history without touching sessions (§4.1). Those pieces are therefore superseded. Only PR-B's "transition in progress" refusal survives, as a concept: the typed PublicationInProgress per form in the RD specification and the stage settings fence. The harvest map is authoritative.

Entries	Verdict	Target section
H-DOM-18	Avoid	§3.3 stage study filter (SP-R01)
H-SVC-11, H-API-08	Avoid	§4.1 filter sweep; the consistency model's operation family
H-SVC-13	Avoid	§4.1 (selection reads the new filter at once; reviewers keep saving)
H-WEB-09, H-TREE-03	Avoid	§3.2 (a stage binds forms; it selects no questions)
H-WEB-14	Avoid	§3.11 form-owned timeout and limits
H-SVC-12	Reference only	RD §3.8 publication operation; consistency model §7.6 settings fence

What this specification requires that the earlier work lacks. A stage binds form identities and owns no evidence, target or session. Its filter alone defines its pool. Filter changes sweep pool history with structured events and never rewrite sessions. Capacity, timeout and in-progress limits are form-owned. Operations are generation-fenced, with a stable cursor and a stalled state, which PR-B's job lacked.