You Inherited 200 PDFs With No Search Log: Rebuilding a Defensible Evidence Base

A folder of 200 PDFs arrives with a manuscript draft, a half-finished reference list, and no record of how any of it was found. The temptation is to write a methods paragraph that sounds systematic and move on. The better move is to treat the folder as an evidence problem: reconstruct what provenance you can, inventory what you actually hold, recover metadata, resolve duplicates, and then decide honestly what kind of claim the collection can support.

This article walks through that repair as a sequence of concrete decisions. The running example is a review manuscript inherited by a new team member. The goal is not to pretend the original search was systematic. The goal is a defensible starting point you can describe accurately and build on.

A pile of PDFs is a set of documents, not a search. Before touching a single file, write a short provenance memo that states what you know and what you do not. In the inherited-review case, that memo might say: the folder was assembled by a previous author over an unknown period; no search strings, databases, or dates were recorded; the draft cites some but not all of the files; and the collection's completeness relative to any eligibility criteria is unknown.

That memo does two things. It prevents you from later describing the collection as if it came from a planned search, and it gives you a baseline against which every repair step can be logged. Keep the memo with the project files so the trail is auditable.

Cochrane's guidance on searching for and selecting studies is useful here as a reference point for what a planned search normally contains: searches planned from eligibility criteria, multiple sources, free-text terms combined with subject headings, a documented process, deduplication, staged screening, and linking of multiple reports of one study. Comparing your inherited folder against that list shows exactly which elements are missing. That comparison is diagnostic, not aspirational — you are identifying gaps, not claiming you have filled them.

An inventory is the backbone of the repair. Build a spreadsheet with one row per file and columns for filename, file path, file type, apparent title, apparent authors, apparent year, and any note about where the file came from (email attachment, downloaded from a journal site, shared by a colleague). Do not edit the PDFs yet. Capture what is there.

Two practical rules keep the inventory honest:

• Record the source of each file separately from its content. A file's origin and its bibliographic identity are different facts, and you will need both.
• Do not silently correct filenames. If a file is named paper_final_v3.pdf, log that name and add a separate column for the title you infer from the document itself.

When you need to find additional papers to fill obvious gaps, use a scholarly search interface rather than ad hoc browsing, and log the queries you run. WisPaper's scholarly search interface is one place to run those queries; the point is that every new file entering the collection gets a row and a recorded query, so the inventory stays complete.

Metadata recovery is where inherited collections most often go wrong. The safe pattern is to extract candidate metadata from the document, then verify it against an authoritative record before it enters the reference list.

A workable sequence:

1. Extract what the PDF itself states. Open the first page and the PDF properties. Capture title, authors, year, journal, and DOI if present.
2. Check for internal consistency. A file whose first page says one year and whose filename says another needs a note, not a guess.
3. Verify against a database record. Match the DOI or the title-plus-author combination to a real record. If no match exists, flag the item rather than assigning metadata by inference.
4. Log the verification. Add a column recording how the metadata was confirmed and when.

For reference lists that will be submitted, citation screening matters. TrueCite checks BibTeX against real academic databases to flag hallucinated references, which is directly relevant when inherited reference lists contain entries nobody has verified. You can read about that workflow on the TrueCite page.

Duplicate detection in an inherited folder has two layers. The first is file-level: the same PDF saved twice under different names. The second, and more important, is record-level: two different files that report the same study, or a conference abstract and its full paper.

Cochrane's guidance explicitly calls for deduplicating records and linking multiple reports of one study. In practice that means your inventory needs a study identifier column, separate from the file identifier. Two files can share a study identifier while remaining distinct documents.

Zotero's Duplicate Items collection supports review and merging of duplicate items, which is a practical way to handle the record-level layer once items are in a reference manager. Its collections can also place one item in multiple project groupings without duplicating it, and tags can describe topic, method, status, or workflow. That combination — one item, multiple groupings, descriptive tags — is well suited to an inherited collection where the same paper matters to several sections of a manuscript.

If you are organizing the repaired collection inside WisPaper, My Library is where you save or upload papers and organize them. Use it as the working home for the cleaned set, with the inventory spreadsheet as the audit record alongside it.

Once the inventory is clean, you face a decision: do you treat the inherited set as your evidence base, or do you run a new search and treat the inherited set as one input among several?

These are different projects with different reporting obligations. If you run a new search, you can describe it. If you rely on the inherited set, you must describe it as an inherited collection with unknown provenance. Mixing the two without saying so is the failure mode to avoid.

A defensible middle path is to keep two clearly labeled layers:

• Layer A — inherited collection: inventoried, deduplicated, metadata-verified, with provenance gaps documented.
• Layer B — new searches: planned from eligibility criteria, with queries, sources, and dates recorded.

Every item in the final manuscript then traces to one layer or the other. When you need to run a longer literature task across the cleaned set, WisPaper's Scholar Agent area covers literature review, inspiration, and reproduction use cases; keep its outputs in Layer B with the query that produced them.

The method trail is the deliverable that makes the repair defensible. It should let a reader — or a reviewer — reconstruct what you did. At minimum, record:

• the provenance memo and its date;
• the inventory file and its version history;
• the metadata verification log;
• the duplicate-resolution log, including which records were merged and why;
• the queries run for any new searching, with dates and sources;
• the screening decisions and the criteria used.

PRISMA 2020 provides a reporting checklist, expanded explanations, an abstract checklist, and flow-diagram templates for original and updated systematic reviews, including transparent reporting of search, selection, and synthesis methods. If your manuscript is a systematic review, those templates give you a structure for the trail. If it is not a systematic review, the same discipline still applies: report what you did, in the order you did it.

At the end of the repair, you should be able to hand over a package rather than a folder. In the running example, that package contains:

• a provenance memo stating the collection's origin and its gaps;
• a complete inventory with one row per file and a separate study identifier;
• a verified reference list with a log of how each entry was confirmed;
• a duplicate-resolution record distinguishing file duplicates from multiple reports of one study;
• a clearly separated record of any new searches;
• a methods paragraph that describes the inherited collection accurately and does not claim a systematic search that did not happen.

The corrected deliverable is not a better-sounding methods section. It is a set of records that supports whatever the methods section says.

Four habits carry over to any project that starts with someone else's files:

1. Write the provenance memo first. It costs an hour and prevents a category error later.
2. Inventory before you interpret. One row per file, source recorded separately from content.
3. Verify metadata against records, not against filenames. Flag unmatched items instead of inferring.
4. Keep inherited and new layers separate. Every item traces to one or the other.

When you need to ask questions across the cleaned collection, Library QA supports asking questions based on papers uploaded to My Library or added from search results — useful for checking what the repaired set actually says before you draft claims from it.