> ## Documentation Index
> Fetch the complete documentation index at: https://docs.consensus.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Screen abstracts against inclusion criteria

> Apply explicit inclusion and exclusion criteria across thousands of abstracts, with a decision log a second reviewer can audit.

## What you get

One row per record: include, exclude, or flag for human review — each with the criterion that decided it and a supporting quote. The most labour-intensive step in evidence synthesis, turned into something a human checks rather than performs.

<Note>
  Consensus gives you the primitives for this — filters, pagination, abstracts, and study types. It is not a packaged screening product, so you are building the workflow yourself. Customers ask us for this regularly; treat the recipe below as the current best path.
</Note>

## Who it's for

Anyone running a systematic or scoping review — graduate students, methodologists, evidence synthesis units. Traditionally two people screen every abstract independently, which is where the weeks go.

## The prompt

```text theme={null}
You are a systematic review screener. Apply the criteria below to each record.
Do not summarize the papers. Do not decide what would be interesting.

Inclusion criteria:
[ONE PER LINE]

Exclusion criteria:
[ONE PER LINE]

For each record, work through the criteria in order and stop at the first one
that decides the case. Then output exactly one verdict:

- INCLUDE — meets every inclusion criterion, triggers no exclusion.
- EXCLUDE — fails a specific criterion. Name which one.
- FLAG — the abstract does not contain enough information to decide. Say which
  criterion you could not evaluate and what you would need to read.

Rules:
- FLAG is not a failure state. A record whose abstract omits the sample size
  cannot be excluded for sample size — flag it.
- Never infer a study design the abstract does not state. If it does not say
  randomized, it is not an RCT for screening purposes.
- Quote the phrase that decided the verdict. A verdict with no quote is not
  auditable and will not survive a second reviewer.
- Judge the record in front of you. Do not use anything you know about the
  paper from elsewhere.

Output: Record ID | DOI | Verdict | Deciding criterion | Supporting quote |
Confidence (high/low).
```

## Calibrate before you scale

<Steps>
  <Step title="Have a human screen 100 records first">
    Screen a random sample by hand, then run the agent over the same 100 and compare. You are measuring agreement, and more importantly reading the disagreements.
  </Step>

  <Step title="Fix the rubric, not the model">
    Almost every disagreement traces to a criterion two humans would also read differently. Rewrite the criterion until it is unambiguous, then re-run.
  </Step>

  <Step title="Watch the FLAG rate">
    A near-zero flag rate means the agent is deciding cases it cannot actually decide from an abstract. Somewhere between 5% and 20% is normal depending on how much your criteria depend on methods detail.
  </Step>

  <Step title="Escalate borderline records to full text">
    For flagged records, re-request with `include_full_text_chunks=true` using the criterion as the query, and screen the excerpts instead.
  </Step>
</Steps>

## Narrowing before you screen

Every filter you apply is a record you do not have to screen — but each one also risks dropping an eligible study, so record what each rung costs you.

```bash theme={null}
curl -G "https://api.consensus.app/v1/search" \
  -H "x-api-key: $CONSENSUS_API_KEY" \
  --data-urlencode "query=resistance training older adults muscle strength" \
  --data-urlencode "study_types=rct" \
  --data-urlencode "human=true" \
  --data-urlencode "sample_size_min=30" \
  --data-urlencode "page_size=200"
```

Use the [filter ladder](/use-cases/best-practices#filter-ladder) and keep the count at each rung, because a reviewer will ask.

## Audit requirements

Follow the [grounding rules](/use-cases/best-practices#grounding-and-auditability). Screening specifically needs: total records retrieved, records after deduplication, screened, included, excluded by criterion, and flagged. Excluded counts must be reported per criterion — PRISMA requires reasons, not a single total.

## What to check before you trust it

* **Never let the agent be the only screener on a published review.** It is a first pass that a human adjudicates, and journals will ask who screened.
* **Check the excluded pile, not just the included one.** False exclusions are invisible in the output and fatal to the review.
* **Re-screen after any criterion change.** A mid-run rubric edit makes the earlier verdicts incomparable.

## Related

<CardGroup cols={2}>
  <Card title="Build a PRISMA-ready search corpus" icon="layer-group" href="/use-cases/prisma-corpus">
    The step before screening: assembling the records.
  </Card>

  <Card title="Write the search-strategy section of your methods" icon="file-lines" href="/use-cases/search-strategy-methods">
    Turn the log into the paragraph reviewers require.
  </Card>

  <Card title="Best practices" icon="shapes" href="/use-cases/best-practices">
    Filter ladder, grounding rules, and the five primitives.
  </Card>

  <Card title="All use cases" icon="grid-2" href="/use-cases">
    Browse the gallery by persona.
  </Card>
</CardGroup>