Build the audit trail while you build the search

By Dr. Esmaeel Saeedy Robat, Founder of MetaSyn Academy · Published meta-analyst (Nature Human Behaviour, 2026) · Evidence checked July 2026

A reproducible search record is more than a final query. It connects the review question to searchable concepts, explains why information sources were chosen, preserves every platform-specific strategy, records testing and peer review, and captures what was actually run.

Cochrane requires search methods to be planned from the eligibility criteria and documented in enough detail for correct reporting. PRISMA-S then specifies what readers need to see about sources, platforms, strategies, limits, dates, peer review, records, deduplication, and updates.^1,3 These are related but different jobs: good reporting cannot repair a poorly designed search, and a carefully designed search cannot be assessed if its decisions were not retained.

What a defensible search record must connect

1. Review framing: question, eligibility criteria, review type, protocol, and scope.
2. Concept decisions: which concepts were searched, which were omitted, and why.
3. Source selection: databases, platforms, registers, websites, and supplementary methods with rationale.
4. Term development: controlled vocabulary and free-text terms, including provenance and variants.
5. Strategy testing: known-item checks, benchmark or relative-recall checks where suitable, and query revision.
6. Platform translation: exact syntax, fields, limits, filters, dates, and yields for each interface.
7. Peer review: PRESS elements, reviewer comments, responses, and changes.⁴
8. Reporting and updating: PRISMA-S mapping, deduplication description, rerun dates, and version history.³

A search becomes defensible through connected decisions

A copied search string shows syntax at one moment. It does not show why concepts were selected, what eligible evidence each source was expected to contribute, which terms were tested and rejected, whether the strategy was translated correctly, or what changed after peer review. Those omissions are consequential. A search can be syntactically valid and still be poorly aligned with eligibility; it can also be methodologically thoughtful yet impossible to reproduce because the platform, date, limits, and executed version were not retained.

The documentation task therefore has two layers. The design record explains the reasoning that shaped retrieval. The execution record preserves what actually happened in each source. PRISMA-S describes what should be reported publicly, while PRESS structures peer review of the electronic strategy. Neither replaces prospective search development.^3,4

Begin with a decision ledger

Before drafting terms, identify the decisions that could materially change retrieval: concepts included or omitted; evidence types sought; databases, registers, websites, and supplementary methods selected; restrictions proposed; filters considered; and the person responsible for each decision. For every entry, record the rationale, supporting source or team judgment, date, and version. This turns later disagreement into a traceable methodological discussion rather than an attempt to reconstruct memory.

Question frameworks help expose concepts, but they do not dictate the final query. In some intervention-review contexts, searching comparator or outcome elements reduced recall; the appropriate response is to test whether those elements are searchable and necessary, not to create a universal rule.⁶ The template therefore asks both what was searched and what was deliberately omitted.

Separate database, platform, and search version

A database is the content source; a platform is the interface used to search it. MEDLINE through PubMed and MEDLINE through Ovid are not interchangeable execution records. Field tags, automatic mapping, phrase handling, adjacency, truncation, limits, and export behaviour may differ. Preserve the database name, platform, coverage if reported, exact executed strategy, date, yield, and version as separate facts. When a strategy is translated with software, keep the translation output as a draft and document the human verification against current platform help.

Test for informative failures

Testing should be designed to reveal why a strategy fails. Known relevant records can expose missing synonyms, indexing terms, spelling variants, or overly restrictive fields. A relative-recall test can assess performance against a defined benchmark set, but the result inherits the limitations of that set.⁷ Record which line retrieved each benchmark, analyze misses, and preserve revisions. “All known items found” is a test result—not a claim that all unknown eligible studies were found.

Do not collapse conduct, peer review, and reporting

Search conduct concerns what the team plans and does. PRESS concerns structured peer review of a strategy. PRISMA-S concerns what the review reports about the search. A single checklist cannot substitute for all three. The practical record below keeps their ownership visible so that a reporting item is not mistaken for a design standard and a peer-review recommendation is not represented as certification.

The solution is not to complete every field mechanically. It is to maintain the smallest complete record that allows a qualified reader to understand the design, reproduce the execution to the extent the source permits, assess changes, and prepare accurate reporting. Blank fields should mean “not applicable” or “not yet completed,” never an undocumented assumption.

Use the record with its methodological guide

The template captures decisions; the paired guide explains how to make them. Keep the two together in the review’s controlled project files, with dated versions for peer review, final execution, and updates.