Specification: Reconciliation, accepted results and screening resolution

Planning specification. This page turns the owner-session decisions of 4 and 5 October 2026 on reconciliation, accepted results, blinding, reconciled-answer hints and screening resolution into a buildable design. Owner decisions recorded here are planning approval only. Brief approval and implementation authorisation are separate per-gate decisions (D1-04) and remain on hold (owner, 5 October 2026). No work has started, no gate has passed and nothing is enabled in production. The owner-session consolidation §4 wins over older package text where they conflict; the register and the condensed packages keep the rationale. How the session was integrated is in the owner-session integration. Names follow the brief's naming registry and are PROPOSALs for the F1a naming ADR; storage is PROPOSAL for the F1a storage ADR. Tracker brief row: T-RS-00.

Companion specifications: review domain and versioning (RD: form versions, standard targets, overrides, publication), stage pools, steps and history (SP: filters, steps, progression, events), duplicate merge (DM), reporting, imports and AI screening (RI), training and inference (TI) and access, communications and deletion (AC).

1. Summary in plain English

When reviewers finish their work on a Study, SyRF needs one accepted set of answers for each annotation form and one collective decision for each screening profile. This page says how that happens, who may do it, what they see, and what SyRF records.

Annotation forms.

• Each published form version states how many reviewers a Study needs (the standard target) and what happens when that number is one. Two choices exist, and both use the ordinary reconciliation machinery.
• Accept automatically. The single completed session becomes the accepted result at once. The result is labelled Single annotator. It records the exact session version and the system rule that accepted it. SyRF never calls it reconciled, verified or checked.
• Require human reconciliation. A second person opens the normal reconciliation workspace, which shows one candidate. They confirm or correct the answers and complete it. This is how a project runs "one extracts, one checks". There is no separate verification engine or session type.
• With two or more candidates a human reconciler always produces the accepted result. Agreement between candidates never creates an accepted result by itself. An optional bulk acceptance screen lets a reconciler accept many agreeing Studies in one go, but only after an explicit confirmation, and each result names that reconciler.
• Accepted results are immutable versions. When the candidates, the target or the form policy change, SyRF keeps the old version and shows what changed. A new version comes only from the rule or person entitled to create it. Raising the target never invents reviewers.
• A blank candidate answer means "not assessed". It is not a disagreement and it does not stop reconciliation. "Unknown" and "Not reported" are real answers.
• Reconcilers see candidates as "Reviewer A", "Reviewer B" and so on by default. The labels and the order are drawn at random for each Study, so "Reviewer A" on one Study has nothing to do with "Reviewer A" on the next. Submission times and similar clues are hidden. Real names stay in protected history.
• Reviewers see existing accepted answers as labelled hints by default. A hint never fills the answer by itself. The reviewer clicks to copy it. SyRF records that the hint was shown and copied, so a copied answer never counts as independent evidence.
• A form can warn about outdated answers and still allow Complete (the default), or it can require them to be addressed first.

Screening profiles.

• Each profile version says how decisions combine: how many agreeing decisions are needed, whether reviewers may answer Unsure, what happens on a tie (ask one more reviewer up to a stated limit, or send it straight to an adjudicator), whether the reviewers in conflict may discuss it first, and whether an adjudicator must write a rationale.
• Unsure keeps a Study available. It is never an exclusion and never a definite Include vote.
• Adjudication work can be assigned to a named member or to a project group. The individual who resolves it is recorded. A Study awaiting adjudication has no definite outcome yet.
• Exclusion-reason templates may nominate a primary reason for a simple reporting breakdown. That is template guidance. A profile can still ask several reason questions and keep every answer.

2. Decisions covered

ID	Decision in one line	Status	Section
Q-29	A single qualifying candidate at an effective target of one can become an automatic Single annotator accepted result, configurable against required human reconciliation	Decided-amended (R1 final clarification)	§3.2, §5.1 RS-R01 to RS-R12
D4-03	Second-person checking uses the same reconciliation mechanism with one candidate and required human reconciliation; no Verified engine	Decided-amended (replaces the original Verified step)	§5.1 RS-R03
Target-versions-form amendment (result part)	A target or form-policy change may create a corresponding new result version; history kept; no reviewers invented	Decided-amended (RD owns form versioning)	§4.6, §5.2 RS-R09 to RS-R12
Q-36	No ordinary self-reconciliation by default; explicit override grants; new admissions use current authority	Decided (R2)	§5.4 RS-R17 to RS-R20
Q-11	Optional per-form bulk acceptance, off by default, explicit reconciler confirmation of exact inputs	Decided (R2)	§4.5, §5.5 RS-R21 to RS-R23
Q-32	A screening profile may require an adjudication rationale; off by default; adjudicated decisions only	Decided (R2)	§5.11 RS-R56
Tie adjudication amendment	A profile routes ties to extra review or to a separate adjudication step, with a bound; no imposed default	Decided (amendment outside the register count)	§5.11 RS-R50 to RS-R59
Adjudicator assignment amendment	Adjudication assigned to a member or an eligible group; the individual resolver recorded; assignment grants nothing	Decided (amendment outside the register count)	§3.9, §5.11 RS-R53, RS-R54
Q-04	Accepted-answer completeness follows requiredness with a form override and no stage override; blank is Not assessed; Unknown and Not reported are answers	Decided (R3)	§5.3 RS-R13 to RS-R16
Q-35	Mandatory "legacy authority unknown" reconciliation backfill	Removed (R3; premise checked in the dry run by BC)	§5.13 RS-R68
Q-30	Hints shown by default; blinding on by default; context-local aliases without cross-Study continuity; unstarted-assignment expiry optional	Decided	§5.6, §5.7, §5.14
Blinding and candidate-ordering amendment	Form owns annotation reconciliation blinding; profile owns screening reconciliation blinding; unpredictable order; hidden chronology; protected attribution	Decided (amendment outside the register count)	§3.5, §5.6 RS-R24 to RS-R30
Q-28 (hint part) and hints amendment	Form baseline shows reconciled hints; step may only hide; explicit click-to-fill; exposure and adoption recorded; never independent evidence	Decided-amended (the rest of Q-28 is in SP)	§3.6, §5.7 RS-R31 to RS-R38
D4-17 (O3)	Outdated-answer handling configurable: warn and allow Complete by default, or block until addressed	Decided-amended (O3)	§5.8 RS-R39 to RS-R42
D4-01 (S1)	Unsure per profile, on in the title/abstract template, not excluded for availability	Decided	§5.10 RS-R46 to RS-R49
S1 Unsure amendment	Bounded Unsure handling with the stated two-agree, three-then-adjudicate rows	Decided-amended (owner's refinement of S1)	§5.10 table
Unsure rows not stated by the owner	All-Unsure, in-flight responses, other thresholds and larger bounds	Brief item	§5.10, §12
D4-02 (S2)	Optional discussion after submitted decisions reveal a conflict; initial observations preserved; fallback when unresolved	Decided	§5.12 RS-R60 to RS-R64
Q-22 (S3, profile side)	Primary reason is template and reporting guidance; multiple reason questions supported	Decided-amended (S3 clarification; counting is in RI)	§5.13 RS-R65 to RS-R67
D4-13 (S3, profile side)	First failing criterion as the template's default primary reason; per-profile reviewer choice	Decided-amended (S3 clarification)	§5.13 RS-R66
D2-09	Shared-question accepted answers across two forms: the second form's reconciler may revise them as a new snapshot, with an optional reason and the query route	Decided-amended (Chris, 5 October 2026; owned by RD, T-OI-01); this page applies its hint display (RS-R32, RS-R33)	§3.3
D4-19	Blinding and serving in reviewer-pool browsing	Decided-amended (owned by SP); this page supplies reconciliation blinding	§5.6
Q-16, D4-12	Agreement formulas and observation basis	Brief item (owned by RI, T-SI-02); this page supplies exposure and initial-observation markers	§5.7, §5.12

3. Concepts, entities and storage

3.0 How the pieces fit

Evidence	Work item	Result	Authority values
Candidate form sessions for one Study × form	ReconciliationTask (one per Study × form)	AcceptedResultVersion, which publishes a new GoldSnapshot of the Study's accepted answers	AcceptedResultVersion.authority: SingleAnnotator, HumanReconciled, MergeResolved (DM); Adjudicated applies only to profile-owned screening annotations (§3.2)
Candidate screening decisions for one Study × profile	Profile rule evaluation; on an unresolved outcome, extra review or an AdjudicationTask	ScreeningOutcome current value and history; AdjudicationVersion when adjudicated	Outcome provenance, kept separate from accepted-result authority: finalSource ∈ ProfileRule, Adjudicated, MergeResolved (§3.8); machine and external human contribution through RI §3.13's composition fields
Accepted answers shown to a later reviewer	None	HintExposure, HintAdoption on that reviewer's session	n/a

3.1 ReconciliationTask (amended)

• What it is. The single piece of work that turns the candidate sessions for one Study and one form into an accepted result. It is reachable through every stage that uses the form.
• Identity. (projectId, studyId, formId) with a deterministic ID (unchanged from C9 and RE4).
• Versions and pointers. Append-only input sets (taskId, seq), each holding the form version reconciled against and the exact qualifying candidate session versions. A pointer to the current AcceptedResultVersion. The reconciliation session (author scope reconciled), the editor claim and assignments stay as in C9.
• Change. A task now exists for every form with at least one qualifying candidate, including target-one forms in both modes. This replaces "target-1 forms create no task" (C9, domain model §4.3). Under automatic acceptance the task is the identity that carries the input set and the automatic result, so a later surplus candidate reuses it.
• Mutability. The task document's state and pointers change by compare-and-set; input sets and results never change.
• Proposed storage (PROPOSAL). pmReconciliationTask as already planned; input sets embedded or in {taskId, seq} records (versioning model §12.1).
• What it is not. It is not a verification session type. It is not a screening adjudication; that is the AdjudicationTask (§3.9).

3.2 AcceptedResultVersion (new name over the existing gold model)

• What it is. One immutable accepted result for one Study × form, with its authority and full provenance. Each version produces a new GoldSnapshot of the Study's accepted answers (GS1).
• Identity. (projectId, studyId, formId, seq), plus (projectId, commandId) as the command receipt.
• Fields (PROPOSAL).
• authority ∈ SingleAnnotator (system rule), HumanReconciled, Adjudicated (profile-owned screening annotations resolved through an AdjudicationTask), MergeResolved (DM).
• acceptanceMethod ∈ SystemRule, Individual, BulkConfirmed, MergeResolution.
• origin ∈ Native, MergeCarriedForward, UnmergeCarriedForward, with the source result version for the two carried values (DM §3.5). A carried result keeps its original authority.
• inputSetRef, the exact candidate session version IDs and candidateCount.
• formVersionId (which pins standardTarget, ReconciliationPolicy and the completeness rule), studyTargetOverrideVersionId when one applies, and the effectiveTarget value used.
• goldSnapshotRef (the StudyGold sequence it produced).
• Actor: the system rule ID and rule version for SingleAnnotator; the reconciler's member ID for HumanReconciled; the publication operation ID and confirming admin when publication generated it; the override grant version when RS-R18 applied.
• Blinding mode in force and a protected reference to the presentation mapping (§3.5).
• supersedes (previous version) and a reason code (InputsChanged, TargetChanged, PolicyChanged, QueryResolution, Recheck, MergeResolution).
• Recorded time as the C18 clock stamp.
• Derived standing (never stored). Current, InputsChanged (a newer input set exists), BelowCurrentTarget (the effective target now exceeds the candidates behind it), SuspendedByTarget (the publishing admin chose to suspend results below a raised target; derived from the recorded publication treatment with no version written, in the C5 pattern), NeedsReReconciliation (class drift, versioning model §9.4), Superseded.
• Reconciled revisions. For SingleAnnotator, the system writes reconciled-scope revisions whose provenance says derivedFrom the exact candidate revision and actor = system rule. This keeps the StudyGold invariants and gives queries (QY2) a reconciled revision to target. PROPOSAL.
• Mutability. Append-only.
• Proposed storage (PROPOSAL). An append-only pmAcceptedResultVersion with {projectId, studyId, formId, seq} unique. The F1a storage ADR may embed versions in the task document instead if size allows; the requirements are immutability and lookup by Study × form.
• What it is not. It does not replace the per-Study GoldSnapshot, which still references exact reconciled revisions across forms (GS1). It is not a screening outcome.

3.3 StudyGold and GoldSnapshot (unchanged, with one note)

The per-Study accepted-answer store and its immutable snapshots stay as in C9 and domain model §4.3. Each AcceptedResultVersion publishes exactly one new snapshot. Shared-question accepted answers across overlapping forms follow D2-09, decided by Chris on 5 October 2026 (Decided-amended; RD §4.14, RD-R37; T-OI-01): the second form's reconciler sees the existing accepted answer as a labelled hint with click-to-fill, never prefilled (OS-A04; RS-R32, RS-R33), and may revise it in their own final submission, which publishes the new snapshot with provenance. An optional reason is prompted for when the answer differs and is never required. The reconciler may also raise a query on the accepted answer (R4b; QY1). Verified leaves the authority set (superseded with D4-03's original form).

3.4 Form reconciliation settings

• What they are. The form-owned choices that govern how its accepted results are produced and shown. Some live in the immutable form version; some are audited operational settings.
• ReconciliationPolicy on the form version (immutable; changes publish a new form version with impact preview).
• targetOneHandling ∈ AutoAccept, RequireHumanReconciliation (owner: R1 final). Baseline conversion alone may also set NoAcceptance (PROPOSAL, RS-R04a), which reproduces legacy single-reviewer behaviour.
• acceptedCompleteness ∈ FollowRequiredness (default) or RequireAllApplicable, plus a list of optional questions marked "required in accepted answers" (PROPOSAL for the override shape; owner: Q-04 for the existence of a form override).
• identityBlinding ∈ Blinded (default), NamesVisible (PROPOSAL classification; see §3.12).
• reconciledHints ∈ Shown (default), Hidden (owner: Q-28 hints amendment, Q-30; classification PROPOSAL, following RD's rule that a setting changing how evidence is produced belongs in the version).
• outdatedAnswerCompletion ∈ WarnAllowComplete (default), BlockUntilAddressed (owner: D4-17; classification PROPOSAL, following the same RD rule). The mode that applies is the one in the form version a Save or Complete declares, so the session version records it.
• Form operational settings (audited, unversioned, every change recorded with actor and time).
• bulkAcceptance ∈ Off (default), On (owner: Q-11).
• unstartedAssignmentExpiry: off by default; when an admin enables it they set the duration (owner: Q-30; no duration approved).
• Proposed storage (PROPOSAL). The version part in pmAnnotationFormVersion; operational settings on the pmAnnotationForm head with history in pmDefinitionSettingsAudit.
• What they are not. Stages and steps own none of these, except the step's hide-only hint override (§3.6).

3.5 Reconciliation presentation mapping

• What it is. The random, private table that says which candidate appears as which alias, in which position, for one reconciliation session (form task or adjudication).
• Identity. (workItemId, reconciliationSessionSeq).
• Content. For each candidate: an opaque context-local handle, an alias, a display position, and the protected link to the real session or decision version.
• Lifecycle. Created when a reconciliation session first opens. Fixed for the life of that session, including Save and resume. A candidate who arrives during the session receives a new random alias and is appended without reshuffling. A later session on the same work item (for example a re-check after inputs changed) draws a fresh mapping. Mappings for different Studies are drawn independently.
• Mutability. Append-only per session; never edited.
• Proposed storage (PROPOSAL). pmSessionPresentation (already planned for presentation state) with server-only read; the client receives only handles, aliases and positions.
• What it is not. It is not a persistent reviewer pseudonym. It never changes attribution or independence accounting.

3.6 HintExposure and HintAdoption

• What they are. The record that a reviewer was shown an existing accepted answer as a hint (HintExposure), and the record that they copied it into their own answer (HintAdoption).
• Identity. One exposure per (session version or draft etag, accepted revision shown). One adoption per (candidate revision written, accepted revision copied).
• Content. The accepted revision ID, its snapshot sequence, the question version of the source and of the reviewer's control, the compatibility mapping applied, the route (stage and step), the reviewer and the clock stamp. The candidate revision written by an adoption carries adoptedFrom.
• Mutability. Append-only.
• Proposed storage (PROPOSAL). New kinds in the existing pmExposureLedger: reconciledHintShown and reconciledHintAdopted, deduplicated as the ledger already is. No new collection.
• What they are not. Permission to see hints is not exposure. Exposure is recorded only when the hint control renders in view (the RE2 and AC-R4a-19 rule for actual controls).

3.7 Screening profile version settings

• What they are. The rules that turn screening decisions into a collective outcome. They belong to the immutable ScreeningProfileVersion and change through profile publication with impact preview (Q-26).
• Fields (owner decisions unless marked).
• Sufficiency rule: initial decisions required and agreeing definite decisions required (existing).
• unsureEnabled (D4-01).
• tiePolicy ∈ ExtraReview with extraReviewBound, or Adjudication (tie amendment).
• Handling per trigger: decision tie, unresolved Unsure, reason disagreement, sole-source Unsure from an AI screening model (adjudicator amendment; E3 via RI).
• discussionEnabled, with an optional admin-set time limit and no default duration (D4-02; time limit PROPOSAL).
• adjudicationRationaleRequired (Q-32; classification into the version is PROPOSAL).
• Reason handling: DP5 reason reconciliation, must-agree supporting answers (RX1), primary-reason derivation (S3, D4-13; classification PROPOSAL).
• identityBlinding ∈ Blinded (default), NamesVisible (blinding amendment; naming registry).
• Source policies for external and AI-model-generated screening decisions (E3; specified in RI).
• What they are not. The adjudicator assignment is not part of the profile version (§3.9), so changing who adjudicates never needs a profile publication.

3.8 ScreeningOutcome (amended)

• What it is. The current collective result for one Study × profile and its append-only history (domain model §4.2).
• Change. The current value gains a resolutionState ∈ Pending, AwaitingExtraReview (with the remaining bound), InDiscussion, PendingAdjudication, Included, Excluded. Only Included and Excluded are definite. A collective all-Unsure state is held back until its rule is decided (§5.10). finalSource ∈ ProfileRule, Adjudicated, MergeResolved records how the outcome was resolved. This is outcome provenance, kept separate from AcceptedResultVersion.authority (§3.2). Machine and external human contribution is carried by RI's outcome composition fields (machineContribution, externalHumanContribution, RI §3.13), not by extra finalSource values: an external or AI decision resolves through ProfileRule under its source policy, and a human resolution of it through Adjudicated. No legacy-unknown value exists (Q-35 removed; RS-R68). PROPOSAL for the names.
• What it is not. It is not an accepted annotation result. The profile's decision rule is the configured screening rule (S3) and is distinct from the unapproved automatic acceptance of agreeing annotation candidates (T-POL-03).

3.9 AdjudicationTask, AdjudicationVersion and AdjudicatorAssignmentVersion

• AdjudicationTask (what it is). One piece of adjudication work for one Study × profile × trigger. It is shared by every stage that binds the profile.
• Identity. (projectId, studyId, profileId, trigger, generation), deterministic; at most one open task per (Study, profile, trigger).
• Content. The exact input decision versions, the trigger, the assignee captured from the current assignment version, an editor claim (compare-and-set plus lease, the X-RECLAIM pattern), the state (Open, Claimed, Resolved, Withdrawn with a reason, Superseded) and the resolution.
• Proposed storage (PROPOSAL). The planned pmProfileAdjudication aggregate becomes the task aggregate and holds the adjudication versions.
• AdjudicationVersion. The immutable adjudicated decision: the decision, reasons and must-agree answers where applicable, the rationale when required, the input vector it applied to, the individual adjudicator and the clock stamp (domain model §4.2, versioning model §9.7).
• AdjudicatorAssignmentVersion. An immutable, audited record per profile (and optionally per trigger) naming a project member or an eligible project group, with actor and time. No assignment means any eligible adjudicator may claim the work. PROPOSAL for storage: the profile head's operational record with history in pmDefinitionSettingsAudit.
• What they are not. An assignment never grants adjudication permission. A group assignment never hides who resolved the task.

3.10 ScreeningDiscussion (new, PROPOSAL name)

• What it is. One discussion episode between the candidates whose submitted decisions conflict on one Study × profile.
• Identity. (projectId, studyId, profileId, conflictGeneration).
• Content. Participants (by protected identity, shown under aliases when blinded), the initial decision versions that revealed the conflict, exposure entries, state (Open, Resolved, EndedUnresolved) and the closing reason. Messages use the existing conversation infrastructure and are permissioned audit records (D3-25).
• What it is not. It is not a separate step. It is part of the screening step's resolution route.

3.11 Self-reconciliation override grant

• What it is. An explicit, audited capability grant that lets a named member or group reconcile or adjudicate work on a Study where they also contributed, for named forms or profiles (Q-36).
• Storage (PROPOSAL). A C10 capability, working name "Reconcile own contributions (override)", granted through the authorization programme's grant model and audited in authorizationAudit.
• What it is not. It is never implied by ownership, administration or Reconcile.

3.12 Where each setting lives

Setting	Owner	Versioned or audited	Default	Source
Standard reviewer target	Form version	Versioned (publication impact)	Per form	Target-versions-form amendment
Target-one handling	Form version ReconciliationPolicy	Versioned	AutoAccept for new forms (PROPOSAL; the owner set no default); NoAcceptance for converted legacy forms (PROPOSAL, RS-R04a)	R1 final
Accepted-answer completeness override	Form version ReconciliationPolicy	Versioned (PROPOSAL classification)	Follow requiredness	Q-04
Reconciliation identity blinding (forms)	Form version ReconciliationPolicy	Versioned (PROPOSAL classification)	Blinded	Q-28, Q-30, blinding amendment
Reconciled-answer hints baseline	Form version ReconciliationPolicy	Versioned (PROPOSAL classification, matching RD)	Shown	Q-28 hints amendment, Q-30
Hide hints at a step	Stage settings version, step	Versioned with the stage settings	Inherit the form baseline	Q-28 hints amendment
Bulk acceptance	Form operational settings	Audited (PROPOSAL classification)	Off	Q-11
Outdated-answer completion mode	Form version; the declared version applies to each Save or Complete	Versioned (PROPOSAL classification, matching RD)	Warn and allow Complete	D4-17 (O3)
Unstarted assignment expiry	Form (tasks) and profile (adjudication) operational settings	Audited	Off	Q-30
Self-reconciliation override	Project capability grant	Audited grant	Not granted	Q-36
Unsure	Profile version	Versioned	Off; on in the title/abstract template	D4-01
Sufficiency rule	Profile version	Versioned	Per profile	Existing
Tie policy and bound	Profile version	Versioned	No platform default; explicit choice; templates preselect	Tie amendment
Discussion	Profile version	Versioned	Off	D4-02
Adjudication rationale required	Profile version	Versioned (PROPOSAL classification)	Off	Q-32
Reason handling and primary reason	Profile version	Versioned (PROPOSAL classification)	Per template guidance	DP5, RX1, S3, D4-13
Reconciliation identity blinding (profiles)	Profile version	Versioned	Blinded	Blinding amendment
Adjudicator assignment	AdjudicatorAssignmentVersion	Versioned and audited; no profile publication	None (any eligible adjudicator)	Adjudicator assignment amendment

4. What loads and writes when

Every write below uses the C18 commit protocol: one study-scoped transaction, compare-and-set on the aggregates it changes, the command ID as the idempotency key, and durable effects (C19) for anything after commit. Structured history events use the C20 HistoryEvent envelope.

4.1 A reviewer completes a session where the effective target is one and the form accepts automatically

Step	Detail
Reads	The draft and its base version; the form version (standardTarget, ReconciliationPolicy, completeness); the current StudyTargetOverride version for this Study × form; the task and its current input set; current qualifying contributions (ContributionQualificationPolicy); the StudyGold pointer
Writes	The completed FormSessionVersion (draft consumed); a new task input set; and, when exactly one qualifying candidate exists, system-authored reconciled revisions, an AcceptedResultVersion (SingleAnnotator, SystemRule), a new GoldSnapshot, the StudyGold pointer and the Study summary
Transaction	The Complete command's study-scoped transaction (PROPOSAL). If the F1a transaction budget test refuses that size, acceptance becomes a durable effect keyed by (taskId, inputSetSeq): readiness shows Accepting until it lands, and a failed acceptance never rolls back the reviewer's Complete
Derived after	HistoryEvent AcceptedResultVersionCreated; targeted reevaluation of stage filters that read reconciled answers to this form's questions (SP); CurrentEvidenceView (DM); statistics; inference recompute if the project opted into the beta (TI)

4.2 A reviewer completes a session where the effective target is one and the form requires human reconciliation

The Complete writes the session version and a new task input set. The task becomes Ready with one candidate. No result is written. The task appears in the reconciliation pool and in My work for eligible reconcilers.

4.3 A reconciler starts reconciling

Step	Detail
Reads	Eligibility: Reconcile through a stage that binds the form, no candidate session on this Study × form (unless RS-R18 applies), the assignment if any; the current input set; each candidate session version's full pin map and revisions; the form version; the current accepted result and snapshot; held-question derivation; the blinding mode; the presentation mapping
Writes	The editor claim (compare-and-set plus lease on the task); a presentation mapping when this reconciliation session has none
Transaction	The task aggregate; the mapping insert is idempotent with the claim
Derived after	Presence (counts only for people without Monitor; D3-20); My work counts

The client receives aliases, positions and opaque handles. It never receives reviewer IDs or FormSession IDs, because a FormSession ID is derived from the reviewer's identity (DD-15) and could be recomputed from a membership list.

4.4 A reconciler completes

Step	Detail
Reads	The draft etag; the base snapshot ID and input-set etag the reconciler saw; the completeness rule; answer validity and applicability; exposure of relevant controls (the unseen-control warning, RE2)
Writes	The reconciliation session's completed version; reconciled revisions; a new GoldSnapshot; an AcceptedResultVersion (HumanReconciled, Individual, with candidateCount); the task state for that input set; claim release; the Study summary
Transaction	One study-scoped transaction. If either etag moved, a typed InputsChanged or GoldChanged conflict returns and the draft is kept (AC-R4a-27)
Derived after	As §4.1

4.5 A reconciler bulk-accepts agreeing Studies

Step	Detail
Reads	The form's bulkAcceptance setting; Studies where every qualifying candidate agrees on every compared applicable question; per-Study warnings; reconciler eligibility per Study; each Study's input-set etag
Writes	A bulk operation record (Studies listed, preview digest, confirming reconciler, time); then, per Study, the same writes as §4.4 with acceptanceMethod = BulkConfirmed
Transaction	One transaction per Study, each checking its etag; the operation record tracks per-Study outcomes and is idempotent on retry
Derived after	As §4.1, per Study

4.6 An admin publishes a form version that changes the standard target or target-one handling

RD owns the publication mechanics (fence, impact manifest, phases). This page owns the result treatment.

1. Preview. The impact manifest lists, with counts and Study lists: results that would fall below the new target; Studies that would newly meet the Single annotator condition; Single annotator results affected by a switch to required human reconciliation; open reconciliation sessions on affected tasks; Studies with target overrides (their effective target follows RD's override rule).
2. Treatment choices (explicit, recorded). For results below a raised target: "keep them accepted, labelled below current target" (default) or "suspend them until reconciled with the new number of candidates" (RD §4.9), with the preview showing which stage filters and dependent steps would stop treating those Studies as having accepted answers. For Studies that newly qualify: "create Single annotator results now" or "create them at the next qualifying completion". For a switch to required human reconciliation: "keep Single annotator results as accepted" or "queue those tasks for human reconciliation".
3. Recheck at commit. Inputs are revalidated at the publication fence.
4. Writes. Phase 1 as RD specifies. The phase-2 sweep writes generated AcceptedResultVersions (SingleAnnotator, actor = the system rule plus the publication operation and the confirming admin) and new task input sets where required. No existing result is rewritten. No session or vote is created.
5. Derived after. Notices to reconcilers with open sessions on affected tasks (captured through C15; delivery is not authorised); history events; targeted filter reevaluation only where a new result changed accepted answers.

4.7 A reviewer sees a hint and clicks to fill

1. Reads. The hint baseline in the session's resolved form version, the step override, the Study's current GoldSnapshot entry for the same answer context, the compatibility class between the source and the reviewer's question version, applicability under the current branch, and the reviewer's accepted-answer view access.
2. Shown. The control renders the hint. The next draft, Save or Complete payload carries a reconciledHintShown exposure.
3. Click-to-fill. A draft patch writes the value with an adoption marker (source revision, snapshot sequence, mapping). Replacing a value the reviewer had entered needs an explicit confirmation.
4. Save or Complete. The session version commits with reconciledHintAdopted entries and the adoptedFrom provenance on the written revisions. Autosave never touches Study.
5. Derived after. The session version is informed for those questions (VS2); agreement statistics exclude adopted answers from independent comparisons; the reconciliation workspace labels them.

4.8 A reviewer completes with outdated answers

The Complete reads outdatedAnswerCompletion from the form version it declares, and the session's outdated flags. Under WarnAllowComplete it shows the warning and accepts "Complete anyway". Under BlockUntilAddressed it refuses with the list and jump links. Either way the draft is kept, mandatory re-answering still applies, and the completed version records the declared form version (and so the mode) and the evidence versions used.

4.9 A screening decision is submitted

Step	Detail
Reads	The profile version; other candidates' current decisions (server-side only); the current ScreeningOutcome; any open discussion or adjudication task; source policies
Writes	The decision revision (profile session version); the ScreeningOutcome via CollectiveOutcomePolicy (§5.10 table); where needed, an extra-review allowance on the outcome, a ScreeningDiscussion, or an AdjudicationTask with a deterministic ID; the Study summary
Transaction	One study-scoped transaction
Derived after	HistoryEvent ScreeningOutcomeChanged when a facet changes; targeted filter reevaluation when the final facet changes (SP); notices to the assignee (capture only); statistics

4.10 Discussion opens, a participant corrects, or the discussion ends

Opening records the participants' exposure to each other's decisions and reasons. A correction is an ordinary own-decision correction (DP2) that writes a new decision version and re-runs the profile rule in the same transaction. Ending unresolved records the reason and applies the tie policy in the same transaction.

4.11 An adjudicator claims and resolves

Step	Detail
Reads	Eligibility (§6); the current assignment version; the exact input vector; the profile blinding mode; the rationale requirement
Writes	Claim: the editor claim on the task. Resolve: an AdjudicationVersion, the ScreeningOutcome final facet, the task state Resolved, claim release, the Study summary
Transaction	One study-scoped transaction per command. A changed input vector since the claim returns a typed InputsChanged conflict and keeps the draft
Derived after	As §4.9

4.12 An admin publishes a profile version that changes Unsure, the tie policy, the bound or discussion

The Q-26 flow applies. The preview lists open ties, AwaitingExtraReview and PendingAdjudication Studies, open discussions and in-flight extra decisions. PROPOSAL treatment: open adjudication tasks and discussions created under the old version continue and their results stand; Studies with no open work item are re-evaluated under the new version only as the admin's chosen Q-26 treatment says. Original decisions and outcome history never change.

4.13 An admin changes the adjudicator assignment

The preview lists claimed tasks held by members who would leave the assignment. The admin may cancel, or use Apply anyway to release those claims (drafts kept). The new AdjudicatorAssignmentVersion and any releases commit together; affected members receive a notice (capture only).

5. Rules

5.1 Target one

• RS-R01 Single annotator acceptance. When a Study × form's effective target is one, the form version's targetOneHandling is AutoAccept, and exactly one qualifying candidate session exists, SyRF creates an immutable AcceptedResultVersion with authority SingleAnnotator, the exact candidate session version and the rule version. Owner decision: Q-29 (R1 final; consolidation §4).
• RS-R02 Labels. A Single annotator result is never labelled reconciled, verified or checked. Exports and the methods summary call it "Single annotator (accepted automatically)". Owner decision: Q-29; label text PROPOSAL (U1 wording flexibility applies).
• RS-R03 One candidate, human reconciliation. Under RequireHumanReconciliation the same task becomes ready with one candidate. An eligible reconciler completes it in the normal workspace. The result is HumanReconciled with candidateCount = 1 and may be displayed as "Reconciled (one candidate)". No separate engine, session type or Verified authority exists. Owner decision: D4-03 via R1 final.
• RS-R04 Configuration. targetOneHandling is part of the immutable form version and changes through publication with impact preview. New forms default to AutoAccept. Owner decision: R1 final for versioning; the default is PROPOSAL (§12).
• RS-R04a Faithful conversion of legacy target-one forms. Legacy single-reviewer forms export the reviewer's answers and have no accepted results. Baseline conversion sets targetOneHandling = NoAcceptance: no automatic result, no required reconciliation work, and exports keep the label "single annotator, not accepted". Only conversion can set this value; new forms choose between the two owner-approved values. The admin moves a converted form to either of them by publishing a new form version, whose impact treatment (RS-R11) decides whether results are created. PROPOSAL, answering BC ambiguity A1 under the R4 rule that conversion adds no workflow constraints; owner-visible (§12).
• RS-R05 Precedence. The effective target is the current applicable StudyTargetOverride version for the Study × form, otherwise FormVersion.standardTarget (RD). targetOneHandling applies whenever the effective target is one, including when an override sets it. RS reads only the resulting effective target; how an existing override combines with a newly published standard target is RD's rule. PROPOSAL (R1 asks the brief to specify precedence).
• RS-R06 Readiness. Readiness is computed from current qualifying contributions at query time, or from a cache that is current for the relevant input versions (Q-27). States: NotReady, Ready, Accepting (only when acceptance runs as a durable effect), Accepted, InputsChanged, BelowCurrentTarget. Owner decision: Q-27, R1; state names PROPOSAL.
• RS-R07 No automatic multi-candidate acceptance. Two or more qualifying candidates always need a human reconciler, even when they agree and even when the effective target is one. Owner boundary: R1 final; T-POL-03 stays unapproved.
• RS-R08 Surplus candidate. A qualifying candidate arriving after a Single annotator result puts the task into InputsChanged. The existing result stays effective, labelled "inputs changed", until a human reconciler completes the next version. Owner decision: consolidation §1 (never silently rewritten); detail PROPOSAL.

5.2 Result versions and target changes

• RS-R09 Never rewritten. A new target, policy or input creates a new AcceptedResultVersion only through the entitled rule or person. Earlier versions stay immutable and queryable. Each version records the form version, any override version, the effective target, the input set and the actor or rule. Owner decision: target-versions-form amendment; R1. Under AutoAccept the configured rule is the entitled creator of SingleAnnotator versions: when the sole qualifying candidate completes again after a correction, the rule writes the next version and the earlier one stays in history (§9.1). PROPOSAL; owner-visible item in §12, because the owner rule reserves new versions of human-authored results for explicit reconsideration.
• RS-R10 Raising the target invents nothing. By default, results below the new target stay effective and show BelowCurrentTarget. The publishing admin may instead suspend them; a suspended result stays in history, readers that use accepted answers as current (stage filters, gates, hints, collective inference) treat the Study as having none for that form, and the next completed reconciliation writes the replacement. Readiness reports how many qualifying candidates are missing. No placeholder session, vote or reviewer is created, and the new requirement is never declared satisfied. Owner decision: consolidation §4; Q-29 recorded direction; the suspend option is PROPOSAL (aligned with RD §4.9).
• RS-R11 Newly qualifying Studies. When a publication lowers the target to one or switches to AutoAccept, Studies that now meet RS-R01 get results only through the treatment the publishing admin confirms. Generated results record the publication operation and the confirming admin. Owner decision: D2-01 amended (publication may create attributable generated versions); treatment PROPOSAL.
• RS-R12 Switching to human reconciliation. Existing Single annotator results stay effective. The admin chooses to keep them or to queue those tasks for human reconciliation. A queued task's result is replaced only when a reconciler completes. PROPOSAL under R1.

5.3 Completeness and missing comparisons

• RS-R13 Requiredness. A reconciler can complete when every required applicable question has an accepted value. The form override can require more (named optional questions, or every applicable question). No stage or step override exists. Owner decision: Q-04; override shape PROPOSAL.
• RS-R14 Blank is Not assessed. A blank candidate answer is "Not assessed" for that comparison. It is neither agreement nor disagreement, it never blocks reconciliation, and agreement statistics count it separately. A blank is never Not applicable (UA1). Owner decision: Q-04.
• RS-R15 Unknown and Not reported are answers. They compare like any other option: two "Not reported" answers agree; "Not reported" against a value disagrees. Owner decision: Q-04.
• RS-R16 Legacy gaps are not answers. NotRecordedInLegacy and the other legacy-gap states (BC) are never treated as Unknown, Not reported or blank. Owner decision: R4 universal baseline direction.

5.4 Authority and eligibility

• RS-R17 No self-reconciliation by default. A member with a candidate session on a Study × form is never offered or allowed its reconciliation task, including a one-candidate task under RequireHumanReconciliation. A member who cast a decision on a Study × profile is never offered or allowed its adjudication. Owner decision: Q-36.
• RS-R18 Explicit override grant. An exception needs the explicit override grant of §3.11, scoped to named forms or profiles and held by a named member or group. Every use is recorded on the result and shown in its provenance, in exports and in the methods summary. Owner decision: Q-36 ("explicit override grants"); scope and recording PROPOSAL; interpretation in §12.
• RS-R19 Current authority for new admissions. Gates that read accepted results or screening outcomes use authoritative current records or a projection proven current by its DefinitionVersionVector. A stale projection fails closed for new admissions and shows "needs revalidation". Saved work is kept. An effective result standing at InputsChanged or NeedsReReconciliation stays effective (GS1) and is never shown as freshly reconciled. Owner decision: Q-36; Q-27.
• RS-R20 Query self-review stays separate. QY4's audited self-review applies only to query resolution. Owner decision: Q-36; QY4.

5.5 Bulk acceptance

• RS-R21 Optional. Bulk acceptance is a per-form setting, off by default, delivered after the core reconciliation workflow. Owner decision: Q-11.
• RS-R22 Explicit confirmation. The screen shows each Study's valid answers and warnings. The reconciler confirms the exact list. Each result is HumanReconciled with BulkConfirmed, the reconciler and the exact input set. Agreement alone never creates a result. Owner decision: Q-11 (R2).
• RS-R23 What bulk never includes. Studies with a held question, inputs changed since the preview, a required blank, a compared free-text difference, the reconciler as a candidate, or any disagreement on a compared question. PROPOSAL.

5.6 Blinding and candidate ordering

• RS-R24 Ownership. The form owns reconciliation identity blinding for its tasks. The profile owns blinding for adjudication and screening-annotation reconciliation. Stages and steps have no blinding setting. Default is blinded. Owner decision: Q-28, Q-30, blinding amendment.
• RS-R25 Context-local aliases. Aliases are drawn at random per reconciliation context and independently for every Study. No persistent pseudonym exists, and renaming a persistent identifier does not meet this rule. Owner decision: Q-30 (no cross-Study continuity).
• RS-R26 Unpredictable order. Display order is a random permutation independent of names, membership order, allocation order and submission time. Owner decision: blinding amendment.
• RS-R27 Stable while working. The mapping stays fixed through one reconciliation session, including Save and resume. New candidates are appended with fresh random aliases. A later session draws a fresh mapping. Owner recommendation in the blinding amendment, to validate with users; detail PROPOSAL.
• RS-R28 Hidden clues. In blinded mode the reconciler's payloads and screens carry no reviewer IDs, FormSession IDs, avatars, submission or edit times, counts that reveal chronology, allocation or assignment metadata, route stage, or "first submitted" wording. Candidate notes appear under the alias. Owner decision: blinding amendment; the list is PROPOSAL.
• RS-R29 Protected attribution. Real identities and mappings sit in protected provenance. Disclosure follows the C10 export disclosure contract and is audited. Random presentation never changes attribution or independence accounting. Owner decision: blinding amendment.
• RS-R30 Names visible. When the form or profile sets NamesVisible, names show and the order stays random. PROPOSAL.

5.7 Reconciled-answer hints

• RS-R31 Baseline and override. The form baseline shows hints by default and may hide them. A step may hide them; it can never reveal hints the form hides. The baseline that applies is the one in the session's resolved form version. Owner decision: Q-28 hints amendment; Q-30; version placement PROPOSAL (matching RD).
• RS-R32 What a hint shows. A hint appears only where an applicable accepted answer exists for the same Study and answer context under the question-version compatibility and mapping rules. It is labelled as an existing accepted answer with its authority and snapshot version. The reconciler's name is shown only to members with history access, and candidate identities never. For a question shared by two forms, the second form's reconciler sees the existing accepted answer through this same hint (D2-09, decided 5 October 2026; RD §4.14). Owner decision: hints amendment; D2-09; display detail PROPOSAL.
• RS-R33 No prefilling. SyRF never fills a control from a hint. The reviewer uses "Use accepted answer" per question, or "Use all available accepted answers". Replacing a value the reviewer entered needs an explicit choice. No fill action appears where no applicable hint exists. Owner decision: hints amendment.
• RS-R34 Exposure and adoption. HintExposure is written when the hint renders in view and HintAdoption when it is copied, both carried in the draft, Save and Complete payloads. Owner decision: hints amendment.
• RS-R35 Never independent evidence. Adopted answers still count toward qualification and progress (VS2). They are excluded from independent agreement observations and are labelled in reconciliation and exports. Owner decision: hints amendment; VS2.
• RS-R36 Hiding never erases. Hiding hints through a step never removes answers already entered or adopted in the shared session and never undoes exposure through another route. Owner decision: hints amendment.
• RS-R37 Entity instances. The first release offers hints only where the answer context matches without instance correspondence (Study-level questions and option branches). Hints for repeatable entity instances need a correspondence rule first (§12). PROPOSAL.
• RS-R38 Hints never submit. Showing or copying a hint creates no session version; explicit Save or Complete does. Owner decision: hints amendment.

5.8 Outdated answers

• RS-R39 Configurable mode. An authorised project designer or admin chooses WarnAllowComplete (default) or BlockUntilAddressed. Owner decision: D4-17 (O3).
• RS-R40 Limits. Neither mode bypasses validation, applicability, permissions or mandatory publication and re-review treatment. Drafts are kept. Each completed version records the declared form version (and so the mode) and the evidence versions. Owner decision: D4-17 (O3).
• RS-R41 Ownership. The setting is part of the form version and applies through every route to the shared session; the mode in the version a Save or Complete declares is the one that applies. A session pinned to an older version keeps that version's mode until it upgrades. No stage or step setting and no stage-entry gate exist. Owner decision asks the brief for ownership consistent with shared sessions; placement PROPOSAL (matching RD's classification).
• RS-R42 Scope. The setting governs warning-class outdated flags (an own answer change that left a dependent answer outdated, and answers flagged under doNothing or autoUpdate policies). Mandatory "Needs updating" under requireReanswer already blocks Complete in both modes (VU1). Reconciliation sessions use held-question and re-reconciliation rules instead. PROPOSAL.

5.9 Screening outcome rules

• RS-R43 Profile rules are not annotation acceptance. A profile's sufficiency rule combining decisions into a collective outcome is the profile's configured screening rule. It is distinct from accepted annotation answers and is not the unapproved automatic acceptance policy. Owner decision: S3 clarification (agreement requirements follow explicit profile configuration).
• RS-R44 Outcome states. Pending, AwaitingExtraReview, InDiscussion, PendingAdjudication, Included, Excluded. Only the last two are definite. Owner decision: tie amendment (pending adjudication is not definite); names PROPOSAL.
• RS-R45 Order independence. The outcome is evaluated over the multiset of current applicable decisions, so the same decisions in any order give the same result. Owner decision: S1 amendment requires it; rule PROPOSAL.

5.10 Unsure

• RS-R46 Per profile. Unsure is a profile version setting, on in the proposed title/abstract template. Owner decision: D4-01.
• RS-R47 Availability. Unsure counts as not excluded. A filter clause on Included does not match Unsure or pending states. Exclusion-stop never triggers on Unsure. Owner decision: D4-01 ("treat Unsure like Include for availability"), S1 amendment. Own Unsure and progression (PROPOSAL, consistent with D4-01). Under the stage default OwnIncludeSufficient (Q-01), a reviewer's own current Unsure satisfies a screening dependency exactly as their own Include does, and it tries the dependent annotation claim as an own Include does (D3-19). It never satisfies CollectiveIncludeRequired, never counts toward a definite collective Include (RS-R48) and never triggers personal exclusion-stop. SP §3.4 states the same rule. The single confirm item is in §12 (it replaces SP-AMB-04).
• RS-R48 Never a definite Include. Unsure never counts toward agreement for a definite outcome. Owner decision: S1 amendment.
• RS-R49 Bounded handling. Unresolved combinations follow the table below. The profile chooses the extra-review or earlier-adjudication policy and its bound. SyRF imposes no common numeric threshold. Owner decision: S1 amendment.

Worked transition table for the owner's example configuration (two initial decisions, two agreeing definite decisions required, ExtraReview with a bound of one additional decision, then adjudication). Decisions are listed as a set because evaluation is order-independent. "Owner" rows restate the S1 amendment. "Derived" rows apply the same stated rule and need confirmation in the brief.

Current decisions (any order)	Outcome under ExtraReview, bound 1	Outcome under Adjudication (earlier adjudication)	Basis
{Include} or {Unsure} or {Exclude}	Pending (second decision needed)	Pending	Existing sufficiency rule
{Include, Include}	Included; no third requested	Included	Owner
{Exclude, Exclude}	Excluded; no third requested	Excluded	Owner
{Include, Exclude}	AwaitingExtraReview (one more decision)	PendingAdjudication	Owner (both pathways, tie amendment)
{Include, Unsure}	AwaitingExtraReview	PendingAdjudication	Owner (third reviewer when the first two give no definite outcome); adjudication column derived
{Exclude, Unsure}	AwaitingExtraReview	PendingAdjudication	Derived (same rule)
{Unsure, Unsure}	AwaitingExtraReview	PendingAdjudication, unless the all-Unsure rule decides otherwise	Derived; all-Unsure is still to specify
{Include, Unsure, Include}	Included	Only if a third arrived in flight; see the list below	Owner
{Exclude, Unsure, Exclude}	Excluded	As above	Owner
{Include, Unsure, Exclude}	PendingAdjudication	As above	Owner
{Include, Unsure, Unsure}	PendingAdjudication	As above	Owner
{Exclude, Unsure, Unsure}	PendingAdjudication	As above	Derived (symmetry)
{Include, Exclude, Include}	Included	As above	Derived (two agreeing definite; today's third-vote behaviour)
{Include, Exclude, Exclude}	Excluded	As above	Derived
{Include, Exclude, Unsure}	PendingAdjudication	As above	Derived
{Unsure, Unsure, Unsure}	Still to specify	Still to specify	Brief item

Because evaluation is order-independent, {Include, Include, Unsure} (a third decision allowed after sufficiency, or in flight) is the same set as {Include, Unsure, Include} and gives Included.

Rows and rules still to specify in the screening brief (owner: "the full transition table ... must be specified and tested in the brief"):

1. All Unsure ({Unsure, Unsure, Unsure}, and {Unsure, Unsure} under earlier adjudication). Options: (a) adjudication; (b) a collective "Unsure (not excluded)" outcome that keeps the Study available to stages filtering on "not Excluded" without a definite Include; © further review beyond the bound, which the owner's no-repeated-review rule rules out. Recommendation: (a) by default, with (b) only as an explicit per-profile option if Chris approves it.
2. In-flight responses (a decision submitted after a definite outcome or after adjudication work was created, from a session started earlier). Options: (a) evaluate the full current set, withdraw an unstarted adjudication task, and warn a started adjudicator with InputsChanged; (b) freeze the input vector when adjudication is created and record later decisions without changing the outcome until it is resolved. Recommendation: (a) until an adjudicator starts, then (b) for that task.
3. Four or more decisions (for example {Include, Include, Exclude, Exclude} from in-flight work or additional-review requests). A majority guard is needed. Recommendation: a definite outcome needs the required number of agreeing definite decisions and strictly more of them than the opposite value; otherwise adjudication.
4. Other thresholds: three agreeing decisions, unanimity of three, majority of N, and a single-screener profile with Unsure enabled ({Unsure} alone). Recommendation: single-screener Unsure follows the profile's tie policy, matching the sole-source AI rule in E3.
5. Bounds above one, for example {Include, Unsure, Unsure} with a bound of two. Recommendation: request one more decision at a time until two agreeing definite decisions exist or the bound is used.
6. Mixed sources. AI-model-generated decisions counted as a contributing vote use the same table; repeated outputs from one model are revisions, never extra voters (E3, specified in RI).

5.11 Ties and adjudication

• RS-R50 Explicit tie policy. Every profile version records ExtraReview with a bound, or Adjudication. SyRF infers no default: creating a profile requires the choice; templates preselect it visibly; baseline conversion maps the legacy behaviour (BC). Owner decision: tie amendment ("do not infer an unchosen default").
• RS-R51 Extra review is bounded. Extra review requests one additional decision at a time up to the bound. When the bound is used without a definite outcome, the Study goes to adjudication. Owner decision: S1 amendment.
• RS-R52 Distinct triggers. Decision tie, unresolved Unsure, reason disagreement and sole-source AI Unsure are separate triggers with separately configured handling in the profile. Extra review never resolves a reason disagreement (AC-R4p-05). Owner decision: adjudicator assignment amendment; E3 for the AI trigger.
• RS-R53 Authority. An adjudicator needs the adjudication capability for the profile. Until F1b names it, that is Reconcile on any stage that binds the profile (permission matrix, "Stage Reconcile must cover both authorized ordinary and screening reconciliation"). Assignment never grants it. Owner decision: adjudicator assignment amendment; capability mapping PROPOSAL.
• RS-R54 Assignment. The assignee is a member or an eligible project group. With a group, any member who holds the authority and is otherwise eligible may claim; one claim at a time; the resolver is recorded individually. Assignment changes are versioned, audited and previewed (§4.13). Owner decision: adjudicator assignment amendment.
• RS-R55 What the adjudicator sees and writes. The exact tied decision versions under the profile's blinding. The adjudicator submits a new immutable AdjudicationVersion; the original decisions and history stay. Owner decision: tie amendment.
• RS-R56 Rationale. When the profile requires it (off by default), an adjudicated decision cannot be submitted without a rationale. Ordinary reconciled-answer explanations stay optional (RE1). Owner decision: Q-32.
• RS-R57 Pending stays pending. While an outcome is AwaitingExtraReview, InDiscussion or PendingAdjudication, steps that depend on it under CollectiveIncludeRequired keep waiting, and progression after the reviewer's own Include (or own Unsure, RS-R47) continues under the Q-01 default (SP §3.4 dependency table; SP-R15, SP-R16). Exclusion-stop needs a definite collective Exclude: a pending outcome never triggers it, and an adjudicated Exclude is a definite collective Exclude for the screening step's collective exclusion-stop and terminal exclusion (SP-R18, SP-R29). Owner decision: tie amendment; Q-01.
• RS-R58 Inputs change around adjudication. Before an adjudicator starts, a correction or new decision that satisfies the profile rule withdraws the open task with a reason, and one that still needs adjudication refreshes the task's input vector (PROPOSAL). After the adjudicator starts, a changed input vector returns a typed InputsChanged at submit and the draft is kept (PROPOSAL). After resolution, nothing rewrites the adjudicated outcome. A later correction, contribution exclusion (ACD §3.2), surplus decision or replaced external decision (RI §9.9) follows the owner rule for dependent results. The actor is warned before commit at the level their access allows (the RD §4.5 pattern): a candidate who may not see the outcome gets a generic warning that dependent results may be flagged for reconsideration, never one that reveals an adjudication or another candidate's decision (SP §6, predictive warnings); admins see the full preview. The adjudicator who resolved it and the current assignee are informed. The AdjudicationVersion stays the current final facet, flagged InputsChanged because its recorded input vector no longer equals the current decisions, so stage pools and gates keep reading it. A new adjudicated outcome is created only when an eligible adjudicator explicitly reconsiders it, which writes a new AdjudicationVersion against the current input vector. The candidate facet keeps recomputing from current decisions and is shown beside the flag. Owner decision: Q-27; O1 amendment ("existing dependent results remain intact ... new result versions created only through an explicit decision"); consolidation §1 ("Existing accepted/dependent work is never silently rewritten"). This supersedes the recovered 25 September fallback to the candidate facet after resolution (§14). AC ambiguity B1 is closed on the same basis.
• RS-R59 Mapping into the step model. Adjudication runs in a system-defined adjudication step, one of the step kinds in SP's step model (SP §3.4 "Step kinds"; SP-R91, SP-R92).
• Contents. The adjudication activity for one screening profile: its open AdjudicationTasks for any RS-R52 trigger (for decision triggers the outcome is PendingAdjudication). It holds no screening or annotation activity of its own. Adjudication resolves decisions already submitted, as reconciliation does (§4.3), so a task stays reachable when the outcome it waits on has moved the Study out of the stage's current pool, for example a reason disagreement on an Excluded Study (PROPOSAL).
• Where it appears. One adjudication step accompanies each screening step whose profile version can route work to adjudication. In practice that is every profile, because extra review ends in adjudication once its bound is used (RS-R51). One AdjudicationTask per Study × profile × trigger serves every stage that binds the profile, through each stage's adjudication step. The step appears in the step strip only for eligible adjudicators (RS-R17, RS-R53, RS-R54).
• Dependencies. Designers add no dependency edge to or from it. Downstream steps depend on the screening step and read its outcome (RS-R57). Open adjudication work counts as remaining work for automatic completion of each stage whose screening step binds the profile (SP §3.10).
• Exclusion-stop. The adjudication step has no exclusion-stop setting. The screening step's collective exclusion-stop applies once the adjudicated outcome is a definite Exclude.
• Discussion and extra review stay inside the screening step's resolution route (§3.10, RS-R51).
• It is never a stage-entry dependency. PROPOSAL (the tie amendment asks the brief to map ties, discussion and adjudication explicitly into the step model).

5.12 Discussion

• RS-R60 When it starts. Off by default per profile. It starts only after submitted independent decisions reveal a conflict. Owner decision: D4-02 (S2).
• RS-R61 Who sees what. The candidates whose decisions conflict see each other's decisions and reasons, under aliases when the profile is blinded. Exposure is recorded. Corrections are new decision versions; the initial versions stay. Owner decision: D4-02; aliases PROPOSAL.
• RS-R62 Independence. Independent agreement uses the initial pre-exposure observations; the current outcome uses the applicable current decisions. Owner decision: D4-02.
• RS-R63 Ending unresolved. A discussion ends unresolved when a participant declines or marks "cannot agree", an authorised admin closes it, or an optional admin-set time limit passes (no default duration). The tie policy then applies. Owner decision: D4-02 fallback; end conditions PROPOSAL.
• RS-R64 Records. Discussion text is a permissioned audit record, outside candidate-answer exports and agreement statistics. Owner decision: D3-25 (O2).

5.13 Exclusion reasons and legacy data

• RS-R65 No question-count limit. Profiles support several screening annotation questions and recorded reasons, with explicit must-agree answers. Additional answers are never discarded. Owner decision: S3 clarification.
• RS-R66 Primary reason is guidance. A template may nominate "primary reason = first failing criterion in configured order" (the D4-13 default where nominated), with a per-profile option for reviewer choice. When no primary exists, reason coverage says so. Owner decision: S3 clarification; D4-13.
• RS-R67 Counting handoff. Distinct excluded Studies are counted separately from overlapping per-reason counts; RI owns the counting and labels. Owner decision: S3 clarification.
• RS-R68 No legacy reconciliation backfill. The canonical model has no LegacyAuthorityUnknown authority and no required legacy-reconciliation lane. The migration dry run (BC) confirms the premise; unexpected records stop that migration case and surface their provenance treatment. Owner decision: Q-35 removed.

5.14 Assignment expiry

• RS-R69 Optional expiry. Expiry of explicitly assigned, unstarted reconciliation or adjudication work is off by default. An authorised admin can enable it and set the duration. It never applies to started work and never deletes evidence. Every setting and assignment change is audited. Owner decision: Q-30.

6. Authorisation, blinding and provenance

Action	Capability (NEW = proposed in the permission matrix or here)	Further eligibility	Provenance recorded
Reconcile a form task (any target)	Reconcile on a stage that binds the form	No candidate session on the Study × form (RS-R17) unless the override grant applies; assignment if set	Reconciler, input set, blinding mode, mapping reference, override use
Bulk-accept	Reconcile, as above	Per Study; form setting on	BulkConfirmed, bulk operation ID, preview digest
Adjudicate	Adjudication capability (Reconcile through a binding stage until F1b)	No decision on the Study × profile unless overridden; in the assignment if set	Adjudicator, input vector, rationale, trigger
Assign adjudicators or reconcilers	NEW Assign reconciliation work	The assignee must be eligible	Assignment version, actor, time
Change ReconciliationPolicy or profile version settings	Design to draft; NEW Publish review definitions to publish	Publication impact flow	Form or profile version, issue record
Change form operational settings (bulk acceptance, assignment expiry)	Design on the project	Active-work preview	Settings audit entry
Hide hints at a step	Design on the stage	None	Stage settings version
Grant the self-reconciliation override	Owner, or a delegated permission administrator inside the envelope (PM2)	Anti-escalation (C10)	authorizationAudit entry
See hints	Review plus accepted-answer view access	Effective visibility of the step in use	HintExposure
Take part in a discussion	Being a candidate in the conflict	Profile discussion on	Exposure entries
See real identities behind aliases	History and corrections capability under the C10 disclosure policy	Audited unmasking	Disclosure audit

Blinding applies to every channel through DisclosurePolicy: interactive reads, history, exports, notices and presence (C10). Notices about reconciliation or adjudication never name candidates to a blinded recipient (D3-22). Provenance is complete in protected history: real actors, exact versions, mappings, override use, exposure and adoption.

History events emitted (C20 envelope; event type names PROPOSAL): AcceptedResultVersionCreated, ReconciliationTaskInputsChanged, BulkAcceptanceConfirmed, ScreeningOutcomeChanged, AdjudicationTaskCreated, AdjudicationTaskAssigned, AdjudicationTaskWithdrawn, AdjudicationResolved, ScreeningDiscussionOpened, ScreeningDiscussionEnded, ReconciliationSettingChanged, AdjudicatorAssignmentChanged.

7. Active-work impacts

Change	Warned before commit	Recheck at commit	Notified after (capture only; delivery not authorised)	Apply anyway
Publish a form version changing target or target-one handling	Counts and lists from §4.6; open reconciliation sessions	Publication fence inputs	Reconcilers with open sessions on affected tasks	Not applicable
Change form blinding (via publication)	Reconcilers with open sessions	Fence	Those reconcilers; a switch to blinded takes effect on their next load, a switch to names visible at their next session	Not applicable
Change the hint baseline (via publication) or a step's hide override (via stage settings)	Reviewers with open sessions on the form or step	Publication fence or stage settings head	Affected reviewers (hints appear or disappear; adopted values stay)	Not applicable
Turn on bulk acceptance	None needed	None	None	Not applicable
Switch the outdated mode to block (via publication)	Count of open sessions with outdated flags, and how many stay on an older version's mode until they upgrade	Publication fence	Those reviewers	Not applicable
Publish a profile version changing Unsure, tie policy, bound or discussion	Open ties, pending adjudications, discussions, in-flight extra decisions	Q-26 fence	Assignees and participants of affected items	Not applicable
Change adjudicator assignment	Claimed tasks held by members leaving the assignment	Claims and assignment version	Affected members	Releases those claims only; drafts kept; never bypasses eligibility
Revoke a reconciler's or adjudicator's authority	Their started work	Grants at submit	The member	Not applicable; saved work is kept and must be reacquired by an eligible member
Contribution exclusion (AC) affecting candidates	Tasks and outcomes whose inputs change	Input sets	Reconcilers and authors of affected results	Not applicable

Apply anyway never bypasses permissions, blinding, eligibility or invalid configuration (consolidation §6).

8. Failure and recovery

Failure	Behaviour	Recovery
Automatic acceptance fails inside the Complete transaction	The whole Complete fails and the draft is kept	Retry with the same command ID returns the same outcome
Automatic acceptance runs as a durable effect and fails	The Complete stands; readiness shows Accepting	The effect retries idempotently on (taskId, inputSetSeq); a later input set supersedes it
Two reviewers complete at the same moment on a target-one form	The task input-set compare-and-set serialises them	The second commit sees two candidates and leaves the task Ready for a human
Inputs change while a reconciler works	Typed InputsChanged at Complete; draft kept	The reconciler reloads; the mapping is extended without reshuffling
Bulk acceptance partly fails	Successful Studies commit; failed ones stay in the pool with reasons	Rerunning the operation skips completed Studies
Presentation mapping missing or unreadable	The workspace refuses to open the candidates; it never falls back to names	A new reconciliation session draws a fresh mapping
Hint source changes between display and click	The fill uses the revision shown and records it; the hint shows the newer accepted version on reload	The reviewer may refill from the newer version
Adjudication input vector changes after claim	Typed InputsChanged at submit; draft kept	RS-R58 applies
Adjudicator loses group membership or authority mid-task	Refused at submit; draft kept	Another eligible member claims after admin release
Profile publication races an adjudication submit	The profile fence orders them; the adjudication pins the version it applied to	RS-R58 and §4.12
Unexpected legacy reconciliation records found	The migration case stops (BC)	Provenance treatment is surfaced for an explicit decision

9. User flows and examples

Example project. "Neuroprotection in focal ischaemia (example)". Forms: Study design v3 (standard target 1, accept automatically), Risk of bias v2 (target 2), Outcome data v1 (target 1, require human reconciliation). Profiles: Title/abstract v1 (two agreeing decisions, Unsure on, extra review with a bound of 1, discussion off) and Full text v2 (two agreeing decisions, Unsure off, adjudication, rationale required, discussion on). People: reviewers Priya Shah, Omar Haddad and Zainab Mensah; reconciler Ewan Fraser; project designer Aisha Rahman; group "Senior screeners" with Ben Carter and Chloe Martin; owner Daniel Okafor. Studies: S-0412 (Smith 2019), S-0518 (Lopez 2021), S-0623 (Nakamura 2018), S-0730 (Osei 2020), S-0811 (Brown 2022).

9.1 Single annotator

Priya completes Study design on S-0412. The Study shows "Accepted automatically · Single annotator". History shows the rule, form v3 and Priya's session version 2. Later Priya saves an incomplete correction. Her session stops qualifying, the task shows "Inputs changed", and the accepted result stays effective with that label. When she completes again, the task has one qualifying candidate again, so the rule creates Single annotator version 2. Version 1 stays in history.

9.2 One candidate, checked by a second person

Omar completes Outcome data on S-0518. The pool shows "Ready · 1 candidate". Ewan presses Start reconciling and sees one column, "Reviewer A". He corrects one standard deviation and completes. The result reads "Reconciled (one candidate) · Ewan Fraser". If Omar had pressed Start reconciling on S-0518 he would see "You reviewed this study" and the task would not open.

9.3 A surplus candidate after automatic acceptance

The capacity cap is off, so Zainab also completes Study design on S-0412. The task shows "Inputs changed · 2 candidates". The Single annotator result stays effective and labelled. Ewan reconciles. The candidates agree on every answer, but nothing is accepted until Ewan completes. Version 3 reads "Reconciled · 2 candidates".

9.4 The target changes

Aisha drafts Study design v4 with a standard target of 2 and no question changes. The preview says: "312 Studies have Single annotator results. They stay accepted and will show 'below current target (1 of 2)'. 6 reviewers have drafts. No reviews will be created." She publishes. S-0623 now shows "Accepted · below current target (1 of 2)". When Omar completes Study design on S-0623, the task becomes ready with two candidates and Ewan reconciles. The new result pins form v4. Nobody was added as a reviewer.

Later Aisha drafts Risk of bias v3, lowering the target from 2 to 1 with automatic acceptance. The preview lists 27 Studies with exactly one qualifying candidate and no result. She chooses "Create Single annotator results now". Each result records "Publication of Risk of bias v3, confirmed by Aisha Rahman". Studies with two candidates still need Ewan.

9.5 Blinded reconciliation with three candidates

Priya, Omar and Zainab all completed Risk of bias on S-0730. Ewan sees Reviewer A, B and C in a random order with no dates and no stage names. Omar's note appears as "Reviewer B's note". On S-0811 the same three people appear as C, A and B with a different mapping. Ewan saves and returns the next day; S-0730 shows the same mapping as before. Aisha then requests an additional review and Daniel Okafor's completed session arrives. It appears as "Reviewer D" at the end and the task shows "1 new candidate since you started".

9.6 Hints and click-to-fill

Zainab opens Outcome data on S-0412. The shared question "Species" already has an accepted answer from Study design. Under the control she sees "Accepted answer: Rat · accepted answers v3 · reconciled" and a "Use accepted answer" button. The control stays empty until she clicks. She clicks, then answers "Strain" herself. Her Complete records the exposure and the adoption. Her session counts toward the Outcome data target. The agreement report leaves her "Species" answer out of the independent comparisons. When she opens the same session through Stage 3, whose step hides hints, no hint shows, and her adopted "Rat" stays. Risk of bias has its baseline set to Hidden, so hints never appear there.

9.7 Outdated answers

Omar changes "Randomised?" from Yes to No on Risk of bias, which leaves "Method of randomisation" outdated. With the default mode, Complete shows "1 answer may be out of date" and offers "Complete anyway". Aisha switches the form to block mode; the preview tells her 4 open sessions have outdated flags. Omar's next Complete is refused with a jump link to the answer; his draft stays. A publication that requires re-answering blocks Complete in both modes.

9.8 Title/abstract tie with Unsure

• S-0518: Priya Include, Omar Unsure. The outcome is "Waiting for one more decision". Zainab includes, so the outcome is Included.
• S-0623: Priya Include, Omar Unsure, Zainab Exclude. The outcome is "Awaiting adjudication", assigned to "Senior screeners".
• S-0811: Priya Exclude, Omar Exclude. The outcome is Excluded with no third decision.
• While S-0623 awaits adjudication, Priya (who included) continues to the extraction step in the same stage under the default. Under the RS-R47 PROPOSAL, Omar (who answered Unsure) may continue too. A step that requires a collective Include waits.
• Later, after Ben has adjudicated S-0623 as Include, Zainab corrects her Exclude to Include. Before she commits, she sees the generic warning that results depending on her decision may be flagged for reconsideration. Candidates in this project cannot see screening outcomes, so the warning does not say that an adjudication exists or what the others decided. The adjudicated Include stays current, flagged "inputs changed", and Ben is informed. Nothing changes until an adjudicator reconsiders it (RS-R58).

9.9 Discussion, then adjudication

On Full text, Priya includes S-0730 and Omar excludes it ("Wrong population"). Discussion is on, so both are invited. Each sees "Reviewer A: Include" and "Reviewer B: Exclude · Wrong population". Priya keeps Include. Omar marks "Cannot agree". The discussion ends unresolved and an adjudication task appears in My work for the "Senior screeners" group. Chloe also screened S-0730 at full text, so only Ben sees it. Ben claims it, writes the required rationale and records Exclude with "Wrong population". The outcome reads "Excluded · adjudicated by Ben Carter". Both original decisions stay in history.

On S-0811 at full text the same conflict opens a discussion; Priya re-reads the methods and corrects to Exclude. The profile rule now gives Excluded. Agreement statistics still use Priya's initial Include as her independent observation.

9.10 Bulk acceptance

Risk of bias has bulk acceptance on. Ewan opens "Accept agreeing studies". It finds 47 Studies where every candidate agrees; 3 are left out with reasons (Ewan was a candidate on 2, one has a held question). Five of the remaining 44 show warnings, such as an optional question both candidates left blank. Ewan confirms "Accept 44 studies". One Study's inputs changed after the preview, so it is refused and stays in the pool. Each of the other 43 results reads "Reconciled · Ewan Fraser · bulk-confirmed".

9.11 Self-reconciliation override

In a two-person pilot, Daniel grants Ewan "Reconcile own contributions (override)" on Risk of bias. Ewan reconciles S-0412, where he was a candidate. The result shows "Eligibility override: reconciler was a candidate (grant v1, Daniel Okafor)" and the methods summary lists it. Without the grant, Daniel himself would be refused on a Study he reviewed.

9.12 Screen states

State	Reconciliation pool or adjudication queue shows
Loading	Skeleton rows with "Loading studies"
Empty	"No studies are ready" with counts of waiting, held and accepted Studies
Pending	"Waiting for 1 more qualifying review (1 of 2)" or "Awaiting adjudication"
Incomplete	The reconciler's "Version checkpoint saved · not completed" (U1 wording is illustrative)
Completed	"Accepted · Reconciled by you · v3"
Unavailable	"You reviewed this study", "Assigned to Chloe Martin", or "You no longer have Reconcile on a stage using this form"
Historical	The accepted-result timeline with superseded versions labelled and authorities shown
Conflict	"Inputs changed since you opened this study. Your draft is kept."
Failure	"We could not save your reconciliation. Your draft is kept." with Retry

10. Rollout and adoption

Capability	Release or lane	Entry dependencies	Flag decision (PROPOSAL)
ReconciliationPolicy fields on the form version	Schema at R2a (inert); behaviour at R4a	F1a, F4	No flag; inert until R4a
Single annotator and one-candidate human reconciliation	R4a	F4 (C9 ADR), X-RECLAIM, RD's effective target	Canonical enrolment scope, plus the R4a reconciliation kill switch
Result treatment on target or policy publication	Mechanics R2c (RD); result generation R4a	R2c, R4a	Covered by publication flags
Context-local blinding, random order, hidden clues	R4a (forms); R4p (profiles)	F4, F5	No separate flag; blinding is not optional behaviour
Hints and click-to-fill	R4a (needs accepted answers); cross-form hints need R2d	R4a, R2d	Own flag per environment so pilots can stage it; the form default is Shown once enabled
Bulk acceptance	Increment after R4a's pilot exit	R4a pilot	Own flag; per-form setting off by default
Outdated-answer mode	R2d (outdated flags and Fix)	R2d	No flag; default matches today's warning
Unsure, tie policy, bound and discussion fields in profile versions	R3b (extra-review path evaluated)	F5, R3a	No flag beyond profiles
Adjudication tasks, assignment, rationale, discussion	R4p	R3b, R4a, F4, F5	Discussion behind its own flag
Optional assignment expiry	R4a (tasks), R4p (adjudication)	Quartz timers (AC-R4a-40)	No flag; off by default
Self-reconciliation override grant	R4a; capability named at F1b	R1d delegation envelope	No flag; nothing granted by default

• Baseline (MVP). Everything above except bulk acceptance and the discussion route is part of the R4a and R4p baseline that GA needs (integrated plan §5.9).
• Optional after the core. Bulk acceptance (Q-11 says after the core workflow) and discussion (an optional profile route).
• Deferred or not approved. Hints for repeatable entity instances (§12); a collective all-Unsure outcome until decided; automatic acceptance of agreeing candidates (T-POL-03, not approved).
• Before R4a. Pilots on target-one forms keep their single assessment without an accepted result, labelled "single annotator, acceptance not yet available" (amends integrated plan §5.10). When R4a is enabled for a project, an admin-confirmed operation may create Single annotator results for Studies that meet RS-R01, with operation provenance. PROPOSAL; never a silent backfill.
• Before R4p. Profiles may choose adjudication. Studies that reach it stay visibly PendingAdjudication (integrated plan §5.10 pilot condition).
• Baseline conversion (BC). Legacy screening maps to profiles with the legacy tie behaviour made explicit (extra review with today's third-vote bound). Legacy target-one forms convert with NoAcceptance (RS-R04a), so conversion creates no accepted results and no reconciliation work. Legacy projects keep their semantics until converted. No legacy reconciliation backfill (RS-R68).
• Dependencies. RD (effective target, overrides, publication), SP (filter reevaluation, Q-01 progression, D3-09 early reconciliation with a warning), DM (MergeResolved), RI (agreement methods T-SI-02, PRISMA mapping T-SI-05, AI source policies), AC (contribution exclusion, conversations, notices), BC (premise check, legacy mapping), UX (phone, tablet and desktop reconciliation).
• Gates. Brief approval for T-RS-00, G0 (T-G0) and the hold lift (T-HOLD). None has happened.

11. Acceptance evidence

ID	Evidence	Method	Amends
RS-AE01	One Complete at an effective target of one under AutoAccept creates exactly one SingleAnnotator result referencing that session version and the rule version; the label never says reconciled or verified	Integration; inspection of export labels	AC-R4a-31
RS-AE02	Two simultaneous first Completes on a target-one form never produce an automatic result; the task ends Ready with two candidates (barrier harness; interleaving count set in the brief)	Integration, concurrency	New
RS-AE03	Under RequireHumanReconciliation a one-candidate task completes as HumanReconciled with candidateCount = 1; no Verified authority or verification session type exists in the API schema	Integration; schema inspection	AC-R4a-49
RS-AE04	A surplus candidate puts the task into InputsChanged; the existing result stays effective and is never retracted	Integration	AC-R4a-20
RS-AE05	Publishing a raised target creates no session, decision or reviewer (counts equal before and after); affected results show BelowCurrentTarget with the missing count, or SuspendedByTarget when the admin chose suspension, in which case filters, gates and hints treat them as absent and history still shows them	Integration	New
RS-AE06	Lowering a target with "create now" writes one SingleAnnotator result per qualifying Study with publication provenance; rerunning writes nothing new	Integration	New
RS-AE07	A required applicable blank blocks reconciler Complete; an optional blank does not; a form override makes a named optional question required; no stage or step completeness field exists	Integration; schema inspection	AC-R4a-44
RS-AE08	Fixtures: blank versus value counts as Not assessed; "Not reported" versus "Not reported" agrees; "Not reported" versus a value disagrees	Unit fixtures shared with R5c	New
RS-AE09	A candidate is refused their task in both target-one modes; a decision author is refused adjudication; the override grant permits it and is recorded; owner or admin without the grant is refused	Integration	AC-R4a-05, AC-R4a-28
RS-AE10	A gate reading a stale projection refuses new admission with "needs revalidation" and keeps saved work	Integration	New
RS-AE11	With bulk acceptance off no bulk endpoint acts; with it on, nothing is accepted without the confirmation tied to the preview digest; each result names the reconciler and BulkConfirmed; a changed Study is refused	Integration; end-to-end	New
RS-AE12	Blinded reconciliation and adjudication payloads contain no reviewer ID, FormSession ID, timestamp, route stage or allocation field	Contract test over response schemas; end-to-end	AC-R4a-08
RS-AE13	Over at least 1,000 synthetic Studies with the same three candidates, a reviewer's alias and position are independent of the Study, of submission order and of membership order (statistical test and threshold set in the brief)	Unit, statistical	New
RS-AE14	The mapping is identical across Save, reload and resume in one session; a new session draws a fresh mapping; a new candidate is appended without reshuffling	Integration	New
RS-AE15	Blinding comes only from the form or profile; no stage blinding field exists; a task reached through two stages shows the same blinding	Integration; schema inspection	AC-R4a-30, AC-R4a-48
RS-AE16	Hints show by default where an applicable accepted answer exists; the control value is unchanged until the reviewer clicks; a step can hide but never reveal; no fill action appears without an applicable hint	End-to-end	AC-R4a-42
RS-AE17	Hint exposure and adoption are recorded in the payloads; an adopted answer is excluded from independent agreement and still counts toward qualification	Integration; agreement fixture	New
RS-AE18	The default outdated mode allows Complete anyway; block mode refuses with the list; requireReanswer blocks in both; each Complete records the declared form version whose mode applied	Integration; end-to-end	Methodology §13.4 statement
RS-AE19	Every Owner and Derived row of the §5.10 table evaluates identically in every permutation of its decisions	Unit (CollectiveOutcomePolicy fixtures)	AC-R3b-14
RS-AE20	Unsure never counts toward a definite outcome; an own Unsure allows within-stage progression under the default; a filter on Included matches no pending or Unsure state	Integration	New
RS-AE21	A profile cannot be published without an explicit tie policy; templates show their preselection	Integration; UI test	New
RS-AE22	The rule never requests more additional decisions than the bound, then routes to adjudication	Integration	New
RS-AE23	A group assignment shows the task only to eligible members; a member without authority cannot claim; two members never hold one task; the resolver is recorded individually	Integration	AC-R4p-04
RS-AE24	With the rationale setting on, an adjudication without a rationale is refused; with it off it succeeds; ordinary reconciled answers never need one	Integration	AC-R4p-06
RS-AE25	While adjudication is pending, exclusion-stop does not trigger, collective-Include dependencies wait and the outcome is not definite in any reader	Integration	New
RS-AE26	A discussion opens only after a submitted conflict, records exposure, keeps initial decisions, leaves the initial-observation set unchanged and falls back to the tie policy when unresolved	Integration; agreement fixture	AC-R4p-08
RS-AE27	A profile with three reason questions and no primary reason keeps every answer in export and states reason coverage	Integration	AC-R3b-13
RS-AE28	No LegacyAuthorityUnknown code path exists; the dry run reports zero legacy reconciliation records or stops the case	Inspection; dry run (BC)	Replaces AC-R4a-12
RS-AE29	Expiry is off by default; once enabled it affects only explicit unstarted assignments	Integration	AC-R4a-07
RS-AE30	Testers from the agreed panel identify a result's authority and the blinding status without help	User test (D3-08 panel)	New
RS-AE31	Hint, fill, reconciliation and adjudication controls work by keyboard, touch and screen reader on phones, tablets and desktops	End-to-end; accessibility	New
RS-AE32	After an adjudication resolves, a correction, contribution exclusion or replaced external decision leaves the adjudicated outcome current and flagged InputsChanged; a candidate's pre-commit warning is generic and reveals neither the adjudication nor another candidate's decision; the adjudicator is informed; no pool membership changes by itself; a new AdjudicationVersion appears only after an explicit reconsideration	Integration; disclosure probe	New (replaces the candidate-facet fallback)
RS-AE33	The adjudication step appears only to eligible adjudicators, offers exactly the profile's open adjudication tasks (including one whose Study left the stage pool because of the outcome it waits on), accepts no designer dependency edge, keeps automatic completion open while adjudication is open, and an adjudicated Exclude triggers the screening step's collective exclusion-stop	Integration; schema inspection	New

12. Brief items, specialist inputs and unapproved proposals

This page owns none of the 22 session-register alignment entries or the three engineering contracts (D2-03, D2-04, D2-06). It consumes D4-12 and Q-16 (RI, T-SI-02), D3-09, D3-19 and D3-20 (SP) and D2-09 (RD, T-OI-01).

Item	Required treatment	Tracker
R1 policy precedence and readiness	Confirm RS-R04 to RS-R06 and RS-R11, RS-R12 in the brief, including the AutoAccept default	T-RS-00
Default for targetOneHandling	The owner stated no default. Options: AutoAccept (follows Q-29's retained path) or RequireHumanReconciliation. Recommendation: AutoAccept, visibly chosen in templates	T-RS-00 (owner-visible)
Converted target-one forms (BC ambiguity A1)	RS-R04a adds a conversion-only NoAcceptance value beyond the owner's two choices. Options: (a) that value; (b) convert with AutoAccept, which would create accepted results legacy never had; © convert with RequireHumanReconciliation, which would add work legacy never had. Recommendation: (a), as the faithful baseline	T-RS-00, T-BC-00 (owner-visible)
Q-36 override reading	Two readings: the override grant permits self-reconciliation with recording (adopted here), or "adjudication overrides" means only overriding an existing outcome. Recommendation: the adopted reading, because R2's package text pairs "no ordinary self-reconciliation by default" with "explicit override grants"	T-RS-00 (owner-visible)
Unsure transition rows	Specify and test the six items in §5.10	T-RS-00
Step-model mapping of ties, discussion and adjudication	Confirm RS-R59, now reflected in SP's step kinds (SP §3.4, SP-R91, SP-R92)	T-RS-00, T-SP-00
Own Unsure and progression (the single confirm item; SP-AMB-04 retired into it)	Options: (a) a reviewer's own Unsure satisfies own-Include progression and tries the dependent claim, never collective Include (RS-R47 PROPOSAL, also in SP §3.4); (b) own Unsure counts as no decision for progression; © a per-profile setting. Recommendation: (a), because D4-01 treats Unsure like Include for availability and the S1 amendment keeps it out of collective agreement	T-RS-00, T-SP-00 (owner-visible)
Re-acceptance under AutoAccept	When the sole qualifying candidate completes again after a correction, RS-R09 and §9.1 let the configured rule write the next SingleAnnotator version. Options: (a) the rule writes it, because AutoAccept is the admin's explicit, versioned acceptance policy, the only input author is the candidate who was warned before commit, and no human-authored result is regenerated; (b) the earlier version stays current, flagged, until someone explicitly re-accepts. Recommendation: (a). Owner-visible because the owner rule reserves new result versions for explicit reconsideration	T-RS-00 (owner-visible)
Outdated-mode ownership	Confirm RS-R41 and RS-R42	T-RS-00
Blinding presentation	Validate RS-R27 stability and the RS-R28 clue list with users	T-RS-00, T-UX-00
Entity-instance hints	Design a correspondence rule before extending hints to repeatable entities	T-RS-00
Screening-annotation agreement bypass	FEAT-009's agreement-derived reasons (truncated at disagreement) could be read as a profile agreement rule (S3) or as automatic acceptance (T-POL-03). Recommendation: treat it as a profile rule only for screening decisions and must-agree reasons the profile names; anything else goes to reconciliation	T-RS-00 (owner-visible)
Exclusion-reason template content and advice	Methodologists write the S3 template text and diagram-compatible guidance	T-RS-00 with CAMARADES methodologists
Source type under blinded adjudication	Whether a blinded adjudicator sees that a decision came from an AI screening model (RI ambiguity A2). RS-R28 hides human identities either way	T-RI-00, T-RS-00
Suspension of results below a raised target	Confirm that the RD §4.9 "suspend" treatment is wanted alongside the default "keep accepted" (RS-R10)	T-RS-00, T-RD-00
Agreement treatment of Unsure, adopted hints and discussion exposure	Specialist method review	T-SI-02
PRISMA treatment of Unsure and pending adjudication	Specialist mapping	T-SI-05
Thresholds	Any numeric bound, discussion time limit or expiry duration is proposed, not approved	T-RS-00
Automatic acceptance of agreeing candidates	Not approved; out of scope	T-POL-03

Harmonisation notes (5 October 2026). Changes made when the nine specifications were harmonised:

• §3.0 and §3.8: accepted-result authority follows the registry (SingleAnnotator, HumanReconciled, Adjudicated, MergeResolved). Screening outcomes carry outcome provenance instead: finalSource here plus RI §3.13's composition fields. RI's old six-value outcome authority list is retired.
• §3.2: added origin (Native, MergeCarriedForward, UnmergeCarriedForward) so DM's carried results have a field to record it.
• RS-R09: stated that re-acceptance by the AutoAccept rule is a PROPOSAL, with a new owner-visible item in this section.
• RS-R47: own-Unsure progression is now an explicit PROPOSAL consistent with D4-01, identical to SP §3.4. This section holds the single confirm item; SP-AMB-04 is retired into it.
• RS-R57 and RS-R59: rewritten to fit SP's step model (step kinds, contents, dependencies, exclusion-stop) with cross-references to SP §3.4, SP-R91 and SP-R92.
• RS-R58: after resolution, a correction or exclusion leaves the adjudicated outcome current and flagged until explicit reconsideration (Q-27; O1 amendment; consolidation §1). The 25 September fallback is listed as superseded in §14; ACD B1 is closed on the same basis.
• §9.8: added own-Unsure and post-adjudication correction examples. §11: added RS-AE32 and RS-AE33.
• RS-R59: adjudication tasks stay reachable when the outcome they wait on moved the Study out of the stage pool (for example a reason disagreement on an Excluded Study). §2: D4-19 is Decided-amended, matching SP.
• §13: domain-model AuthorityValue bullet split into accepted-result authority and outcome provenance; added the consistency-model §8.4 amendment. §14: added rows for the 25 September fallback and the old six-value outcome authority list.

13. Amendments to existing package documents

• contracts.md → C9. Replace the "Target-1 forms" row with RS-R01 to RS-R12 (a task exists; automatic SingleAnnotator or one-candidate human reconciliation; no Verified). Delete the "Legacy reconciled answers" row (Q-35 removed). Add AcceptedResultVersion, the presentation mapping, hints and bulk acceptance rows. Change "Screening-profile part" to the AdjudicationTask with triggers, assignment and rationale. Amend "Assignment" so expiry is optional and off by default. Amend the v10 dispositions: "Reconciler sees reviewers" moves to form and profile versions.
• contracts.md → C6. Remove BL1 from the stage settings version and the "most restrictive bound stage" rule. Replace VS1's stage default with the form hint baseline plus the step hide-only override. Remove the stage assignment-expiry default.
• contracts.md → C3. Add exposure kinds reconciledHintShown, reconciledHintAdopted and the discussion exposure.
• contracts.md → C4. Add ReconciliationPolicy to the form version; move profile Unsure, tie policy, bound, discussion, rationale and blinding into the profile version.
• contracts.md → C5. Add the outdated-answer completion setting and its recorded generation.
• domain-model.md → §4.2. Add resolutionState to ScreeningOutcomeValue; turn ProfileAdjudication into the AdjudicationTask aggregate; add AdjudicatorAssignmentVersion.
• domain-model.md → §4.3. Remove "Target-1 forms create no task"; add AcceptedResultVersion; remove Verified from StudyGold; keep "a reconciler is never a candidate" with the override exception.
• domain-model.md → §4.4 placement table. Blinding, VS1 and assignment expiry rows move to the form or profile; the self-reconciliation row becomes the override grant.
• domain-model.md → §7.1. BlindingPolicy input becomes the form or profile setting; add a HintPolicy; PrefillPolicy (RE2, reconciler workspace) is unchanged.
• domain-model.md → §7.2. Split AuthorityValue. Accepted results use AcceptedResultVersion.authority ∈ SingleAnnotator, HumanReconciled, Adjudicated, MergeResolved. Screening outcomes use ScreeningOutcome.finalSource ∈ ProfileRule, Adjudicated, MergeResolved plus RI's composition fields. candidateAgreement, reconciled, adminOverride, verified, imported and legacyUnknown leave the closed set (Imported survives only as a candidate provenance kind, RI §3.10). ReviewerAlias becomes context-local.
• versioning-model.md → §5.1. Profile settings that change outcome derivation are versioned (tie policy by owner decision; the others by RS classification). §9.7 gains the triggers and RS-R58.
• consistency-model.md → §8.4. Replace the 25 September paragraph (a replacement input makes the adjudication inapplicable and the outcome falls back) with RS-R58: the adjudication stays the current final facet, flagged, until explicit reconsideration. The §4.2 adjudication row keeps StaleBase for a submit against a superseded input vector before resolution.
• methodology-coverage.md → §3.1 (template table: tie policy explicit; extraction row "1 plus human reconciliation", no Verified gold), §3.2 (replace the Unsure rules with the §5.10 table), §3.3 (discussion fallback), §3.8 (blinding owned by form and profile with a blinded default), §4.4 and §5.8 (no Verified authority), §13.4 (configurable outdated mode).
• acceptance-criteria.md. Amend AC-R4a-05, 07, 08, 20, 28, 30, 31, 42, 44, 48, 49; replace AC-R4a-12; amend AC-R3b-13, AC-R3b-14, AC-R4p-04, 06, 08; add RS-AE rows.
• integrated-plan.md → §5.5 R3a and R3b, §5.6 R4a and R4p, §5.10. Stage-owned BL1, VS1 and expiry wording; target-one pilots; Q-29, Q-35, Q-36 and D4-03 statuses; R4p scope (assignment, discussion, triggers).
• decision-register.md and open-questions-and-assumptions.md. Record the statuses in §2.
• ux-strategy.md. Reconciler workspace hint labels, one-candidate layout, adjudication step in the step strip.
• review-form-owner-decisions-2026-10-02.md (owner ledger). Mark BL1 and VS1 as amended by Q-28, Q-30 and the blinding and hints amendments.

14. Superseded wording

Old wording	New wording	Where it appears today
"Target-1 forms create no task and no automatic gold"; "single reviewer, unreconciled"; optional "accept as gold"	Automatic SingleAnnotator result or one-candidate human reconciliation, configured on the form version (superseded wording 11)	contracts.md C9; domain-model.md §4.3; AC-R4a-31; integrated-plan.md §5.6 and §5.10
A Verification step producing Verified gold (D4-03 original)	The same reconciliation mechanism with one candidate and required human reconciliation (superseded wording 11)	contracts.md C9; domain-model.md §4.3 and §7.2; AC-R4a-49; methodology-coverage.md §3.1, §4.4, §5.8
Legacy reconciled answers readable as LegacyAuthorityUnknown, treated per Q-35	Removed; verify the no-records premise in the dry run (superseded wording 7)	contracts.md C9; AC-R4a-12; integrated-plan.md §5.6; domain-model.md §7.2
BL1 stage-owned; a task uses the most restrictive blinding of its stages; stable per-project aliases	Form or profile owns blinding; blinded by default; context-local random aliases (superseded wording 4)	Owner ledger BL1; contracts.md C6; domain-model.md §4.4, §7.1, §7.2; AC-R4a-30; methodology-coverage.md §2 and §3.8; integrated-plan.md §5.5, §5.6
"Candidates are always blinded; the stage chooses only the alias scheme"	Blinded by default, names visible by explicit form or profile choice	AC-R4a-48; methodology-coverage.md §3.8
VS1 step policy with a stage default (originally off)	Form baseline shows hints by default; step may only hide	Owner ledger VS1; contracts.md C6; AC-R4a-42; integrated-plan.md §5.5
Automatic prefilling of reconciled answers	Labelled hints, explicit click-to-fill, exposure recorded (superseded wording 6)	Earlier Q-28 wording in the register
Seven-day expiry for unstarted reconciliation assignments	Optional, admin-configured, off by default (superseded wording 13)	Original Q-30 recommendation; contracts.md C6; domain-model.md §4.4; integrated-plan.md §5.6
Outdated answers: non-blocking warning only, enforcement levels dropped	Configurable warn (default) or block	methodology-coverage.md §13.4
Profile rationale, Unsure and discussion settings live on the profile head with no impact flow	In the immutable profile version with Q-26 publication	versioning-model.md §5.1; domain-model.md §4.5; AC-R3b-05
Unsure rules "Unsure + Unsure and Include + Unsure need a third vote; Exclude + Unsure is a conflict"	The §5.10 table (Exclude + Unsure requests one more decision under extra review)	methodology-coverage.md §3.2
"No project setting permits self-reconciliation"	No self-reconciliation by default; explicit override grant	AC-R4a-28
Settings-only treatment of the standard form target	A target change is a new form version with publication impact (superseded wording 3; RD owns)	Earlier D2-05 proposal
A submitted replacement of an input decision makes an earlier adjudication inapplicable, and the outcome falls back to the candidate facet until re-adjudicated (25 September clarification, RECOVERED)	The adjudication stays the current final facet, flagged InputsChanged, until an eligible adjudicator explicitly reconsiders it; the actor is warned and affected authors informed (RS-R58; Q-27; O1 amendment)	consistency-model.md §8.4; earlier RS-R58 draft; AC ambiguity B1
An outcome authority list of CandidateAgreement, Reconciled, Adjudicated, Admin, Imported, LegacyUnknown	ScreeningOutcome.finalSource plus RI's composition fields; accepted results use the registry's four authority values	prisma-amendments.md §H; contracts.md C12; domain-model.md §7.2