Skip to content

Product-owner guide

A temporary planning guide for Chris, written on 5 October 2026 from the owner session of 4 and 5 October. It explains in plain English what the planned review engine will do for the people who use it. It adds no decision. Every statement comes from the owner-session consolidation or one of the nine specifications, which hold the detail and the traceability.

Feature implementation is on hold (your instruction, 5 October 2026). Three things stay separate throughout this guide:

  1. Planning approval. What you decided in the session. It shapes the plan.
  2. Brief approval and implementation authorisation. You approve each workstream brief, then authorise work gate by gate (D1-04). Both are on hold.
  3. Work started, gate passed, production enabled. None of these has happened. G0 is not approved and nothing has been built under this plan.

How to read it. The people and studies in the examples are illustrative. "Proposal" means a recommendation that the brief will carry for your approval; it is not yet approved. Section 16 lists the questions only you can answer. Section 18 says where everything stands today. Section 19 explains which earlier work the plan reuses.

1. The plan in one page

  • The Study stays the thing a project reviews. A Study is usually one paper. Forms, screening, reviewer targets and accepted answers all attach to a Study, and they are shared across every stage that uses them.
  • Each reviewer has one copy of their work per Study and form. It is the same whether they open it from one stage or another, in two browser tabs or on a phone.
  • Saving has three clear levels. SyRF keeps a draft automatically. Save progress makes a permanent checkpoint. Complete checks the whole form and counts the review.
  • Definitions change through published versions. Forms, questions and screening profiles are versioned. Changing how many reviewers a Study needs is also a new form version. Before anything is published, the admin sees exactly whose work is affected and how.
  • A stage works on the Studies its filter selects. The filter reads screening results and accepted answers. SyRF records every time a Study enters or leaves a stage, and why, so an admin can always explain what happened.
  • Results are never rewritten behind anyone's back. Accepted answers, adjudications and merged results are immutable versions. A change is shown before it is made, and a new version appears only when the person or rule entitled to create it does so.
  • Duplicates merge into one Study and can be unmerged. The originals are kept as history.
  • Every project moves to the new engine in the end. Pilots come first. Conversion keeps each project's behaviour and never invents history it did not record.
  • Everyone can work on a phone, a tablet or a desktop from launch, including very large forms.

2. What comes first, what comes later, what waits

The release names below come from each specification's §10. The rollout plan fixes their final placement.

2.1 Baseline (MVP)

These are part of the first usable engine for projects that have moved to it.

Area What people get Where specified
Forms and versions Versioned questions, forms and screening profiles; publication with an impact preview; a declared compatibility for each changed question; several people drafting at once with live presence RD
Targets The standard reviewer target inside each form version; per-Study overrides; requests for additional reviews on many Studies at once RD
Reviewing One shared session per reviewer per Study and form; "Draft auto-saved", "Version checkpoint saved" and "Complete" kept distinct; whole-form validation; form-owned inactivity timeouts RD; UX
Stages Stage filters on screening results; steps inside a stage; progression after a reviewer's own Include; exclusion-stop rules; finishing work already started; pool history and the admin explanation SP
Reconciliation Single annotator acceptance or a second-person check at a target of one; blinded, randomly ordered candidates; labelled hints with click-to-fill; configurable outdated-answer handling RS
Screening Unsure per profile; an explicit tie policy; adjudication assigned to a member or group; optional adjudication rationale RS
Duplicates Merge into one consolidated Study, conflict resolution and delegation, unmerge with explicit choices DM
Reporting Clear reporting units; PRISMA reports that freeze; counts from outside SyRF; versioned search documentation; protocol amendments; full-text retrieval actions; analysis-ready exports RI
Devices and discovery Full annotation on phones, tablets and desktops; the step selector; My work, a cross-project tab and a badge; refreshed legacy screens with compatible features UX
People and messages Named attribution after account deletion; contribution exclusion; reversible project deletion; the CAMARADES catalogue; permission-aware emails; per-project mute; notices that resolve themselves ACD
Conversion Faithful conversion of every project after trials and pilots, then a separately approved retirement of the old writers BC

2.2 Later opt-in beta and optional extras

Item What it is Default
Inference beta (the only beta) SyRF points out relationships between experimental groups, such as "pregnant animals are a subset of female animals" (§11) Off for every project; a project designer opts in after reading what it does
External and AI-model screening imports Importing AI-model-generated screening decisions and other external screening decisions (§10). A later lane after the first engine release, working name XS1 Off; enabled per project
Annotation-answer imports Importing answers from other tools. A later lane, working name XA1 Off
Reviewer-pool browsing A reviewer can browse the Studies available to them in a stage instead of only pressing Next Off per stage
Collective-Include setting A stage can make everyone wait for the team's Include before moving on Off
Bulk acceptance A reconciler accepts many agreeing Studies at once, after an explicit confirmation Off per form; delivered after the core reconciliation work
Screening discussion Reviewers whose decisions conflict may discuss before the tie rule applies Off per profile
Assignment expiry Unstarted reconciliation or adjudication assignments expire after a time the admin sets Off
Pilot timing data How long steps take, recorded only with the reviewer's consent and never with answers Off; per pilot
Training Training steps with reference answers, scoring, manual assessment, retries, admission to a project group and explicit promotion (TI). A planned lane after steps exist, working name TR1; the recommendation is that it does not gate the first engine release (rollout R-AMB-01) Used only where a project adds a training step

2.3 Deferred enhancements

  • Branching between steps on accepted answer values (D4-15). Stage filters on accepted answers stay in scope.
  • Grouping distinct reports, such as an abstract and its journal article, into one investigation (D4-08). Prepared links to several source documents are in scope.
  • A Progressive Web App, caching of allocated Studies and offline review. An exploration comes after the MVP, and no offline saving is authorised.
  • A full global landing page. My work and the badge come first.
  • Graph digitisation (decided after outcome-data pilots) and a full updated-review workflow.
  • Filter clauses on answers about individual groups of animals; hints for repeatable entities; wider inference reasoning; match-based scoring of repeatable entities in training.
  • Further catalogues with their own permissions.

2.4 Specialist decisions

Five scientific and statistical inputs need methodologists or statisticians before the parts that depend on them are built. Section 17 lists them.

3. Who sees and does what

3.1 Reviewer

  • Sees. My work, with what they can start or continue in each stage. One workspace per Study with a step selector across the top and one form below. A save status that says whether work is a draft, a checkpoint or complete. Accepted answers from earlier work shown as hints where the form allows it. A "Saved work" list for work they may still finish after a Study left the stage.
  • Does. Screens and annotates on any device. Uses "Use accepted answer" when they choose to copy a hint. Resolves a merge conflict if an admin delegates it to them. Takes training where a project requires it.
  • Never sees. Other reviewers' candidate decisions or answers, their names, or their submission times, while review is blinded. Advance warning that their decision will settle a team result, because that would reveal how others voted.

3.2 Reconciler

  • Sees. Studies ready for reconciliation, with candidates shown as "Reviewer A", "Reviewer B" and so on. The letters and order are drawn at random for each Study. A Study with one candidate when the form requires a second-person check. Clear labels when inputs changed after they started.
  • Does. Confirms or corrects answers and completes, which creates a new accepted result version in their name. May bulk-accept agreeing Studies if the form allows it, after confirming the exact list.
  • Never does. Reconciles a Study they reviewed themselves, unless an explicit override grant allows it and the result records that.

3.3 Adjudicator

  • Sees. Screening disagreements assigned to them or to their group, in an adjudication step that only eligible adjudicators see. The exact decisions in conflict, under the profile's blinding.
  • Does. Claims a task (only one person holds a task at a time) and records the decision, with a written rationale where the profile requires one. SyRF records them by name even when the task was assigned to a group.

3.4 Project admin

  • Sees. A preview before every change that affects people working now: who is affected, what is kept, what is released and who will be told. A "Why?" panel that explains, for any Study, why it was or was not reviewed in a stage. Pending changes waiting for their approval.
  • Does. Publishes forms and profiles, sets targets and overrides, and asks for additional reviews. Designs stages, filters and steps. Merges and unmerges duplicates. Excludes a member's contributions when needed. Deletes and restores projects. Runs the conversion wizard. Accepts imported AI-model runs. Sets up training.
  • Apply anyway. When a change conflicts with places that reviewers currently hold, such as lowering the maximum number of reviewers on a form, the admin can cancel or choose "Apply anyway". Apply anyway releases only those held places. Drafts and saved work stay. It never overrides permissions or an invalid set-up.

3.5 Methodologist

  • Sees. PRISMA reports that label each count with its unit (imported records, source documents, Studies) and say what is missing. Stage reports that separate Studies actually reviewed through a stage from Studies that merely sat in its pool. Agreement figures with human and machine sources kept apart. A methods summary with search documentation, protocol amendments and any automation tools used.
  • Does. Freezes reports, which never change afterwards. Records counts for steps done outside SyRF. Provides the specialist inputs in section 17.

4. Forms, versions, targets and overrides

4.1 Versions

A published form, question or screening profile never changes. Editing creates a draft. Publishing the draft creates a new version. Each review records which version it was written under.

When an admin publishes, SyRF first shows a preview: how many completed, saved and draft-only reviews are affected, under which earlier versions, and which reconciliations and accepted answers depend on them. The admin chooses how existing work is treated. SyRF checks again at the moment of publishing.

For each changed question, the publisher states whether the old answers still mean the same thing (the question is "compatible") and whether old options may be mapped to new ones. SyRF suggests an answer; the publisher decides. That statement never changes afterwards. A mistake is put right with a guided correction that publishes a new version.

Publishing may create new versions of reviewers' work that record the treatment the admin chose. Each one says it was created by that publication and names the admin. The reviewer stays the author of their answers. Drafts are always kept.

Several people can draft at once. Each sees who else is viewing or editing. Accepted changes appear in every open view without wiping anyone's unsaved typing. Only one publication per form runs at a time.

4.2 Example: raising the target from 2 to 3

The Risk of bias form needs 2 reviewers per Study. Study A already has two completed reviews, from Alice and Ben, and an accepted result that Dev reconciled. Priya changes the target to 3.

  1. It is a new form version. The target is part of the form, so the change is a publication even though no question changed.
  2. The preview. SyRF lists, for example, 140 Studies that drop below the new target, 60 of them with accepted results (Study A among them), and the one Study that has its own target.
  3. The choice for accepted results. The default keeps them accepted and labels them "below current target (accepted under target 2)". A proposed alternative suspends them until they are reconciled with three reviewers; anything that relies on accepted answers, such as stage filters and hints, then treats those Studies as having none.
  4. Studies with their own target. Priya must choose for each one: keep its number, adjust it or remove it so it follows the new standard. Nothing changes silently.
  5. What happens to Study A. Alice's and Ben's reviews still count. Nobody's review is changed and no review is invented. Study A now waits for one more reviewer: "Waiting for 1 more qualifying review (2 of 3)". When Carmen completes the third review, Dev reconciles all three, and SyRF writes a new accepted result version that records target 3. The old result stays in history.
  6. Stages. A stage that completes automatically shows remaining work again. A stage that was completed by hand stays completed until someone reopens it.

4.3 Example: lowering the target to 1

If Priya lowers a form's target from 2 to 1 and the form accepts single reviews automatically, she chooses whether Studies with exactly one completed review get an accepted result now or at their next completion. Each result says it came from that publication and names Priya. Studies with two reviews still need a human reconciler, even when the two agree. Automatic acceptance of agreeing reviewers has not been approved.

4.4 One Study, or many Studies

  • One Study. Priya sets Study B's target to 4 because it is a key paper. That writes a new version of Study B's own target. It does not create a new form version. Project statistics still show "Target: 3 reviewers per study", with "1 study has a study-specific target" listed separately.
  • Many Studies. Dev selects 40 Studies with a disagreement and asks for one more review on each, assigned to the group "Senior extractors". Each Study's target rises by one and the request is recorded. A group member who already reviewed one of those Studies cannot count twice there. Each member gets one notice listing their Studies. Nothing is accepted automatically.
  • Target versus maximum. The target is a minimum. A cap on how many people may work on a Study at once is a different setting. The proposal keeps it off by default and never below the Study's target.

5. Drafts, checkpoints and completion

5.1 Three levels

Status (words may change) What it means Does it count?
Draft auto-saved SyRF has safely kept your latest edits. It sends only what changed. You can come back to it No. Nobody else sees it
Version checkpoint saved You pressed Save progress. A permanent copy now exists. It may be incomplete No, not as a completed review
Complete SyRF checked every required answer across the whole form, including questions not on screen, and accepted the review Yes, once per reviewer per Study and form

You approved the distinction. The exact words may change after testing; the three meanings may not.

5.2 One session everywhere

Alice opens Study S-101 on the Risk of bias form from the Full text stage on her laptop. Later she opens it from the Extraction stage in another tab, then on her phone on the train. It is the same session, the same draft and one reserved place. If she edits the same answer in two tabs at once, SyRF keeps both values and asks her to choose. Nothing is lost silently.

5.3 Saving incomplete after completing

If Alice reopens a completed review and presses Save progress, SyRF warns her first: her review will stop counting as complete, and a reconciliation in progress uses it and will need re-checking. If she confirms, Dev, the reconciler, gets one notice. His work and any accepted answers are not changed.

5.4 Places and timeouts

The form decides how long an idle session keeps its place and how many Studies a reviewer may have in progress. One idle tab never releases the place while another tab is active. When the place is released, the draft stays. On return, SyRF checks again whether a place is free and says so honestly.

6. How a Study enters and leaves a stage pool

6.1 The filter decides the pool

Each stage has a filter. It reads the team's screening results and accepted answers, combined with AND and OR. For example, the Full text stage might use "title and abstract result is Included AND full-text result is not Excluded". A Rodent synthesis stage might add "accepted species is rat or mouse". There is no separate gate into a stage.

Being in a stage's pool does not mean work is needed. Allocation, available places, step rules and reviews already done decide what is offered. A Study can sit in a pool with nothing left to do, for example because its form already has enough reviews from another stage. SyRF never repeats work that is already sufficient, and never invents a review to explain why nothing was asked.

6.2 Steps inside a stage

A stage holds steps. A step can be screening, annotation or both. A step can depend on earlier steps.

  • By default a reviewer moves on after their own Include while the team's result is still pending.
  • A stage setting can make everyone wait for the team's Include instead.
  • A separate exclusion-stop setting says whether an Exclude stops further work. When the team result becomes Excluded, new work stops in the steps that setting covers.

6.3 Example: a result that makes its own Study leave

Okafor 2021 is in the Full text stage. Chandra included it and started extracting outcomes. Alice and Bob then both exclude it at full text.

  1. SyRF saves Bob's decision. It is never rejected because of its effect.
  2. The full-text result becomes Excluded, so Okafor 2021 no longer matches the stage filter.
  3. SyRF records the departure, naming Bob's decision as the cause and the condition that failed.
  4. Nobody is offered new work on Okafor 2021 in that stage.
  5. Chandra sees it under Saved work: "No longer in the Full text stage. You can finish your saved work." By default she may finish. An admin can restrict this; her draft is kept either way.
  6. PRISMA reports Okafor 2021 as excluded at full text. Chandra's extraction is kept as evidence.

6.4 Why the admin can always see the reason

You asked that an admin can always explain why a Study was available, reviewed, not reviewed or no longer available, without assuming the platform failed. SyRF therefore records:

  • each time a Study enters or leaves a stage pool, with the filter version, which conditions passed or failed, what change caused it, who or what caused it, and when;
  • why each reviewer was allowed to start, through which stage and step, and on what basis they finished.

The "Why?" panel turns this into plain sentences, using the settings in force at the time. For example: "4 Oct 16:05: left Full text. Full-text team result became Excluded (Bob's decision)." or "6 Oct 10:22: Chandra completed Outcomes. Allowed as work started before the Study left the pool."

It is honest about gaps. Where a Study was eligible and nobody reviewed it, it says "No review is recorded" and suggests no reason. Where tracking started late, it says so, for example "Pool history before 20 September 2026 is not recorded; this project was converted then". It does not log every page view, so it cannot show that "no place was free" at some past moment, and it says that too.

For reports, the priority is the Studies actually reviewed through a stage. Pool history is kept for audit. Leaving a pool because a filter stopped matching is never reported as a screening exclusion.

7. Merging and unmerging duplicates

7.1 A merge in practice

Lee 2021 was imported twice, as S-204 from PubMed and S-377 from Embase. Alice reviewed both copies and gave different answers.

  1. Preview. Priya opens the duplicate. SyRF shows the evidence on both copies, the conflicts (Alice included one copy and excluded the other), different targets, a suggested bibliography and active work, such as Carmen's draft on S-377.
  2. Resolve or delegate. Agreeing answers are filled in already. Priya can choose between Alice's answers herself or hand the choice to Alice. She delegates. Alice gets a My work item naming the merge and both of her submissions, side by side. SyRF records who actually made each choice.
  3. Confirm. Priya confirms the resulting target and the bibliography, field by field.
  4. Commit. SyRF checks nothing changed since the preview. If Ben saved a correction meanwhile, the commit stops and the preview refreshes. Otherwise, in one step, a new consolidated Study S-512 becomes current and S-204 and S-377 become history. Either all of it happens or none of it.
  5. After. Reviewers and the reconciler get one notice each. Anyone who opens S-204 sees "Merged into S-512" and can continue there; Carmen applies her kept draft to S-512 explicitly.

The originals are not edited. They stop being listed, offered or counted, and they stay readable in history and as-of exports.

7.2 Unmerging

Two weeks later Priya learns that S-377 was really the conference abstract, which the protocol keeps as a separate Study. She unmerges S-512. For every item created on S-512 since the merge she chooses "move to S-204", "move to S-377" or "leave in the merged history". SyRF never copies an item to both. It warns her about accepted results built from both originals; those stay readable and a new result is created only if someone reconsiders. The merge itself stays on record.

7.3 Bibliography and distinct reports

A Study with one reference shows that reference's details and says where they came from. A Study-level value can be picked from any linked reference or typed in. Each field records its source, who chose it and when. References themselves never change.

A conference abstract and a later article are distinct reports, not duplicates. The admin marks them "Distinct report"; both stay current and are not merged. Grouping them into one investigation is deferred.

8. Reconciliation, hints and blinding

8.1 When a form needs one reviewer

Each form version chooses one of two behaviours for Studies whose target is one:

  • Accept automatically. The single completed review becomes the accepted result at once. It is labelled "Single annotator (accepted automatically)" and is never called reconciled, verified or checked.
  • Require a human check. A second person opens the normal reconciliation screen with one candidate, confirms or corrects, and completes. This is how "one extracts, one checks" works. There is no separate verification engine.

Which of the two is the default for new forms is in section 16.

8.2 Two or more reviewers

A human reconciler always produces the result. Agreement alone never creates one. Bulk acceptance, where a form turns it on, still needs the reconciler to confirm the exact list, and each result names them.

A blank answer means "not assessed". It is not a disagreement and it does not block reconciliation. "Unknown" and "Not reported" are real answers and are compared like any other.

8.3 Blinding

Reconciliation is blinded by default. The form owns this setting for annotation; the screening profile owns it for screening. Stages cannot change it. Candidates appear as "Reviewer A", "Reviewer B" and so on, drawn at random for each Study, so "Reviewer A" on one Study has nothing to do with "Reviewer A" on the next. Dates, times and other clues are hidden. Real names stay in protected history for people allowed to see them.

8.4 Hints and click-to-fill

When a Study already has an accepted answer to a question, a reviewer sees it as a labelled hint, for example "Accepted answer: Rat". The answer box stays empty until the reviewer clicks "Use accepted answer". SyRF records that the hint was shown and that it was copied. A copied answer still counts towards the target, but it never counts as independent evidence in agreement figures. A form can turn hints off. A step can hide them; it can never show hints the form turned off.

8.5 Outdated answers

When a reviewer's own change leaves another answer out of date, the form warns them and by default still lets them complete. A form can instead require the flagged answers to be fixed first. Neither setting bypasses validation or a re-answer that a publication made mandatory.

9. Unsure, ties and adjudication

9.1 Unsure

Each screening profile decides whether reviewers may answer Unsure. It is on in the proposed title and abstract template. Unsure keeps a Study available, so it is never an exclusion. It also never counts as a definite Include.

9.2 What happens with mixed decisions

The table uses your example: two agreeing decisions needed, one extra review allowed, then adjudication.

Decisions so far (any order) Result
Include, Include Included
Exclude, Exclude Excluded
Include, Exclude One more decision is requested, or the Study goes straight to adjudication if the profile chose that
Include, Unsure One more decision is requested
Include, Unsure, Include Included
Include, Unsure, Exclude Adjudication
Include, Unsure, Unsure Adjudication
Unsure, Unsure, Unsure Still to specify (section 16)

The order of decisions never changes the result. The brief completes the full table and tests every row.

9.3 Ties and adjudication

Every profile must state its tie rule: ask one more reviewer up to a stated limit, or send ties straight to adjudication. SyRF picks no default; templates preselect one visibly.

Adjudication work goes to a named member or a project group. Any eligible group member can claim it, and SyRF records who resolved it. Someone who screened the Study cannot adjudicate it unless an explicit override grant allows it. A profile can require a written rationale; this is off by default. While adjudication is pending, the Study has no definite result: a step that waits for the team's Include keeps waiting, and no exclusion-stop applies.

If someone later corrects a decision that an adjudication relied on, the adjudicated result stays in place, flagged "inputs changed". The adjudicator is told. Nothing changes until an adjudicator reconsiders.

9.4 Discussion

A profile can let reviewers whose submitted decisions conflict discuss the Study before the tie rule applies. Their first decisions are kept for agreement figures. If they cannot agree, the tie rule applies.

10. AI-model-generated screening decisions

This is a later, opt-in import lane. No importer is switched on by your planning approval.

Example. Ravi trains the team's classifier outside SyRF on 600 Studies that Tom and Mei screened.

  1. Describe the model. Ravi records "StrokeScreen classifier" version 1 in the project: provider, version, what it is for, its labels and how each maps to Include, Exclude or Unsure, the thresholds the team uses, and the 600 Studies it was trained on. Anything not supplied is marked as such.
  2. Say how it counts. Priya publishes a screening profile version that lets the model count as one contributing vote. The alternative is "sole screener". The proposal treats this as a change of selection method, so SyRF asks for a protocol amendment entry.
  3. Import. Ravi uploads a run for 4,000 Studies. The preview lists matched rows, rows SyRF could not match (reported, never turned into new Studies) and the 600 outputs on the model's own training Studies, which by default do not count (proposal).
  4. Accept. Priya reviews the impact and accepts. Each Study now holds one AI-model-generated screening decision. When Tom agrees with the AI screening model's Include on a Study, two agreeing decisions make it Included, labelled as machine-assisted.
  5. Disagreement. Where Mei and the model disagree, the profile's tie rule applies. The adjudicator sees the AI-model-generated screening decision with its label and confidence. That decision itself never changes.
  6. Rerun. If Ravi retrains and reruns the model, its new outputs replace its old ones as new versions. The model is still one voter, never two.

Rules that always apply. The model is a recorded source, separate from the person who imported its output. It never has a login or permissions. Under "sole screener", a model Unsure goes to a human adjudicator. Reports, exports and agreement figures always show which results involved a machine. The words are "AI-model-generated screening decision" and "AI screening model"; other external tools keep their real type.

11. Training, and the inference beta

11.1 Training

Tom Liu joins the stroke review with access to the Training stage only.

  1. He screens 20 practice Studies whose expected answers Aisha, the designer, wrote down.
  2. He scores 72%. The policy needs 80% and allows one retry with approval. He sees which items were wrong, without the expected answers.
  3. Aisha approves a retry. Tom scores 90%, but one free-text answer needs a person. Ewan marks it correct.
  4. SyRF adds Tom to the "Screeners" group, whose existing permissions let him screen for real. The record shows the attempt, the assessment, the policy version and who caused it.

Practice answers never count as votes, never fill a target, never become accepted answers and never appear in PRISMA. Passing gives only the named group membership. Turning practice work into real evidence is a separate action an admin takes on purpose.

11.2 The inference beta

Some forms record groups of animals and how they relate. With project rules such as "Pregnant is contained in Female", SyRF can point out relationships a reviewer did not state, contradictions, and totals it can prove. It understands four kinds of statement only: all of these together, this group inside that group, these groups share no members, and these groups together cover everything.

  • It is off for every project until a project designer turns it on. Templates, copies and conversion never turn it on.
  • It works from one reviewer's own answers, shown only to them, or from a Study's accepted answers. It never mixes two reviewers' unreconciled answers.
  • It never changes an answer and never invents an animal count.
  • When answers or rules change, it recalculates and keeps the old conclusion in history.

12. Moving every project to the new engine

12.1 The order

  1. Trials in staging on seeded and synthetic projects.
  2. Production pilots with projects whose owners opt in. Each pilot needs your approval.
  3. Every remaining project, including completed and inactive ones, in scheduled waves once the pilots prove the converted projects behave the same. You approve each wave.
  4. Retiring the old writers, as its own milestone that you approve separately.

12.2 What conversion does

Conversion copies a project's set-up and review data into the new structures so that it behaves exactly as before: the same Studies offered to the same people, the same answers and decisions, the same exports and the same access. It is not a redesign and adds no new rule.

A wizard shows the admin how each old stage maps to new steps, forms and screening profiles, what is created and what is reused. Where two old stages would share one form and a reviewer worked in both, the wizard shows both of that reviewer's answers so they are resolved and counted once.

Later, inside the new engine, an admin can rearrange a converted project with a separate redesign wizard. That is an ordinary publication with previews.

12.3 What "not recorded in legacy" means

Old SyRF did not record everything the new engine records. SyRF never fills the gap with invented history. It labels it instead.

Label (plain meaning) Example
Not recorded in legacy: old SyRF never captured this kind of fact Earlier saves of a review; pool history before conversion
Current snapshot only: only the latest value survived A screening decision changed twice in old SyRF
Unknown author, time or question wording: the record exists but this detail is missing An answer whose reviewer ID no longer resolves
Value or default unknown: the stored value may be an untouched default "Zero animals" that nobody may have entered
Legacy completion unvalidated: old SyRF marked it complete without checking every required answer Any old completed session. It still counts as completed by default, as it did before (proposal)

These labels never mean "Unknown" or "Not reported", which are real answers a reviewer gave.

12.4 Safety

  • Blocked projects wait. A project that cannot be converted faithfully is set aside with the blocker and a remedy recorded. Its data is kept and it keeps working as before. It is never forced through by dropping data.
  • The largest project is a test case. Francesca's project with about 2,023 questions is never excluded for size. If it fails a speed check, the remedy is performance work.
  • Undo before first use. Until somebody saves new work in the converted project or changes its set-up, it can be switched back with nothing lost. After that, fixes move forward inside the new engine.
  • No reconciliation records are expected. You said reconciliation was never fully built. Every dry run (a rehearsal that changes nothing) checks this. If a project has such records, its conversion stops and the question comes to you.
  • Single-reviewer forms convert with no accepted results (proposal; section 16).

13. Phones, tablets and desktops

  • Full work on every device from launch. Screening and full annotation, including the largest forms, work on phones, tablets and desktops. Layouts differ; no feature disappears because the screen is small.
  • Large forms stay fast. Only part of the form is on screen at once, autosave sends only changes, and Complete checks the whole form. "3 required answers missing · Jump to next" takes the reviewer to the right question even if it was never on screen.
  • Losing signal. The status says "Offline. Your latest edits are held until you reconnect." How edits are held on the device during a short break is a question for the UX brief, because it stores answers on the device.
  • Older projects get the refreshed look, the new navigation, dark mode, phone layouts and My work before they convert. Their review workflow does not change until conversion.
  • Finding work without email. My work, a cross-project tab and a badge in the top bar count what each person can act on, even with all email muted.
  • App installation (a Progressive Web App) is explored after the MVP. Today's mobile metadata does not make SyRF installable.

14. Email, leaving and deletion

14.1 Leaving a project or SyRF

  • Deleting a SyRF account stops sign-in. Submitted work keeps the person's name and keeps counting.
  • Disabling someone's project membership removes their access. Their submitted work still counts.
  • Reviewers cannot take back submitted work by leaving. Joining a project explains this, once the wording has had legal review.

14.2 Excluding contributions

An admin can deliberately take one member's contributions out of current use, for one form, one screening profile, one stage or the whole project. For example, Omar learns that Sam extracted outcomes without the required training. He excludes Sam's work on the Outcome extraction form with a reason. The preview shows that 14 Studies drop below target and 3 accepted results used Sam's input. After confirming, those 14 Studies need more reviews. The 3 accepted results stay, flagged, and their authors are told. Sam's work stays in history with his name.

14.3 Deleting a project

Ordinary deletion can be undone. The project disappears from lists, review and editing stop, allocations and notices stop and held places are released. Drafts, data and history are kept. An authorised admin restores it from a restricted "Deleted projects" view. Restoration checks places again and does not bring back old reservations. Permanent erasure is a separate policy that you have not approved.

14.4 Emails and notices

  • Emails may include the project name and Study titles.
  • Answers and free text are configurable per project. The proposal keeps them off by default, because a sent email cannot be recalled.
  • Every email is checked against the recipient's current access and the blinding rules when it is sent. Under blinded reconciliation, an email to the reconciler uses the same "Reviewer B" label they see in SyRF, never a name.
  • A person can mute email for one project and still see its notices in SyRF.
  • When the work a notice is about is done, the notice marks itself resolved and leaves the unread count.
  • Reconciliation conversations are kept as permissioned audit records, outside answer exports and agreement figures.
  • Notifications are switched on only with your approval per environment and type, pilot projects first, with test email kept in a test mailbox and an operator pause switch.

14.5 The catalogue

There is one CAMARADES catalogue of templates, run by users with a system permission. Using a template copies it into the project with a record of where it came from. Later edits on either side never overwrite the copy. Anyone else can ask for something to be added.

15. What has not been approved

  • Implementation of any kind, migrations, production activation, notification delivery, closing unrelated or dormant pull requests, messaging the design session and building a new prototype.
  • Permanent physical erasure of data (T-POL-01).
  • A separate identity-erasure process (T-POL-02). No wording in the plan claims legal sufficiency.
  • Automatic acceptance of several agreeing reviewers (T-POL-03). Bulk acceptance needs the reconciler's explicit confirmation.
  • Every proposed number. For example: publication pause and operation limits (D2-10); the deduplication targets of F1 at least 0.99 and 80,000 citations in under an hour (D4-21), which are neither approved nor achieved; Unsure thresholds beyond your stated example; the capacity cap and timeout defaults; presence and badge refresh times; telemetry retention.
  • Exact PRISMA box mapping, statistical methods and scientific event definitions. These need specialists (section 17).
  • Each conversion pilot, each wave and the retirement of the old writers. Each needs its own approval. Approving the plan approves none of them.
  • Any importer. Each import lane needs its own brief, gate and flag.
  • Offline saving and caching of allocated Studies on devices. No offline writes are authorised. Whether unsent edits may be held on the device during a short connection loss is a UX brief question.
  • Production recovery from a backup, which needs your authorisation for each incident.

16. What you still need to decide

16.1 The one open owner decision

ID Plain question Recommendation
D2-09 (T-OI-01) Two forms share a question, such as "Species". The first form's reconciler has accepted an answer. What may the second form's reconciler do? They see it as accepted and may revise it, which writes a new accepted version recording who changed what. The alternative is "first publisher wins; others raise a query". Until you answer, pilots avoid forms that share reconciled questions (RD §4.14)

16.2 Gates

Item What it is Recommendation
G0 approval (T-G0) Your approval of the plan and its operating model, set out in the G0 dossier. Passing G0 allows the rows listed there to be built and merged in a switched-off state. It never covers production. Nothing starts while the hold stands Approve when you are satisfied with the dossier
G0-D1 Your D4-18 answer was "independent of funders". The recorded reading is that the plan maps the NC3Rs and SSI RSMF deliverables itself, does not wait for the funders, and keeps an independent accessibility audit (WCAG 2.1 AA) at GA (AC-GA-08). Is that reading right? Confirm
G0-D4 to G0-D10 Who closes or keeps the listed older pull requests, and when. No closure is authorised until you approve As the dossier recommends; section 19 adds the harvest map's three related questions
Hold lift (T-HOLD) Lifting the implementation hold you set on 5 October Your call; nothing starts before it

G0-D2 (staging seeds) and G0-D3 (Firefox, WebKit and touch coverage) were settled in the session as D3-14 and D3-15.

16.3 Confirmations the specifications reserve for you

Each has a recommendation. They mostly fill gaps your decisions left open.

# Plain question Recommendation Where
1 Which target-one behaviour is the default for new forms? Accept automatically, shown visibly in templates RS §12
2 How should converted single-reviewer forms behave? Old SyRF never accepted their answers Convert with no accepted results and no new reconciliation work, labelled "single annotator, not accepted". Admins can switch later through a normal publication RS §12; BC §12.4 A1
3 What does "explicit override grants" (Q-36) mean? A named person may reconcile or adjudicate work they also reviewed, recorded on the result and in the methods summary RS §12
4 Does a reviewer's own Unsure let them move to the next step, as their own Include does? Yes, but it never counts as the team's Include RS §12 (replaces SP-AMB-04)
5 When the only reviewer of a target-one form corrects and completes again, may the automatic rule accept the new version? Yes; the earlier result stays in history RS §12
6 Today's screening annotations keep exclusion reasons only as far as reviewers agree (FEAT-009). Is that a screening-profile rule, or a form of the unapproved automatic acceptance? A profile rule, but only for screening decisions and the must-agree reasons the profile names; anything else goes to reconciliation RS §12
7 Do you want the "suspend" option for results below a raised target, beside the default "keep accepted"? Offer both, with "keep accepted" as the default RS §12; RD §4.9
8 What happens when every decision is Unsure? Adjudication by default. A collective "Unsure (not excluded)" result only as a per-profile option if you approve it RS §5.10
9 Where does the setting live that restricts finishing work after a Study leaves a stage? You said it must not be guessed A stage default with a step-level option that can only restrict, shown together with the saved-work setting as "Finishing work already started" SP §12.4 (SP-AMB-01)
10 When a new standard target is published, what happens to Studies with their own target? You asked for an explicit rule Each override gets an explicit choice (keep, adjust or remove). The suggested default keeps every Study's number unchanged and flags overrides that become redundant or fall below the new standard RD §12 (RD-R16)
11 What feedback do trainees see? Which items were right or wrong after assessment; the expected answers only after a pass or when no retry remains TI §12
12 May a live step require "passed this training step", in addition to group admission? The specification offers it as an optional extra; group admission stays the approved gate TI §12
13 Does the inference beta also gate explicit recording of experimental groups? No. The beta covers rules and inference; explicit recording follows its own enablement, so ordinary annotation stays usable TI §12
14 May admins still copy a definition from one of their projects to another outside the catalogue? Yes, with the same provenance record ACD §12.5 B5
15 Who carries out the legal review of the joining terms and account-deletion wording? You route it; it is required before release ACD §12.3

16.4 Approved with each brief, not individually

Every specification resolves its other ambiguities with a recommendation and lists proposals an owner may want to see. You approve these with each brief, not one by one. Two are worth a look when their briefs arrive: holding edits on the device during a connection loss (UX §12 A1), because it stores answers on the device, and the scope of your own wave approvals during conversion (BC §12.4 A3). The lists are in each specification's §12.

17. What is waiting for specialists

Row Input needed What waits for it
T-SI-01 (Q-17) A field-level specification for event-count outcome data, including what "variation" means, from you or CAMARADES methodologists The event-count outcome schema
T-SI-02 (Q-16, D4-12) Agreement methods: denominators, percent agreement, prevalence, use of first independent decisions, screening agreement per profile, statistical review of multi-rater formulas, and how machine sources, Unsure, copied hints and discussion are treated Multi-rater agreement figures; percent agreement with clear denominators can come first
T-SI-03 (D4-06) Methodologist checking of the SYRCLE, CAMARADES and ARRIVE Essential 10 templates and when each applies Publishing those templates in the catalogue
T-SI-04 (D4-21) The method and thresholds for proving that SyRF's own ASySD deduplication matches the reference version, and how fast it must be The deduplication release decision
T-SI-05 Which PRISMA boxes use actual review through a stage and which use pool history; how merged Studies, AI sole-screener exclusions, Unsure, pending adjudication and pre-conversion gaps appear The PRISMA reporting release

Methodologists are also asked, inside the briefs, for the exclusion-reason template text and for guidance on choosing practice Studies for training.

18. Where this sits today

  • Implementation is on hold (your instruction, 5 October 2026).
  • G0 is not approved. The G0 dossier awaits you.
  • Nothing has been built under this plan. No migration, production change, notification delivery or pull-request closure has happened.
  • Every work item is at most "Brief drafted". None is "Brief approved". No gate has passed and nothing is enabled in production.
Work status Today
Planning approved Your session decisions
Brief drafted The nine specifications and the design-prototype handoff
Brief approved None
Implementation authorised None
In progress, merged dark (merged but switched off), gate passed, production enabled None

The decision count, with its scope. Before the session the package had 89 open owner decisions. Now 63 are resolved, replaced, removed or deferred, 25 are alignment, brief or validation entries that the briefs settle, and 1 is still open (D2-09). The session's own register of 74 entries holds 52 resolved, replaced, removed or deferred entries and 22 alignment, brief or validation entries. Thirty further agreed requirements sit outside these counts as amendments OS-A01 to OS-A30. The full reconciliation is in the owner-session integration.

A related caveat. Production readiness of the materialised project statistics stays provisional: its latency gate failed on 3 October (#3510), and any production date is a target, not a commitment.

Next options. Answer D2-09 and the confirmations in section 16; approve G0 with G0-D1; route the specialist inputs in section 17; lift the hold when you choose. Each is independent of the others.

19. Reusing earlier work

The plan does not start from scratch. Several open pull requests already hold work on questions, forms, imports and groups. Five read-only reviews on 5 October checked each one against what you decided in the session, and the harvest map records what to keep and where it goes. Nothing has been copied, changed or closed yet. That waits for G0 and for you to lift the hold, and then happens release by release.

What is reused.

  • From QM v2 (#2572 to #2575, and the #2461 umbrella they came from): ideas, test cases and several building blocks. Examples are how an answer's type is checked, how the built-in system questions are defined, how a publication works out whose work is affected, the check that stops a publish when the impact changed after the admin looked, the message a reviewer sees after a form changes, and the conversion tools that compare old and new data. Almost all of it is rewritten to fit the new model rather than copied.
  • From #2224 (custom project groups, by nurikarakaya, who has left): how groups are created and deleted, the rules behind that, and its tests. They return in R1c, when admins can create and manage their own groups, with the agreed safeguards added. Three small fixes go into the Members & groups page in R1b, and its screens serve as design input.
  • From the import work (#3934 and #2781): most of #3934, which reads a template file safely, shows a preview, and adds the questions all at once or not at all. It becomes R1a's import. The sample file from #2781 becomes a test.

What is deliberately not reused, and why.

  • The old migration. It would have deleted each project's original review data after copying it, and its undo would have rebuilt the old data imperfectly. It never ran: nothing called it, and it never merged. You decided that conversion never touches the originals and that undo only works before anyone uses the converted project.
  • Question lists per stage, and stage "transitions". In the new plan a stage picks its Studies with its filter and uses whole forms. Forms, not stages, own the questions, the target and the reviewers' work.
  • Single-copy drafts. The old designer kept one editable draft that the last save overwrote. You asked for drafts that several people can work on, with every change recorded.
  • Publishing that wiped answers or rewrote them. A changed question now keeps the reviewer's earlier answer and marks it as needing an update, and mapping old options to new ones keeps the original answer.
  • Group shortcuts. #2224 stored groups in the old membership format and let administrators hand out permissions by default. Groups wait for the new format, and handing out permissions stays with the owner.
  • Things SyRF has since built another way, such as the new annotation form, live reviewer presence and the current question editor's locks.

The pull requests stay open until the work taken from each has been merged in its own release. Until then they stay as they are, untouched. GitHub also keeps a closed pull request's code, so closing one later loses nothing.

Closing them is a later decision for you (G0-D4 to G0-D7 in the G0 dossier). The map drafts a closing note for each, including thanks to nurikarakaya for #2224, and says when each could close. It asks you three questions (harvest map §10): whether #2986 stays open outside the programme for a corrected reason, who closes #3934, #2781 and #2387, which no G0 item covers, and whether #2224 closes in W0 or after R1c.