How to Run a Feasibility Search Before Committing to a Topic

A feasibility search is a bounded, documented scoping search you run before you commit a manuscript, a coauthor team, or a lab handoff to a topic. Its job is not to prove your idea is novel. Its job is to answer three practical questions: is there enough relevant literature to build on, is the field small enough to screen within your time budget, and can you leave behind a method trail that a coauthor or reviewer could re-run?

Cochrane's guidance on searching for and selecting studies gives the shape of the work: plan searches from eligibility criteria, use multiple sources, combine free-text terms with subject headings, document the process, deduplicate records, screen in stages, link multiple reports of one study, and rerun searches before publication. A feasibility search applies that same discipline at smaller scale, with an explicit stop point.

This article gives you a complete sequence with checkpoints, a worked example, a reusable checklist, and clear rules for when to stop, narrow, or escalate.

Most wasted feasibility searches begin with a vague topic and no eligibility criteria. Before you open any database, write down what you actually have. You are in one of a few recognizable states:

• A topic sentence only. You have a phrase like "remote work and team creativity" but no defined population, outcome, or study type. You need to convert this into eligibility criteria first.
• A draft manuscript with a shaky frame. You have text but are unsure whether the literature base supports the claims. You need a targeted search around each claim.
• A coauthor handoff. Someone else proposed the topic and you must decide whether to invest. You need a search that produces an auditable record the proposer can review.
• A project close-out or review start. You need to preserve an evidence trail so the next person can pick up the work.

Each state changes what counts as "enough." A topic sentence needs breadth to see the shape of the field. A draft manuscript needs precision around specific claims. A handoff needs documentation that another person can follow.

Checkpoint 1: You can state, in one sentence each, your population or setting, your phenomenon of interest, and the study types you would accept. If you cannot, stop and write them.

Cochrane's approach starts from eligibility criteria rather than from keywords. Do the same. Write your criteria as inclusion and exclusion rules, then derive search terms from them.

A workable plan has four parts:

1. Concepts. Break the topic into two to four concept blocks (for example, a population block, an exposure block, an outcome block).
2. Terms per concept. For each block, list free-text synonyms and, where the database supports it, subject headings. PubMed supports field tags and phrase searching, and its Search Details view reveals how your terms were translated and combined, which is useful for catching a term that silently matched nothing.
3. Sources. Use more than one source. PubMed supports filters, Advanced Search, saved searches, Similar Articles, and citation lookup. Google Scholar documents searching by author and title, date limits and sorting, Cited by and Related articles, and locating alternative versions of a work. These two behave differently, which is the point of using both.
4. Limits. Set a date range and language limit deliberately, and record why. A limit you cannot justify later is a limit you will have to defend in review.

If you want a scholarly search interface to run and refine these queries, you can start from WisPaper search and keep the resulting records together for the next step.

Checkpoint 2: Your plan lists concepts, terms, at least two sources, and explicit limits. Save the exact query strings, not just the results.

Documentation is not a cleanup task you do at the end; it is the artifact the feasibility search exists to produce. Cochrane explicitly recommends documenting the search process and deduplicating records. Build the trail while you search.

For each query, record:

• The source and interface used
• The full query string, including field tags and filters
• The date you ran it and the date range covered
• The number of records returned
• Any translation or expansion the interface applied

PubMed's Search Details is valuable here because it shows how the system interpreted your terms. If a subject heading expanded unexpectedly, that belongs in your notes. Google Scholar's citation export and email alerts let you capture records and keep watch on a topic between search sessions.

As records accumulate, move the ones that survive your first pass into a working collection. My Library is where you can save or upload papers and organize them, which keeps the feasibility set separate from your general reading.

Checkpoint 3: A colleague could take your notes and re-run each query. If they cannot, your trail is incomplete.

Cochrane recommends screening in stages and linking multiple reports of one study. A feasibility search does not need a full systematic review's screening burden, but it does need staged screening so you can stop early when the field is clearly too thin or too vast.

A practical three-stage screen:

1. Title screen. Sort by relevance or date and scan titles against your criteria. Record how many you excluded and the main reasons.
2. Abstract screen. Read abstracts for the survivors. Note recurring study designs, populations, and outcomes. This is where you learn whether the field has the kind of evidence you assumed.
3. Full-text spot check. Read a small sample of full texts to confirm the abstracts were accurate and to find multiple reports of the same study.

Linking reports matters more than it seems. If five hits turn out to be five papers from one cohort, your apparent evidence base is smaller than the record count suggests. Google Scholar's Related articles and Cited by features help you trace a study's family of reports and its downstream use.

Checkpoint 4: You can state how many distinct studies, not just how many records, your search surfaced.

A record count tells you volume. A feasibility decision needs shape. After screening, characterize what you found:

• Recency. Are the core papers recent, or is the field quiet? Date limits and sorting in Google Scholar and PubMed filters make this visible.
• Design mix. Are there empirical studies, reviews, or mostly commentary? A field of commentary may not support an empirical manuscript.
• Terminology drift. Did your free-text terms miss a body of work that uses different vocabulary? PubMed's Similar Articles and Google Scholar's Related articles are quick ways to test this.
• Access. Can you actually obtain the full texts? Google Scholar's library access links and alternative-version lookup help here.

If you need to ask questions grounded in the papers you have collected, Library QA lets you query papers uploaded to My Library or added from search results, which is useful for checking what a set of papers collectively says before you commit.

Checkpoint 5: You can describe the field in a short paragraph: what exists, what is thin, and what vocabulary the field uses.

This is the decision the feasibility search exists to support. Write the decision down with its rationale so the trail is complete.

A negative feasibility result is a useful artifact. It saves a coauthor team from investing in a manuscript the literature cannot support, and it documents why the topic was set aside.

Checkpoint 6: The decision, its rationale, and the evidence behind it are written in one place.

Suppose a coauthor proposes "remote work and team creativity" and asks you to assess feasibility before the group commits a semester.

Step 1 — Criteria. Population: knowledge workers in teams. Phenomenon: remote or hybrid work arrangements. Outcome: creativity or creative performance. Acceptable designs: empirical studies and reviews.

Step 2 — Plan. Three concept blocks (remote/hybrid work; teams; creativity). Free-text synonyms for each, plus subject headings where supported. Sources: PubMed and Google Scholar. Limit: last ten years, English.

Step 3 — Run and record. You save both query strings, the run dates, and the record counts. PubMed's Search Details shows one heading expanded more broadly than intended; you note it and adjust.

Step 4 — Screen. Title screen cuts the set substantially. Abstract screen reveals that many hits concern individual productivity rather than team creativity. You link reports and find that several hits share one dataset.

Step 5 — Shape. The field is active but the team-creativity angle is thinner than the productivity angle. Terminology varies: some papers use "creative performance," others "innovation." You re-run with those synonyms.

Step 6 — Decide. You narrow to team-level creative outcomes and commit, with the narrowed criteria recorded. The coauthor receives the query strings, the screening counts, the linked-study note, and the decision rationale.

If the group later wants to expand from this scoped question into a broader literature review or a reproduction plan, Scholar Agent supports longer research tasks in its literature review, inspiration, and reproduction use cases, and Research Projects is where a new project can be created to carry the work forward.

Use this before every topic commitment.

• Population, phenomenon, and acceptable designs written in one sentence each
• Two to four concept blocks defined
• Free-text synonyms and subject headings listed per block
• At least two sources selected
• Date and language limits set with a recorded reason
• Full query strings saved with run dates and record counts
• Interface term translation checked (for example, PubMed Search Details)
• Records deduplicated
• Staged screening completed with exclusion reasons
• Multiple reports of the same study linked
• Field shape described: recency, design mix, terminology, access
• Decision recorded as commit, narrow, pivot, or stop, with rationale
• Trail stored where a coauthor can find and re-run it

Your feasibility search is ready when four conditions hold:

1. Reproducible. Every query string, source, date, and limit is recorded, and a colleague could re-run the search.
2. Screened. You can report distinct studies, not just record counts, and you know why records were excluded.
3. Characterized. You can describe the field's recency, design mix, vocabulary, and accessibility in a short paragraph.
4. Decided. A written decision with rationale exists, whether that decision is to commit, narrow, pivot, or stop.

Cochrane also recommends rerunning searches before publication. Treat your feasibility trail as a living record: when you return to the topic months later, re-run the saved queries and note what changed.

Clear rules prevent a feasibility search from quietly becoming an unbounded review.

Stop and record a negative result when:

• Screening yields very few distinct studies after terminology checks
• The literature is dominated by commentary rather than empirical work
• Full texts are largely inaccessible

Narrow and re-run when:

• Record counts are too large to screen within your budget
• A single concept block is driving most of the noise

Escalate to a fuller review process when:

• The topic will support a formal systematic review, in which case follow Cochrane's full sequence including protocol, comprehensive multi-source searching, and staged screening
• Coauthors disagree on criteria, which needs resolution before searching continues

Escalate to reference checking when:

• You are assembling a bibliography and need to confirm that cited references are real. TrueCite checks BibTeX against real academic databases to flag hallucinated references, which fits the point where your feasibility trail becomes a manuscript bibliography.