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. Section 20 explains the new question management and its five open questions. Section 21, added on 6 October 2026, explains your answers of that day, including the design-handoff answers from your Codex discussion, and what they left open.

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
Answers (added 6 October 2026) New questions are required by default; making one optional is an advanced, discouraged setting. A reviewer who cannot give a value says so by choosing a reason no value is provided, such as "Not reported" or "Unable to assess" (your wording of 6 October 2026, DQ-46; it replaces the working name "no-value answer"). Designers choose those reasons per question, add their own or copy sets from catalogue templates such as SYRCLE, and choose which comments, units, quotes and other notes each kind of answer allows or needs. Complete waits until every applicable required question has an answer; saving progress never does (§21) RD §3.16

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). Writing and publishing the project rules it uses also needs the beta; recording groups explicitly does not (your answer of 6 October 2026, DQ-09) 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. You decided on 6 October 2026 that training does not gate the first general release ("No, training does not gate GA"); it stays planned. Guidance for trainees to read before an attempt is proposed (§11.1) 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.

6 October 2026. You decided that what Tom sees in step 2 is the default: right or wrong per item after assessment, and the expected answers only after a pass or when no retry remains. You also asked whether trainees get guidance to read first. The proposal (not yet approved): Aisha can attach a guide (text, links or files) to the training step; Tom reads it before he starts, ticks "I have read this" if the policy asks, and may keep it open during the attempt if the policy allows. Training does not hold up the first general release.

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.
  • 6 October 2026 (your answer, DQ-09). Writing and publishing project rules also needs the beta, as do evaluating them and showing what they infer. Ordinary annotation, and recording groups of animals explicitly (§11.3), never need it.

11.3 Recording groups of animals, and questions that point at records (lane C1)

Added on 6 October 2026 from the classification, populations and references specification. It is planned, after the first engine release, and none of it is approved for building.

  • Groups, written down explicitly. A reviewer records the groups a paper reports ("Farm A, 70 animals"), how they relate ("these share no animals", "together they cover all 120"), with a quote and page for each statement. SyRF never adds groups up: no screen or export will ever show 240 for two ways of splitting the same 120 animals.
  • Every Study starts with one population, "all the animals it studies", which has no number unless the paper gives one. A paper with two unrelated sets of animals can have two.
  • Category tabs become entity types. A project can add its own, such as "Location".
  • Questions that point at records. Today five built-in questions point at other records (for example a cohort's treatments). A designer could make their own, such as "Housing location" on a cohort, pointing at Location records. The answer stores the record itself, so renaming the record never breaks the answer. The recommendation is that these arrive with lane C1 and do not hold up the first general release; you have not decided (§21).
  • Nothing is inferred here. Suggestions come only from the opt-in inference beta (§11.2), and none of this recording needs the beta (your answer of 6 October 2026, DQ-09).

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.
  • Reconciliation and design screens on phones (your answer of 6 October 2026, DQ-04). They get layouts that work on a phone with every feature, but they do not have to pass a formal phone test before release. Screening and annotation still do.
  • 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

The question-management integration of 5 October (evening) adds five questions outside the session's counts, QMI-01 to QMI-05. They are explained in plain terms in section 20.5. Your answers of 6 October 2026 settled confirmation 11 below and the rollout question whether training gates the first general release (R-AMB-01). Your design-handoff answers later that day settled confirmation 13 (the inference beta) and answered QMI-04 in part. Section 21 lists what is still open.

16.1 The last open owner decision (answered)

You answered this on the status page on 5 October 2026, so no owner decision remains open (decision register §1.16).

ID Plain question Your answer
D2-09 (T-OI-01, Decided) 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? Agreed with the recommendation, with your additions. They see the accepted answer as a labelled hint they can click to use (never filled in for them) and may revise it in their own final submission, which writes a new accepted version recording who changed what. They are prompted for a reason, but it is optional. They can also raise a query on the accepted answer if needed (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 and G0-D7 to G0-D10 Who closes or keeps the remaining older pull requests, and when. No closure is authorised until you approve As the dossier recommends
G0-D5, G0-D6, G0-D12 (answered) You answered the harvest map's three questions on 5 October (section 19) Nothing to do now; nothing closes until each harvest has merged
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. You answered "as recommended" on 6 October 2026 TI §12
12 May a live step require "passed this training step", in addition to group admission? Group admission stays the only access gate, through the group's existing permissions; no extra step, profile or form gates; re-qualification could come later. You were unsure on 6 October 2026, so it stays open (DQ-32) TI §12
13 What does the inference beta cover? Your S5 amendment says the "advanced classification/rule/inference capability" starts in beta Writing project rules, evaluating them and the results, but not explicit recording of experimental groups, which has its own setting, so ordinary annotation stays usable. You decided this on 6 October 2026 (DQ-09): the record says you found the recommendation made sense: only rule-writing and inference require the beta. The classification specification's alternative, writing rules in lane C1 outside the beta, is not adopted TI §12; CPR §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 64 are resolved, replaced, removed or deferred, 25 are alignment, brief or validation entries that the briefs settle, and none is open: the session left D2-09 open, and you answered it on 5 October. 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 the confirmations in section 16 (D2-09 is answered); approve G0 with G0-D1; route the specialist inputs in section 17; lift the hold when you choose. Each is independent of the others. The design pack waits for you: it is ready to send only after the integration of your 6 October answers is checked and merged (§21.1), and sending it is your own step (T-DH-01). Approving #2986's wiring fix as a legacy-integrity fix is a separate, optional decision (section 19).

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 needs your decision on each (G0-D4 to G0-D7 and G0-D12 in the G0 dossier). The map drafts a closing note for each, including thanks to nurikarakaya for #2224, and says when each could close. On 5 October you answered its three questions (harvest map §10), each as recommended:

  • #2986 stays open outside the programme (G0-D6), for the corrected reason: it checks no answer today because nothing calls it yet. Connecting it is treated as a fix to protect today's data, not feature work. Doing that fix needs your separate approval, which you have not given yet.
  • #3934 and #2781 close after R1a's import PRs merge, and #2387 after R1a's editor PRs merge (the new G0-D12). Stream A's lead closes each with its note.
  • #2224 stays open until R1c's group work merges (G0-D5), and the programme lead then closes it with a note thanking nurikarakaya.

Nothing closes now. Each closure waits for its harvest to merge, which needs G0, the hold lift and that release's approved brief. The QM v2 stack (G0-D4) and #2987, #2629 and #2812 (G0-D7) still wait for your answer.

20. The new question management

Added on 5 October 2026 (evening). The question-management plan holds the detail, the evidence and the full list of what already exists. Nothing here is approved for building: implementation stays on hold, and every "proposal" waits for its brief or for your answer.

20.1 What changes for question designers and reviewers

  • One question editor. The Design, Assign and Preview editor that SyRF already has, refreshed, becomes the editor for every project (your decision of 6 October 2026, DQ-01). In a project that has not yet moved to the new engine it saves and assigns questions exactly as today, and it never brings in versions, drafts or publishing there. In a project that has moved, every edit goes into a named draft, several drafts can exist at once, and nothing reaches reviewers until someone publishes a new form version after seeing whose work it affects. When the old "Question design" page retires is still a proposal (question QMI-04 below).
  • How the editor looks (your decision, DQ-02). On a wide screen the editor sits beside a compact list of questions; on a narrow screen it opens as its own page, with a way back to the list. The screen width at which it switches is not decided; it will be tried with users.
  • Edits are saved as you go (your decision, DQ-03). In a project on the new engine, each change a designer makes is saved into the unpublished draft straight away, with a clear "saved" status, a safe way to handle two people changing the same thing, and "Discard changes" for each question. Saving a draft never shows anything to reviewers; only publishing does.
  • Questions keep their meaning. Renaming an option keeps every answer valid. Removing one retires it, with its answer count shown. A question that has been published is retired, never deleted. Whether a question collects one answer or a repeated set is fixed when it is created. The built-in system questions are read only.
  • Filtered options really save (a proposal). "Offer only these answers after that parent answer" becomes something a designer can save, checked by the server. Today the old dialog collects these choices and then throws them away, and the new editor never saved them.
  • Answered questions are protected by the server (a proposal). Today only the screen hides Edit and Delete on an answered question, and it can show them while counts are loading. The server would refuse those edits too.
  • Working together. Designers see who else is viewing or editing, and each other's accepted changes appear live without overwriting what they are typing. This arrives with publication (R2c), not earlier, because the editor has no drafts before then.
  • Import. A designer can import a question template from a spreadsheet: SyRF previews exactly what it will add, adds everything or nothing, never changes existing questions and keeps a receipt.
  • Reviewers see nothing change while designers draft. When a new version is published, their own drafts are kept, they see what changed and why, and an earlier answer is reused only where it is still valid.
  • Required by default, with reasons no value is provided (your decisions, 6 October 2026). New questions are required; optional is an advanced, discouraged setting kept mainly for older questions. Each question offers reasons such as "Not reported" or "Unable to assess", and the designer chooses which comments, units, quotes or other notes each answer allows or needs. Converted projects keep each question's old required or optional setting, and the later redesign wizard offers to make optional ones required (§21).

20.2 What is already built and reused

  • Today's editor, with its tabs, question tree, preview and the two-tree Assign screen, which is reused to put questions into forms instead of stages.
  • The new annotation form (AF2), which already renders forms for review and preview. It becomes the only way the new engine shows a form.
  • The live question counts (the materialised statistics work), which tell a publisher how many answers exist before a change is published.
  • Smaller pieces: answer labels; the server check that already stops a parent edit breaking a child question; the rules file and its test cases for where questions may sit; and the built-in system questions, which become a stored set with a test that proves they match today's.

20.3 What comes in which release

Release What designers get
R1a The editor made solid: its switched-off tests back, debug text gone, drag that works with touch and keyboard, filtered options that save (a proposal), answered questions protected by the server (a proposal), a warning before a change breaks a child question, question import with a preview and receipt, and question templates from the catalogue
After R1a The new editor becomes the default for every project. One editor for both kinds of project is your decision (DQ-01, 6 October 2026); the timing, with the old "Question design" page and its switch retiring after R1a is accepted and one soak on staging, is still a proposal (QMI-04, T-RD-17)
R2a Versioned questions and forms in projects on the new engine; drafts checked against the version they started from, one editor at a time; Assign builds forms; history; import into a draft
R2c Publishing with an impact preview; several people drafting at once with presence and live updates; history with a comparison between versions
R2d Forms that share questions; corrections; revising shared accepted answers (D2-09, which you decided)
R6 Converting every project keeps every question, condition and filtered option, with legacy-gap labels where history is missing

20.4 What is deliberately not reused

  • Question lists per stage for projects on the new engine. Forms own the questions; stages use whole forms. Projects not yet converted keep today's per-stage lists until they convert.
  • The QM v2 designer's store and properties panel, its per-stage assign trees and its stage-by-stage publishing, which belong to the model the session replaced.
  • The browser's native drag and drop, which fails on touch screens.
  • Locks based on answer counts for new-engine projects, because versions replace them.
  • The old QM v2 migration, which dropped every conditional question rule. Conversion must keep them.

20.5 Questions for you (QMI-01 to QMI-05)

They are grouped under tracker row T-OI-02. None blocks the plan's documents, and none authorises building anything. Your answer to DQ-01 on 6 October 2026 answers QMI-04 in part; the others are open.

ID Plain question Recommendation What waits for it
QMI-01 SyRF runs on 3 to 10 servers at once. How do designers connected to different servers see each other and each other's changes? A short-lived "who is here" note in the database that removes itself, read by the new live-update service and never kept as history. The alternatives are messages between the servers, or a new shared cache service (Valkey) Presence in R2c
QMI-02 Your 2 October rule says jobs that change data are all or nothing and can be undone, tidy-up jobs finish, and standing obligations need your approval. Which kind is each new job? Publishing's first step is all or nothing. Its second step, which updates each Study, is an approved job that always finishes. Conversion is all or nothing, with a switch back to the old path before the first new write. Merge and unmerge preparation and stage pool sweeps follow the same rule The publication and conversion briefs
QMI-03 The statistics brief adds no new statistics until its production pilot is accepted. What do early pilots of the new engine use for the impact preview? Exact counting at the moment of publishing for pilots; the new engine's statistics join the brief's scope before general availability, or at its eight-week review R2c pilots
QMI-04 Should the new editor become the default for every project? Yes. Projects not yet converted use it with today's saving. The old "Question design" page and its switch retire after R1a is accepted and one soak on staging. The alternative keeps the old page until R7. Answered in part on 6 October 2026 (DQ-01): yes, one editor for every project, each keeping its own saving and assigning. When the old page retires was not discussed, so that part of the recommendation still waits for you The default-entry change after R1a
QMI-05 The architecture review's plan for simplifying old data shapes does not list questions, stages or targets, and one package row wrongly says #3988 changes the system questions. Record a proposal to that plan? Yes, as a proposal to that plan; nothing to decide inside this package The conversion inventory

21. Your answers of 6 October 2026

In the planning session on 6 October 2026 you answered four things (decision register §1.17). They are planning decisions only: implementation stays on hold, and nothing authorises sending the design pack.

Topic What you decided What it means in practice
Training and the first general release "No, training does not gate GA" Training stays planned (lane TR1) and is built after its dependencies, but the first general release never waits for it
What trainees see after an attempt As recommended Right or wrong per item after assessment; the expected answers only after a pass or when no retry remains
Required by default New questions are required; optional is hidden under advanced settings, discouraged and mainly for older questions; designers choose each question's reasons no value is provided beyond the defaults, including sets from catalogue templates such as SYRCLE A finished review shows that the reviewer considered every question. Complete waits for an answer to every applicable required question (a value, or a reason such as "Not reported" or "Unable to assess"); saving progress never does. A risk-of-bias "Unclear" stays an ordinary answer choice. Converted projects keep their old setting per question
Answer metadata Comments, units, quotes or evidence and similar notes are configurable per question, and can be allowed or required for each kind of answer, including each reason no value is provided. Later that day the "Other" text moved out of the notes and into the answer itself (DQ-46, below) For example, "Unable to assess" can require a comment

21.1 Your design-handoff answers (6 October 2026)

Later on 6 October 2026, in a Codex discussion, you answered the five questions the design pack needed first and the inference-beta question (record archived at owner-session-2026-10-05/syrf-design-decisions-2026-10-06.md.txt; decision register §1.18). They are planning decisions only. Implementation stays on hold, and recording them sent nothing to the design session.

Topic What you decided What it means in practice
One question editor (DQ-01) "Yes" to the same refreshed editor for older and converted projects, keeping each kind of project's own saving and assigning Designers learn one editor. Older projects keep saving each question straight away and choosing questions per stage, with no drafts or publishing. When the old "Question design" page retires is still a proposal (§20.5)
Where the editor opens (DQ-02) A compact list with the editor beside it on wide screens; a separate editor page on narrow screens The width where the layout switches is not decided; the designer and users will try it
Keeping design edits (DQ-03) Edits save automatically into the unpublished draft, with a clear save status, safe handling when two people change the same thing, and a discard button No "Save" button per question in projects on the new engine. Reviewers see nothing until someone publishes
Reconciliation and design screens on phones (DQ-04) Usable phone layouts with every feature, but no formal phone test before release Screening and annotation still must pass the phone, tablet and desktop checks at launch
What to call answers (DQ-46) You approved revised wording (below) Fewer ambiguous words on screen and in exports
What the inference beta covers (DQ-09) "The recommendation makes sense: only rule-writing and inference require the beta" Writing, publishing and evaluating project rules, and anything SyRF infers, need the project to opt in. Recording groups of animals explicitly, and ordinary annotation, do not. The classification specification's other reading is not adopted

The words you approved (DQ-46).

  • Answer status: the overall state of a question in a review. It is unanswered; answered with a value (a listed option, "Other, please specify" with its text, a number, text, a date or a record); or answered with a reason no value is provided.
  • Reason no value is provided: the reasons a designer offers for giving no value, such as "Not reported", "Not applicable" or "Unable to assess", the designer's own, or a catalogue set such as SYRCLE. Each keeps its identity in versions and exports and can need its own notes. This replaces the working term "no-value answer" everywhere. Dense tables may shorten it to "no-value reason".
  • No value to enter: the suggested wording for the reviewer's button that opens those reasons. It is only an example until you confirm a label.
  • Other, please specify: a real answer with a value, the listed "Other" option plus the text the reviewer types. It is never a reason no value is provided.
  • Kept from the recommendation, not discussed separately: unanswered means nothing recorded; option means only a listed choice; Not compared (unanswered) is what reconciliation shows for a missing answer.
  • No longer used on screen: "no-value answer", "blank", "response mode", "response option", "missing-data code" and "answer exception".

What happens to the design pack. All five questions the pack needed first are answered, so none of them is open. The other open questions (40 that the pack can carry, listed in the open questions) go to the design session as labelled options with a "To be decided" mark. The pack is ready for you to send only after this integration has been checked and merged. Sending it is your step; nobody else messages the design session.

Still open after both sessions:

  1. How clearing an answer is recorded. The proposal: clearing leaves a visible "answered, then cleared" entry in history; questions never touched are not pre-filled with blanks; empty text counts as unanswered. You asked why blanks are not written for untouched questions: they add no information, go stale when earlier answers or the form change, cost storage, and every report would have to ignore them (DQ-50).
  2. Whether a live step can depend on passed training (DQ-32), above.
  3. Guidance for trainees before the test (DQ-47), §11.1.
  4. Questions that point at records: at the first general release or with lane C1, and which kinds of record they may point at (DQ-48), §11.3.
  5. When the old "Question design" page retires (the rest of QMI-04), §20.5.

The naming question that was item 1 here is answered (DQ-46, above).