The Search Strategy Exists Only in One Person's Notes: Rebuilding an Auditable Method Trail

A manuscript is nearly ready. The screening is done, the synthesis reads well, and the coauthors are trading final edits. Then someone asks the question that stalls the room: "What exactly did we search, and where is it written down?" The answer is that the strategy lives in one person's notebook — a string of terms, a few database names, and a date, all in a format no one else can reconstruct. The person who built it may be leaving the project, or may simply be unavailable during peer review.

This is a recoverable situation, but only if you treat it as a reconstruction task rather than a memory exercise. The goal is a method trail that a coauthor, a reviewer, or a future lab member could follow without asking the original searcher anything. This article walks through the starting problem, the decisions that rebuild the trail, and the point at which the result is ready to defend.

The immediate symptom is a missing methods paragraph. The deeper problem is that several linked decisions were never externalized: which eligibility criteria drove the terms, which sources were used, how free-text terms and subject headings were combined, how records were deduplicated, and how screening proceeded in stages. Cochrane's guidance on searching for and selecting studies treats each of these as a planned, documented step rather than an afterthought, and it recommends rerunning searches before publication. If none of that was recorded, you cannot yet show that the review's selection process was systematic.

There is also a reporting dimension. PRISMA 2020 supplies a checklist, expanded explanations, an abstract checklist, and flow-diagram templates for original and updated systematic reviews, with transparent reporting of search, selection, and synthesis methods. A reviewer who cannot find your search details in the manuscript is not being pedantic; they are checking against a known reporting standard.

Before writing anything, establish what actually survives. Sort what you have into three buckets.

Recoverable artifacts. Search strings pasted into an email, exported record files, a screening spreadsheet, a reference manager library, meeting notes that mention a date range. These are your raw material.

Reconstructable decisions. Eligibility criteria you can restate from the protocol or the manuscript's introduction; the list of sources you remember using; the rough logic of how terms were combined. These can be rebuilt and then confirmed with the original searcher if they are reachable.

Genuinely lost details. Exact date-stamped result counts, the precise syntax used in a particular interface, the order in which duplicates were removed. Do not invent these. Decide whether to rerun the search to regenerate them or to describe the process at the level you can actually support.

Write this inventory down. It becomes the scope statement for the repair and prevents the team from quietly filling gaps with plausible-sounding detail.

The most common reason a search strategy is hard to reconstruct is that it was never explicitly derived from anything. Cochrane recommends planning searches from eligibility criteria. That gives you a defensible starting point: restate the criteria in plain language, then map each criterion to the concepts the search needed to capture.

In practice this means building a concept table. For each core concept, list the free-text synonyms and the subject headings that represent it. This table is the artifact that survives personnel changes, because it explains why each term is in the string rather than just recording that it was.

If the original searcher is reachable, send them the concept table and ask them to confirm or correct it. If they are not, mark the table as reconstructed and note the basis for each entry.

Cochrane's guidance is specific enough to serve as your checklist: use multiple sources, combine free-text terms with subject headings, document the process, deduplicate records, screen in stages, and link multiple reports of one study. Each of these becomes a line in your methods record.

• Sources: list every database, registry, or other source you searched, and note the date of each search.
• Term combinations: record the free-text terms and subject headings together, with the Boolean logic that joined them.
• Deduplication: describe how duplicate records were identified and removed.
• Staging: describe the screening stages — for example, title and abstract followed by full text — and who performed each.
• Study linking: note how multiple reports of the same study were grouped.

If any of these steps was performed but not written down, reconstruct it from the artifacts you recovered and label it as reconstructed. If a step was never performed, that is a finding about the review, not a formatting problem, and the team needs to decide how to address it before submission.

A method trail is only auditable if the records themselves are organized in a way someone else can navigate. This is where a shared reference library earns its place. Zotero collections can organize one item in multiple project groupings without duplicating it, and tags can describe topic, method, status, or workflow — which means a single library can carry both the topical structure of the review and the workflow status of each record. Saved searches update automatically, and the Duplicate Items collection supports review and merging, which directly supports the deduplication step above.

If your team works inside WisPaper, the equivalent move is to save or upload the recovered records into My Library so that the collection, rather than one person's folder, becomes the shared source of truth. The point is not the specific tool; it is that the records and their organization live somewhere the whole team can see.

Some details cannot be reconstructed from memory, and the honest response is to rerun the search. Cochrane recommends rerunning searches before publication, so this step often belongs in the timeline anyway.

When you rerun, capture the outputs as you go: the exact strings, the sources, the dates, and the result counts. If you need to find papers through a scholarly search interface, WisPaper search is one place to run and capture those queries; the public Scholar Search page explains the entry point for finding academic papers. Record what you ran and when, exactly as you would for the original search.

Treat the rerun as a documented event, not a quiet refresh. If the rerun changes the included set, that change needs to be visible in the manuscript and the flow diagram.

A reconstructed search often coincides with a reference list that was assembled over months by several people. Before the trail is closed, screen the bibliography itself. TrueCite checks BibTeX against real academic databases to flag hallucinated references — a useful pass when entries were copied, merged, or generated during the repair.

Run this check after the library is consolidated, not before, so you are screening the final list rather than a moving target. Record which entries were flagged and how each was resolved.

The repair produces a small set of artifacts that together constitute the method trail:

1. A concept table mapping eligibility criteria to free-text terms and subject headings.
2. A sources and dates log listing every source searched and when.
3. A deduplication and screening record describing how duplicates were removed and how screening proceeded in stages.
4. A consolidated, organized library where records can be navigated by anyone on the team.
5. A verified reference list with flagged entries resolved.
6. A methods paragraph and flow diagram written from the artifacts above, aligned with PRISMA 2020 reporting expectations.

If the project is large enough to warrant a shared workspace, Research Projects is where a team can create and hold that work together. For longer reconstruction efforts — for example, rebuilding a literature review from scattered notes — Scholar Agent covers literature review, inspiration, and reproduction use cases that fit that kind of extended task.

The trail is ready when a coauthor who was not involved in the original search can answer four questions from the artifacts alone: What were the eligibility criteria, and how did they shape the terms? Which sources were searched, with what terms, and on what dates? How were duplicates removed and how was screening staged? Where do the included records live, and how were the references verified?

A second test is whether the methods paragraph and the flow diagram agree with the artifacts. If the paragraph describes a step the artifacts do not support, one of them is wrong. Fix it before submission rather than during peer review.

A third test is durability. If the person who built the trail left tomorrow, would the next person be able to rerun the search? If the answer depends on a conversation, the trail is not finished.

• Derive the strategy from criteria, and write the derivation down. The concept table is cheap to build at the start and expensive to reconstruct later.
• Treat documentation as a step, not a cleanup task. Cochrane lists documenting the process alongside searching multiple sources and combining terms; it belongs in the plan.
• Keep records in a shared, organized library from day one. Collections and tags that describe topic, method, status, or workflow make the library legible to people who were not there when it was built.
• Plan to rerun before publication. If a rerun is expected, capturing its outputs becomes routine rather than a scramble.
• Verify references as a distinct pass. Screening the bibliography against real records is a separate check from screening studies for eligibility.