Research search method
How to build a reproducible literature search log
A search log turns a promising list of papers into a process another researcher can inspect, repeat, and update.
In this article
A literature search is difficult to reconstruct from a folder of PDFs. The folder does not show which database was searched, which query was run, which filters were active, when the search happened, or whether the result set changed before screening. Those details belong in a search log created while the work is happening.
The Cochrane Handbook says the search process should be documented in enough detail to report it correctly and reproduce each database search as far as possible. PRISMA-S provides a 16 item reporting checklist for literature searches in systematic reviews. It covers databases, platforms, full strategies, limits, dates, deduplication, updates, and other search methods. See Cochrane Handbook Chapter 4 and the PRISMA-S record at the EQUATOR Network.
If the query cannot be reconstructed, the result set cannot be explained.
- Source
- Scopus via institutional subscription
- Run
- 2026-09-11 at 09:30 ET, 418 records
- Strategy
- TITLE-ABS-KEY((battery OR cell) AND thermal AND management)
- Artifact
- scopus-battery-thermal-2026-09-11.ris, SHA-256 recorded in project log
Record the minimum evidence for every search
Create one row for each search run, including trial searches that changed the final strategy. A useful row records the review question, source, platform, coverage dates, full query, limits, run time, result count, export file, and the person who ran it. Keep notes about syntax errors and unexpected results beside the row instead of rewriting history after the fact.
| Field | Record | Purpose |
|---|---|---|
| Source and platform | Database name, interface, and access route | The same database can behave differently across platforms. |
| Exact strategy | Every field code, operator, phrase, and subject term | A paraphrased query cannot reproduce the retrieval. |
| Limits | Date, language, document type, and other filters | Limits change the eligible result set and can introduce bias. |
| Run evidence | Date, time zone, result count, and export filename | Databases change, so the run must be tied to a point in time. |
| Version note | Reason for each change and the prior query identifier | The final search should have a visible development history. |
Define the scope before tuning keywords
Write the review question and eligibility criteria before deciding whether a query is good. A search cannot be evaluated without knowing which studies it should retrieve. For an engineering review, record the system, intervention or technology, operating conditions, outcomes, study designs, and publication window. For a health review, a framework such as population, intervention, comparator, and outcome may fit better.
Separate eligibility criteria from search filters. A study may be ineligible after full text review even though it should remain searchable. Applying every eligibility rule inside the database query can make a search precise but incomplete.
Save the exact query, not a summary
Copy the complete strategy exactly as the platform executed it. Preserve parentheses, quotation marks, field codes, proximity operators, controlled vocabulary, truncation, and filters. Record the database and the platform because syntax and indexing can differ even when the content source has the same name.
Do not store only a statement such as "searched for battery thermal management." It cannot explain whether the search covered titles, abstracts, keywords, subject headings, spelling variants, acronyms, or related concepts. PRISMA-S asks authors to report the full strategies for every database and information source, including filters and limits.
Preserve the result set from each final run
Export the retrieved records before screening or deduplication. Use a stable filename containing the source and date. Keep the raw export read only, and perform cleaning in a separate working copy. If your team uses version control or a research data repository, record a checksum so a later reviewer can confirm that the artifact is unchanged.
A count alone is insufficient because database records are corrected, merged, added, and withdrawn. The raw export connects the reported count to the records that were actually screened. Preserve the fields needed for matching, including title, authors, year, DOI, accession number, abstract, and source database identifier.
Keep search decisions separate from screening decisions
The search log explains how records entered the candidate set. A screening log explains why individual records were included or excluded. Combining both into one free text note makes it difficult to distinguish retrieval problems from eligibility decisions.
Assign a stable identifier to each imported record. After deduplication, keep the identifiers of every merged source record so the path remains traceable. When several reports describe the same study, link them to a study identifier rather than deleting the additional reports. Cochrane treats studies, rather than reports, as the unit of interest and warns that one study may have several reports.
Treat an updated search as a new recorded run
Do not overwrite the first query when the review is updated. Record the new date, database coverage, query, result count, and export. Then document what changed. A platform may add a field code, retire a subject heading, alter its index, or change how a filter works. Your own scope may also change after protocol amendment.
Store a concise reason for every revision. Examples include adding a known synonym found during screening, translating a strategy to a second platform, extending the date range, or correcting an operator. Label post hoc changes clearly. A reasonable improvement can still distort the record if it is presented as though it were planned from the start.
Example: an engineering search that changes over time
A team begins a review of thermal management for high power battery packs. Its first query combines battery terms with liquid cooling. During screening, several relevant papers use the term cold plate without saying liquid cooling in the title or abstract. The team adds cold plate to the second query and records the reason.
The log now shows two runs. The first is development evidence. The second is the final search used for screening. Each has an exact strategy, timestamp, result count, and raw export. When the team updates the review six months later, it can rerun the final strategy with a new date boundary, inspect platform changes, and report the update without reconstructing the process from memory.
Use this final search log check
- State the review question and eligibility criteria before evaluating retrieval.
- Name every database, platform, website, registry, and citation search used.
- Save the exact executed strategy with every field code, operator, and limit.
- Record the date, time zone, result count, operator, and raw export filename.
- Keep search development, deduplication, and screening decisions distinct.
- Give every strategy revision an identifier, date, and reason.
- Test whether another researcher could reconstruct the final search from the log alone.
Rivul can help a researcher search scholarly records, save useful papers, inspect source material, and keep citations beside the draft. The search design, eligibility criteria, reporting standard, and final judgments remain the researcher's responsibility.
Use the literature review evidence matrix after retrieval to compare methods and findings, then follow the conflicting findings method when the included studies appear to disagree.