Protocol

What is the Protocol?

The protocol is the blueprint for your systematic review. It defines your research question, screening criteria for each stage, and extraction fields that determine what data the AI pulls from included papers.

You set up the protocol before screening begins. The AI then uses that protocol to apply the same rules across all papers, which keeps screening and extraction consistent and reproducible.

You can confirm the generated protocol as-is, edit any criterion or field, or build it from scratch. Save only when it reflects your actual review design.

When to set up the protocol

Set up the protocol before you start screening, ideally while you create the systematic review. Defining the protocol early gives you a clear set of rules before the AI begins screening papers or extracting data.

AI-generated protocol

When you open the Protocol stage for the first time, the system generates the protocol from your research question and additional context. It creates separate outputs for each enabled stage, so you only see Title & Abstract Screeing or Full-text Screening criteria if those stages are part of your review.

The generated protocol includes:

• Abstract screening criteria for title & abstract screening, if enabled
• Full-text screening criteria for full-text screening, if enabled
• Extraction fields for data extraction

The AI generates the protocol as a methodologist-oriented assistant using established systematic review frameworks. Depending on your question type, it structures suggestions around frameworks such as PICO, PEO, CoCoPop, or SPIDER.

Stage-specific guidance matters. Title and Abstract criteria must be answerable from the title and abstract alone, while Full Text criteria can rely on details available only in the paper itself.

Screening criteria

Screening criteria are the inclusion and exclusion rules the AI applies to each paper. Each criterion is evaluated independently, and all criteria carry equal weight.

Each screening criterion includes the same four parts:

• Title: A short label for the criterion. Suggested titles are typically 2 to 5 words so you can scan them quickly during review.
• Instructions: Guidance that tells the AI how to interpret the criterion. Use this field to clarify edge cases, terminology, or how strictly the rule should be applied.
• Include When:The concrete condition that means a paper passes the criterion. Write this as an observable rule, not as a general goal.
• Exclude When: The concrete condition that means a paper fails the criterion. Clear exclusion rules reduce inconsistent decisions across papers.

Title and abstract screening criteria

Title and Abstract screening is designed to be sensitive rather than final. If the abstract is silent or ambiguous for a criterion, the AI keeps the paper in play instead of excluding it.

The AI follows this decision pattern:

• If any criterion is clearly a No, the paper is excluded.
• If every criterion is Yes, the paper is included.
• If at least one criterion is Maybe and none are No, the paper moves forward for further review.

This makes the stage conservative by design — ambiguity leads to review, not exclusion.

Full-text screening criteria

Full Text screening is confirmatory — the AI uses information from the full paper to make the final eligibility decision.

Full Text screening is stricter:

• If every criterion is Yes, the paper is included.
• If any criterion fails, the paper is excluded.

Exclusion reasons

Every excluded paper gets a reason. The reason is the first failing criterion — the first criterion evaluated as a clear "No" among the saved criteria for that stage.

Because the exclusion reason is the first failing criterion in order, the position of each criterion matters. If two criteria both fail for a paper, the one listed first becomes the stated reason for exclusion. This is why reordering criteria can change which criterion is cited as the exclusion reason, even though the paper is still excluded either way.

Extraction fields

Extraction fields define what data the AI pulls from papers that pass full text screening. The generated protocol usually includes a mix of standard study descriptors and fields specific to your research question.

Every extraction field contains the following parts:

• Title: A short field name such as Study design, Sample size, or Setting.
• Instructions: Guidance on what to extract, which details to capture, and how to present the answer.
• Output type: Controls the response format the AI must return for the field.
  • Allowed values: Answer, Yes/Maybe/No, or Specified options

Output types

Use the output type that best matches the data you need. More structure usually improves consistency, but only if the options map cleanly to the evidence in the paper.

Building better extraction fields

Write field titles and instructions so a reviewer could apply them without extra explanation. Instructions describe what to extract and how to present it. The output setting controls the response format, so there is no need to repeat it in the instructions.

A clear instruction does three things:

• States what to extract, in your review's terminology, anchored to your population or setting so off-topic content is ignored.
• Lists the details to capture, including sub-components, units, and expected categories.
• Says how to present the answer, so values are comparable across every paper.

Add these where they apply:

• Where to look, if the value sits in a specific section, table, or figure.
• Which value to prefer, if a paper reports more than one, such as multiple timepoints or analyses.
• What counts as missing, so the AI knows when to leave a field as not found.

If a field asks for a judgment, define what counts as evidence. If a field asks for a value, specify the format you want returned.

For specified fields, keep the option list complete and mutually distinct. Overlapping options make extraction less reliable and harder to interpret later.

Editing the protocol

You can edit the protocol at any time, but the impact depends on whether the affected stage has already been completed.

Editing protocol data before a stage starts has no effect on that stage — the stage simply uses the updated protocol when it runs.

Editing protocol data after a stage is completed requires that stage to be re-run with the new criteria or fields. Any downstream stages that depend on the re-run stage are also affected and must be repeated.