Why We Built PACR
Oct 3, 2026
The idea for PACR started with a spreadsheet. Not a glamorous origin story, but an honest one.
It was a screening spreadsheet for a systematic review — 2,100 records exported from three databases, deduplicated badly, with columns for include/exclude, reason for exclusion, and a free-text notes field that had become a graveyard of half-sentences like "check methods section" and "same cohort as #418?" Three of us were working on it. Two of us had different versions. The notes one of us wrote in a PDF reader never made it into the sheet at all, because PDF annotations don't travel.
Nothing about that was unusual. That is what made it worth fixing.
The real cost isn't the tools, it's the gaps between them
Most researchers have perfectly good tools. A database to search. A reference manager. A PDF reader. A notes app. A writing environment. A collaboration tool. A submission portal. Each one, taken alone, usually does its job.
The problem is that none of them know about each other. Every time you move between them, you pay a small tax: you re-explain your context, re-find the paper, re-type the citation, re-read the thing you already read three weeks ago because the thought you had about it lives somewhere you can't remember.
Individually these costs are trivial. In aggregate they are the job. Think about a normal week:
You run a search, scan abstracts, and open fifteen PDFs in browser tabs.
You read eight of them properly and annotate them in a reader that doesn't sync to anything else.
You write a paragraph of synthesis in a document that has no idea which papers you just read.
Your co-author comments on that paragraph asking "which study is this from?" — and you go back and re-find it.
Three months later, a reviewer asks whether you considered a specific 2019 trial. You cannot remember whether you excluded it deliberately or never saw it.
The knowledge didn't disappear. It got distributed across five applications in formats that don't talk to each other, and the only integration layer was your memory.
Why context loss is a methodological problem, not just an annoyance
It's tempting to file this under "inconvenience." It isn't. Reproducibility and transparency standards — the kind codified by the EQUATOR Network reporting guidelines and the PRISMA statement for systematic reviews — assume you can reconstruct your decisions. How many records did you screen? Why was each one excluded? What was your search string, exactly, and on what date?
Anyone who has tried to write a PRISMA flow diagram six months after screening knows that reconstruction is often archaeology. You are not recalling your process; you are inferring it from artifacts. The tooling didn't fail you dramatically. It just never captured the reasoning in the first place, because the reasoning happened in the gaps.
We built PACR on a simple premise: if the steps of research were connected, the record would create itself as a byproduct of doing the work.
The second problem: closed networks
The other half of the story is access — and not only in the paywall sense, though that matters too.
Research has always run on networks. Who you trained with, which department you landed in, whose lab is down the corridor, which conference you can afford to attend. Those networks determine which papers get recommended to you, which collaborators you find, which preprint lands in your inbox before it lands anywhere else, and often which journal editor recognizes your name.
If you're a postdoc at a well-resourced institution with a well-connected PI, those networks are an accelerant. If you're a clinician doing research in the evenings, a PhD student at a smaller university, or a researcher in a low-resource setting, they're a wall. The World Health Organization and funders worldwide have spent years pointing out how badly global research output skews toward a handful of countries and institutions. Part of that is funding. A meaningful part is infrastructure and access.
Open access has helped enormously — the growth of the Directory of Open Access Journals and preprint culture has genuinely changed what's readable. But readable isn't the same as findable, and findable isn't the same as usable. A corpus of 40 million open papers you have no efficient way to search, filter, read, and synthesize is a library with no catalogue.
What "closed" actually looks like day to day
It rarely looks like a locked door. It looks like:
Not knowing that a group in another field solved your methods problem in 2021, because their journal isn't in your reading rotation.
Spending a week building a search strategy that a librarian could have built in an hour — if your institution still had a research librarian.
Submitting to a journal because a senior colleague mentioned it, with no systematic way to assess fit, scope, or legitimacy. (Resources like Think. Check. Submit. exist precisely because this is a widespread problem.)
Writing a paper that quietly duplicates work already published, because nobody in your immediate network happened to see it.
Scattered tools and closed networks are the same problem viewed from two angles. Both are failures of connection.
What we set out to build
PACR is an AI-native research workspace. The phrase does some work, so let me be precise about what we mean by it.
Workspace means the whole arc lives in one place: finding and reading literature, summarizing it, writing, collaborating with co-authors, and getting to publication. Not a tool that handles one stage and exports to the next, but a single environment where those stages are the same environment.
AI-native means the AI isn't a sidebar bolted onto a document editor. It has access to the context of your project — what you've searched, what you've read, what you've written, what you've decided — because all of that is in the same system. An assistant that can see your corpus and your draft is a materially different thing from one that can see neither.
The outcome we care about is compression: moving from a first search to a finished manuscript in a timeframe measured in hours and days rather than months, without cutting methodological corners. Speed that comes from eliminating redundant work is good speed. Speed that comes from skipping steps is not, and we're not interested in building that.
A concrete example of what connected means
Imagine a clinical fellow investigating whether a particular intervention improves outcomes in an older patient population. Here's how that goes in a connected workspace.
Search. She describes what she's looking for in plain language and refines from there — adjusting population, comparator, study design, and date range as the result set tells her what's actually out there. She can run the same question against literature she'd never have thought to search, because the search isn't limited to the three journals she reads.
Triage and read. She skims AI-generated summaries to decide what deserves a full read, then reads the ones that matter inside the same workspace. Her highlights and notes attach to the paper and stay attached.
Synthesize. When she asks what the included studies agree and disagree about on a specific outcome, the answer is grounded in the papers she selected — not in a general model's recollection of the literature. She can trace each claim back to its source.
Write. She drafts in the same place. Citations are already there because the papers are already there. When she writes "three trials reported no significant difference," the system knows which three.
Collaborate. Her supervisor opens the project and sees the search strategy, the screening decisions, the annotated papers, and the draft — together. His comment about a questionable exclusion sits next to the exclusion itself, not in an email thread.
Publish. Formatting, reference styling, and submission preparation happen from the same project, against the same source material.
At no point does she export, re-import, re-explain, or re-find. That's the whole idea. You can see how the search and discovery side fits into this, and how the workspace itself holds the project together.
What we deliberately didn't build
Two things, both of which we've been asked for.
We didn't build a system that writes your paper for you. Generated text that isn't anchored to real, verifiable sources is a liability — for you, for your co-authors, and for the record. The ICMJE recommendations and COPE guidance on AI use both converge on the same principle: authors are accountable for every claim in their manuscript. A tool that makes it easier to publish things you haven't verified is making the wrong thing easy. We built for traceability — every synthesized statement should lead back to a paper you can open and check.
We also didn't build another silo. It would have been commercially convenient to make PACR a walled garden where your work is hard to take elsewhere. Research infrastructure that locks people in is part of what's wrong with the current ecosystem. Your work is yours.
The reproducibility dividend
One benefit we expected but underestimated: when the workflow is connected, the audit trail is free.
Your search strings are recorded because you ran them in the system. Your inclusion and exclusion decisions are recorded because you made them there. Your annotations sit with the papers they describe. When you need to report your methods — for a PRISMA diagram, a registered protocol, a grant report, or a reviewer who wants to know why you excluded a 2019 trial — the answer exists, timestamped, without anyone having reconstructed anything.
This is the same logic behind persistent identifiers like ORCID and trial registration through ClinicalTrials.gov: make the record a structural property of the process rather than a document someone has to remember to write.
Who this is for
PACR is built for people who do research as their actual job, with all the constraints that implies. The PhD student in year two with a confirmation review approaching. The postdoc running three projects because that's what the funding structure demands. The clinician who gets four hours a week for research and loses most of it to administration. The faculty member supervising six students who all need feedback on drafts referencing literature she hasn't read yet.
These people are not short on expertise. They are short on time, and a surprising fraction of what consumes that time is mechanical: re-finding, re-formatting, re-explaining, re-reading. We think a large portion of that is removable, and removing it is not a trivial improvement. It's the difference between finishing a project and shelving it.
We're not claiming the hard parts of research get easier. Framing a good question, designing a study that can answer it, interpreting ambiguous results honestly — none of that is automatable, and we'd be suspicious of anyone who said otherwise. What we're claiming is narrower and, we think, more useful: the work around the thinking should stop eating the time available for thinking.
If any of this sounds like your week, the most direct way to judge it is to run a real question through it. Bring something you're genuinely working on — a search you've been putting off, a pile of PDFs you've been meaning to synthesize — and start a project in PACR. If you already have an account, your workspace is where you left it when you log in.
We built this because we got tired of the spreadsheet. We suspect you are too.
