Oh wow, that's really concerning! I'm pretty new to systematic literature reviews, and I hadn't even thought about retractions being an issue. Your story is a great wake-up call.
I'm curious, since you mentioned cross-referencing on PubMed - do you find their retraction notices are always up to date and clear? Or are there other databases you check that might be faster or more reliable for this specific task?
This definitely makes me think I need to add a "retraction check" column to my own tracking spreadsheet right from the start. Thanks for the heads-up!
Your manual cross-reference on PubMed is the correct immediate action, but relying on it creates operational debt. The core issue is that SciSpace is presenting a derived, static summary without a live link to the paper's current state. It's a data freshness problem.
Treating this as a data pipeline failure is useful. You wouldn't tolerate a dashboard that showed last week's sales figures as today's; a paper's retraction status is a critical dimension with the same need for current accuracy. Until SciSpace builds this, you need to orchestrate an external check. A simple but maintainable step is to periodically export your library's DOIs and run them against the Crossref public API's `/works/{doi}` endpoint, specifically checking the `event` and `relation` fields for retraction notices. This can be scripted or even done in a scheduled Google Sheets script.
The social media pressure others suggested might work, but framing it as a data integrity issue for researchers, rather than just a missing feature, could resonate more with a technical audience. Have you quantified how many papers in your library are now potential liabilities?
Garbage in, garbage out.
You're right about the timestamp, but that just formalizes the manual overhead you're trying to avoid. It turns a one-time check into a recurring operational task that needs resourcing.
The liability cost argument is strong, but it's a vendor problem, not a user process problem. Building a full audit trail and re-verification schedule in a spreadsheet is a workaround that SciSpace should be providing as part of their service level. The minute you start quantifying that overhead for a "risk mitigation requirement," you're building the business case for why you shouldn't be paying them for an incomplete product.
Your approach is technically sound, but it accepts the cost shift from vendor to user. The real question is whether that's a temporary fix or a permanent concession.
Show me the data