How to Update a Search Log After the Research Question Changes

A research question rarely stays fixed. A supervisor narrows your scope, a rubric rewards a sharper comparison, or a pilot search shows that your original wording pulls in the wrong population. When that happens, the search log you already built is not wasted — but it is no longer a record of the current search. The task is to version the question and its eligibility criteria, mark which searches are now invalidated, rerun only the concepts that changed, and preserve the reasoning so a reader can see why each version exists.

This guide gives a complete sequence for that update, with diagnostic checkpoints, a worked deadline example, a reusable log table, and stop rules for when to escalate to a supervisor or librarian.

Cochrane's guidance on searching for and selecting studies treats the search as something planned from the eligibility criteria. That ordering matters here: if the criteria move, the search that was built from the old criteria no longer matches the study you are now running. A log that silently keeps old searches under a new question creates a mismatch between what you claim to have searched and what your criteria actually require.

The same guidance emphasizes documenting the process and rerunning searches before publication. Documentation is only useful if it reflects the current version of the question, so versioning is part of documentation rather than an extra chore.

Before changing a single line, snapshot what you have. Copy the current question, eligibility criteria, search strings, databases, dates, and result counts into a dated block and label it clearly, for example v1 — frozen [date]. Do not overwrite it.

This frozen block is what lets you answer the question a reader will eventually ask: what did you actually search, and when? Editing in place destroys that record. Freezing first also protects you if the supervisor later prefers the original framing.

Checkpoint: Can you point to a complete, dated v1 that includes the question, criteria, and every search string? If not, reconstruct it from your notes before continuing.

Create v2 with three parts: the revised question, the revised eligibility criteria (population, intervention or exposure, comparison, outcomes, study types, date and language limits), and a short change note stating what moved and why.

The change note is the part students skip and reviewers value most. "Narrowed population from all adults to adults over 65 because the rubric requires a defined subgroup" is a reasoning record. "Updated question" is not.

Keep the criteria explicit enough that each one maps to a search concept. Cochrane's approach of planning searches from eligibility criteria works best when each criterion is concrete enough to translate into terms.

Not every change invalidates every search. Build a small mapping before you touch any database:

• A change to population usually affects the population concept block only.
• A change to outcomes may add or remove a concept block entirely.
• A change to study type or date limits affects filters rather than terms.
• A change to wording only, with identical meaning, may require no rerun at all.

This mapping is what lets you rerun affected concepts instead of starting over. It also tells you which earlier searches remain valid under v2.

Checkpoint: For each concept block, write one of three labels: unchanged, revised, or dropped. If you cannot assign a label, the change is not yet specific enough to act on.

In the log, give every v1 search a status. Use plain language: valid under v2, invalidated — population changed, or superseded by v2-S3. Never delete an invalidated search; strike it through or move it to an archive column with its status and the reason.

Marking invalidation is what keeps the log honest. A reader can then see that a search was run, why it no longer applies, and which search replaced it. This is also where you record the date of invalidation, so the timeline of the project stays legible.

Rebuild the revised concept blocks and rerun them. When you translate terms in a database, use the interface's own transparency features to check the translation. PubMed's search details show how terms were translated and combined, which lets you confirm that a revised phrase was actually searched as intended rather than silently split or mapped elsewhere.

If your revised question now spans unfamiliar literature, a scholarly search interface can help you locate candidate papers for the new concept. WisPaper search is the place to run that scholarly search when you need to find academic papers for a revised concept block. Treat what you find there as candidate records to screen against v2 criteria, and log the search exactly as you would any other source.

Checkpoint: Does every revised concept block have a dated search string, a source, and a result count recorded under v2? If a block is missing, the rerun is incomplete.

New criteria mean old screening decisions may no longer hold. Cochrane's guidance describes screening in stages and deduplicating records, and both need to be redone where the criteria changed. Records you excluded under v1 might qualify under v2, and vice versa.

Record the re-screen as its own dated step. Note how many records carried over, how many were newly retrieved, and how many changed decision. That count is often the most persuasive evidence that the update was done properly.

For every version, keep a short rationale entry. Good entries answer: what triggered the change, what evidence or feedback prompted it, what was traded away, and what would make you revert. Link each entry to the specific searches it invalidated.

This is where a reference manager or library helps. If you keep your candidate papers in My Library, you can save or upload papers and organize them so that the v2 set stays distinguishable from the v1 set while you re-screen. Keeping the two sets organized prevents the most common error in a question change: quietly mixing old and new records.

A student is writing a course paper on remote work and employee wellbeing. The v1 question asks how remote work affects wellbeing across all industries. Two weeks before the deadline, the supervisor returns feedback: the paper is too broad, and the rubric rewards a defined population and a measurable outcome.

v1 (frozen): all industries; any wellbeing outcome; searches on remote work, telework, wellbeing, burnout.

v2: knowledge workers only; outcome limited to burnout measures; same date limits.

Mapping: population block revised; outcome block revised; date limits unchanged.

Invalidation: the v1 population search is marked invalidated — population narrowed to knowledge workers. The v1 outcome search is marked invalidated — outcome narrowed to burnout. The date-limit filter is marked valid under v2.

Rerun: the student rebuilds the population and outcome blocks, reruns them, and records new counts. The student then re-screens the combined set against v2 criteria and records how many records changed decision.

Reasoning preserved: the change note states that supervisor feedback and the rubric drove the narrowing, that general-population studies were traded away, and that the student would revert if the supervisor judged the knowledge-worker restriction too narrow for the available literature.

Submission decision: with the v2 log complete, every search dated, invalidations marked, and the re-screen counted, the student submits, attaching the version history as an appendix. If the rerun had returned too few records to support the narrowed outcome, the correct move would have been to escalate to the supervisor before the deadline rather than quietly widen the criteria back.

Stop and escalate rather than improvise when any of these occur:

• The rerun returns too few records to support the revised criteria. Escalate to your supervisor before widening criteria, because widening silently undoes the versioning work.
• A change touches more than two concept blocks. At that scale, treat it as a new search rather than an update, and confirm the approach with a librarian or supervisor.
• You cannot reconstruct v1. Escalate before submitting, since the version history is part of what you are claiming to have done.
• Feedback conflicts with the rubric. Ask the supervisor to resolve the conflict in writing rather than guessing which to follow.
• The deadline leaves no time for re-screening. Submit with the version history and an explicit note on what remains unscreened, rather than presenting an incomplete re-screen as complete.

If the question change is substantial enough that you are effectively rebuilding the literature review, a longer-running research task may fit better than a sequence of manual reruns. Scholar Agent is the WisPaper area for longer research tasks, including literature review use cases. Use it when the update is a review-scale job, and keep your own versioned log as the record of what was searched.

If you need to ask questions across the papers you have already gathered for the revised question, Library QA supports asking questions based on papers uploaded to My Library or added from search results. That is useful for checking whether your v2 set actually addresses the revised outcome before you commit to it.