Your Research Team Saved the Same Papers Five Times: Cleaning a Shared Library Without Losing the Evidence Trail

A shared library that has been growing across a manuscript draft, a revision, and a grant summary rarely fails loudly. It fails quietly: the same randomized trial appears as a preprint, a conference abstract, and the final journal article; two co-authors saved the same DOI under different titles; a review's reference list was imported wholesale alongside the primary studies it cites. When you finally run a count for your methods section, the number is wrong, and nobody can reconstruct why.

This article walks through a concrete repair of that situation for a research team preparing a manuscript and its evidence summary. The goal is not a pristine library for its own sake. The goal is a defensible one: every retained record can be traced to a search, every merge can be explained, and every collection and tag rule reflects a decision someone made on purpose.

Imagine a team writing up a systematic review of an intervention. Over several months, four people added papers. The library now holds 412 records. The team's draft claims "412 studies were identified." That sentence is the first casualty.

Three distinct problems are tangled together:

• Duplicate records. The same article was saved more than once, often because it was found through different searches or imported from different sources.
• Related reports of one study. A single trial may have a protocol, a conference abstract, and a full report. These are genuinely different records describing one study.
• Loose collection and tag habits. Records sit in overlapping folders, tags mean different things to different people, and nothing records which search each record came from.

Cochrane's guidance on searching and selecting studies is useful here because it treats these as separate steps: plan searches from eligibility criteria, use multiple sources, document the process, deduplicate records, screen in stages, and link multiple reports of one study. That structure is the backbone of the repair below.

Before changing anything, record what you have. Export the full library, including whatever metadata your tool stores, and save it with a date. This baseline is what lets you say later, "we started with 412 records and ended with 268 unique studies plus 31 linked reports."

At this stage, do not delete. The temptation is to start removing obvious duplicates immediately, but a merge you cannot reverse is a merge you cannot defend in a methods appendix or a response to reviewers.

If your team works inside a shared paper library, this is the moment to confirm that everyone is looking at the same saved set. In WisPaper, My Library is where saved and uploaded papers are organized, so the baseline export and the subsequent cleanup happen against one shared collection rather than four personal ones.

This is the decision that most often goes wrong. A duplicate and a related report can look identical in a reference manager: same authors, similar titles, close years.

Use a simple test:

• Duplicate: the same work, recorded twice. Same DOI, same publication, same content. Merging is safe and desirable.
• Related report: a different document about the same study. A protocol, an abstract, a secondary analysis, or a follow-up report. These should be linked, not merged.

Cochrane's handbook explicitly distinguishes deduplicating records from linking multiple reports of one study. Collapsing a protocol into its final report destroys information a reader may need, and it can make your study count look cleaner than your evidence actually is.

A practical rule for the team: merge only when the identifier matches. When identifiers differ but the study appears to be the same, create a link and a note rather than a merge.

Safe merging has three parts: a match criterion, a survivor record, and a log.

Match criterion. Decide in advance what counts as a duplicate: matching DOI, matching PMID, or matching title-plus-author-plus-year when no identifier exists. Write the rule down before you start, because the rule is what a reviewer will ask about.

Survivor record. When two records merge, choose which one survives based on completeness, not on who saved it first. Keep the record with the fullest metadata and the correct identifier.

Log. For every merge, record the records combined, the criterion used, and who did it. A simple spreadsheet column set — date, records merged, reason, initials — is enough. This log is your auditable method trail, and it is far easier to maintain during cleanup than to reconstruct afterward.

PubMed's search details, which show how terms were translated and combined, are a reminder that search provenance is itself evidence. Preserve the search string or saved search that produced each batch of records so the merge log can point back to it.

Once duplicates are resolved, organize by the structure of the deliverable, not by personal preference. For a manuscript with an evidence summary, a workable scheme is:

• Included studies — one entry per study, with linked reports attached.
• Excluded at full text — with the reason recorded, since screening in stages means exclusion reasons matter.
• Background and methods citations — sources that support framing but are not part of the evidence base.
• Pending — anything awaiting a second screener.

Name collections so a new team member can guess their purpose. "Final," "misc," and "important" are not collections; they are future cleanup work.

Tags fail when they are adjectives. They succeed when they are facts about a record that a reader could verify.

Adopt a small, closed tag vocabulary and document it:

• Study design (e.g., randomized trial, cohort, qualitative).
• Report type (primary report, protocol, abstract, secondary analysis).
• Screening status (included, excluded, pending).
• Source search (which search or database batch the record came from).

Keep the list short enough that people actually use it. A tag nobody applies is worse than no tag, because it implies coverage that does not exist.

A cleaned library is only half the deliverable. The other half is the record of how it was built. Cochrane recommends documenting the search process and rerunning searches before publication, and that advice maps directly onto a shared library: your collections should be reproducible from your documented searches.

If the team needs to re-run or extend a search to catch records added since the last sweep, use a scholarly search interface and save the queries. WisPaper search is the entry point for finding academic papers through WisPaper's scholarly search interface; for a public explanation of that capability, the Scholar Search page describes finding academic papers. Save each query alongside the batch it produced so the merge log and the collections stay connected.

When the search needs to be more than a single query — for example, assembling a literature review section or checking whether a claim is already covered — the Scholar Agent area supports longer research tasks including literature review work. Use it to generate candidate records, then route those candidates through the same deduplication and tagging rules as everything else. A new source of records does not get a shortcut past the log.

Library cleanup fixes your internal record. It does not automatically fix the bibliography in the manuscript. After merging, check that every in-text citation still points to a surviving record and that no merged-away duplicate left an orphan reference.

For BibTeX-based manuscripts, TrueCite checks BibTeX against real academic databases to flag hallucinated references. Running it after a merge is a sensible sequencing choice: you want to verify the citations that survived cleanup, not the ones you were about to remove.

Once the library reflects one entry per study with linked reports, it becomes useful for more than counting. Teams preparing a revision often need to ask what a set of saved papers says about a specific outcome or method.

Library QA supports asking questions based on papers uploaded to My Library or added from search results. The order matters: clean first, then query. Questions asked of a library with five copies of the same trial will tend to return answers weighted toward whichever copy was saved most often.

After the repair, the team's methods paragraph can say something specific and checkable: the searches run, the number of records retrieved, the number of duplicates removed under a stated criterion, the number of studies included, and the number of linked reports attached to those studies. The library itself carries the trail: collections named for the manuscript structure, tags drawn from a closed vocabulary, and a merge log that ties each decision to a search batch.

The draft sentence "412 studies were identified" becomes a sentence about records and studies, which is what the evidence actually supports.

• Count records and studies separately from day one. The distinction is easy to lose and hard to reconstruct.
• Merge on identifiers, link on studies. Related reports are evidence, not clutter.
• Write the merge rule before merging. A rule applied consistently is defensible; a series of judgment calls is not.
• Keep the log during the work. The method trail is a byproduct of doing the cleanup carefully, not a separate writing task.
• Let the deliverable shape the collections. Organize around the manuscript's structure so the library and the paper stay in step.
• Re-run searches before you finalize. A library frozen at the last search date is a library that may already be out of date.