How to Keep an Inclusion and Exclusion Log During Fast Screening

Fast screening fails quietly. You read a title, decide "no," and move on — and three weeks later, when your supervisor asks why a paper you cited in your proposal never made it into the review, you cannot reconstruct the decision. An inclusion and exclusion log fixes that. It is a small, disciplined record that turns each screening decision into something you can defend, re-check, and report.

This guide gives you a complete sequence: define reason codes, apply them consistently, record borderline calls, and build an audit trail that survives later review. It ends with a worked student example and a concrete submission decision.

Screening is a selection method, and selection methods need to be documented. The Cochrane Handbook's guidance on searching for and selecting studies recommends planning searches from eligibility criteria, screening in stages, and documenting the process. PRISMA 2020 provides a reporting checklist and flow-diagram templates that make search, selection, and synthesis methods transparent. NIH guidance on rigor and reproducibility treats transparent methods and reproducibility as core parts of rigorous research practice.

In practical terms: your log is the bridge between your eligibility criteria and the numbers you eventually report. If you cannot explain why a record was excluded, you cannot honestly report how many were excluded and for what reason.

You cannot code decisions against criteria you have not fixed. Before screening, write down your inclusion criteria and your exclusion criteria as short, testable statements. Cochrane's guidance ties search planning to eligibility criteria, so the criteria should exist before you start reading records.

A workable format for each criterion:

• Criterion ID (e.g., E1, E2, I1)
• Plain-language rule (one sentence)
• Test (what you look at to decide: population, date, study design, language, outcome)
• Edge case note (what to do when the rule is ambiguous)

Freeze this list before screening begins. If you must change it mid-stream, record the change and its date in the log so later readers can see when the rule shifted.

Reason codes are short labels attached to every exclusion. They should map one-to-one onto your exclusion criteria so that a code always points back to a rule.

Two rules keep codes clean. First, one primary code per excluded record; if several apply, record the first criterion that failed and note the others in a comment field. Second, reserve a distinct code (like B1) for borderline calls so they never get silently folded into a firm exclusion.

Cochrane's guidance also recommends deduplicating records and linking multiple reports of one study. Give duplicates their own code so your final counts are not inflated by the same study appearing twice.

A single spreadsheet or table is enough. Each row is one record; each column captures one decision element.

• Record ID (stable, assigned at import)
• Citation stub (authors, year, title)
• Source (which database or search produced it)
• Screening stage (title/abstract or full text)
• Decision (include, exclude, borderline)
• Reason code
• One-line justification (the specific evidence from the record)
• Screener initials and date
• Second-look flag and resolution

If you are gathering records through a scholarly search interface, the WisPaper search page is where you find academic papers to screen. As records accumulate, save the ones you keep in My Library so your included set stays organized and separate from the raw screening pool.

Cochrane recommends screening in stages. A two-stage log — title/abstract first, then full text — keeps effort proportional to certainty.

Diagnostic checkpoint after title/abstract screening: Count records by reason code. If one code accounts for a suspiciously large share, re-read a sample of those rows against the criterion. A code that is doing too much work usually means the criterion was written too loosely.

Diagnostic checkpoint after full-text screening: Confirm that every full-text exclusion has a one-line justification quoting the specific passage or feature that triggered the code. Rows with a code but no justification are the ones that break under review.

Borderline records are where logs earn their keep. Do not force them into include or exclude. Instead:

1. Assign the borderline code (B1) and write what made the call hard.
2. State which criterion is in tension and why the record sits on the line.
3. Set a resolution rule in advance — for example, a second screener reviews all B1 rows, or the decision goes to your supervisor at a scheduled check-in.
4. Record the resolution, the resolver's initials, and the date.

This is the audit trail in miniature: a later reader can see not just what you decided but why the decision was not obvious.

An audit trail is the set of records that lets someone else retrace your screening. Keep it in three layers:

• The log itself — every record, every decision, every code.
• A decision memo — a short dated note recording any change to criteria or codes, and the reason.
• A count summary — totals by stage and by reason code, ready to feed a flow diagram.

PRISMA 2020's flow-diagram templates are built for exactly this kind of count reporting, and its checklist covers transparent reporting of selection methods. If you are drafting the methods section of a longer manuscript and want help working through the literature, Scholar Agent supports literature review tasks. When you need to ask questions grounded in the papers you have already saved, Library QA lets you query papers uploaded to My Library or added from search results.

A master's student has ten days to finish the screening for a course paper on remote-work productivity. The rubric rewards a transparent methods section.

Day 1 — Criteria. She writes four exclusion criteria (wrong population, pre-2015, non-empirical design, wrong outcome) and one inclusion rule. She freezes the list.

Day 2 — Codes. She assigns X1–X4, plus X5 for duplicates and B1 for borderline. She builds the log columns listed above.

Day 3–5 — Title/abstract screening. She logs every record. At the checkpoint, X4 (wrong outcome) is catching 40% of records — she re-reads a sample and finds her outcome rule was too broad. She narrows the rule, records the change in the decision memo with the date, and continues.

Day 6–7 — Full text. Several papers are behind a paywall. She codes them X6 (full text unavailable) rather than excluding them on content, and notes in the memo that access was limited. She flags three B1 records where the population was ambiguous.

Day 8 — Supervisor feedback. Her supervisor asks why two well-known papers are missing. She opens the log, finds both rows, and shows the reason codes and justifications. One was a genuine X1; the other was a B1 that had never been resolved. She resolves it and records the outcome.

Day 9 — Counts. She totals records by stage and code, and drafts the flow numbers for her methods section.

Day 10 — Submission decision. She checks three conditions: every excluded record has a code and a justification; every B1 row has a recorded resolution; the count summary reconciles with the log. All three pass, so she submits. If any had failed, she would have held submission and cleared the gap first.

Use these as hard triggers, not suggestions:

• Stop and revise criteria if a single reason code exceeds roughly half of all exclusions at a checkpoint — the rule is probably too broad.
• Stop and escalate any record where two screeners would plausibly disagree, or where the criterion does not clearly apply.
• Escalate to your supervisor any change to criteria or codes made after screening began, and any cluster of unresolved borderline records.
• Do not submit while any excluded record lacks a justification or any borderline record lacks a resolution.

• Eligibility criteria written and frozen before screening
• Reason codes mapped one-to-one to criteria
• Duplicate code and access code defined separately
• Log columns include justification, screener, and date
• Checkpoint run after title/abstract stage
• Checkpoint run after full-text stage
• Every borderline record has a written tension note
• Every borderline record has a recorded resolution
• Decision memo records any mid-stream change with a date
• Count summary reconciles with the log