re-search.ai: How I Built a Copilot for Research Novelty
There is a specific kind of anxiety that anyone who has submitted an academic paper will recognize. You've spent months on an idea, run the experiments, written the draft — and then, the night before submission, you find a paper from 2021 that does almost exactly what you did. Or worse: a reviewer finds it for you, in public, in the form of a rejection.
The research process has a quality control problem at its earliest stage. The moment when you decide whether an idea is worth pursuing — whether it's genuinely new, whether it addresses a real gap, whether it will survive peer review — is the moment when you have the least information and the least tooling to help you.
re-search.ai was built to fix that specific moment.
The Problem Is Worse Than It Looks
On the surface, assessing novelty sounds like a literature review problem. Read enough papers, and you'll know what's been done. But in practice, the academic literature is too large, too fragmented, and too fast-moving for manual review to keep up with — especially at the frontier of active fields like machine learning, computational biology, or NLP, where a relevant preprint can appear and accumulate hundreds of citations within weeks.
The deeper problem is structural. A literature review tells you what exists. It doesn't tell you why your angle is different, whether that difference is meaningful enough to constitute a contribution, what experiments would demonstrate it, or which venues would consider it publishable. It gives you raw material but leaves all the analytical work to you — and that analytical work is exactly where most early-career researchers (and many experienced ones) struggle most.
Current tools don't help much. Search engines return papers ranked by relevance to keywords, not by their relationship to your specific contribution. Citation networks show you what cited what, but not whether anyone has tried your approach. AI assistants can summarize papers, but they hallucinate citations and don't have a structured model of what novelty actually means in a research context.
What was missing was a tool that could take a raw research idea and produce a structured analysis: here is what exists, here is what doesn't, here is where your idea sits relative to the frontier, and here is what you'd need to demonstrate to make the contribution credible.
What re-search.ai Does
The entry point is deliberately minimal. You describe your research idea — it can be a sentence, a paragraph, or a rough hypothesis. There's no required format. The system is designed to work with the kind of half-formed thinking that characterizes early-stage research, not polished abstracts.
From that input, the pipeline does several things in sequence.
Literature mapping. The system retrieves papers relevant to your idea — both foundational work that establishes the conceptual background and frontier work that represents the current state of the art. These are separated deliberately, because the relationship between them is analytically important: foundational papers define the problem space; frontier papers define what solutions already exist. The gap between "what the frontier has tried" and "what your idea proposes" is where novelty lives.
Gap analysis. The system synthesizes across the retrieved corpus to identify where the literature is silent, where it's contested, and where it's saturated. A saturated area — one where multiple groups have converged on similar approaches with similar results — is a weak place to contribute. A genuinely open area, where the problem is recognized but the solution space is unexplored, is where a novel contribution can land.
Direction generation. Rather than returning a single verdict, the system generates multiple ranked research directions based on your idea. Each direction comes with a specific hypothesis (falsifiable, not vague), a rationale explaining why this direction represents a real gap, a set of suggested experiments, and a list of must-beat baselines — the specific prior methods any reviewer will expect you to compare against. This last point is often underestimated: knowing your baselines before you design your experiments lets you build a methodology that actually answers the question reviewers will ask.
Idea critique. Each direction also includes a candid critique — the strongest objection a skeptical reviewer would raise. This is not there to discourage. It's there because hearing the hard question before you start is dramatically more useful than hearing it after you've committed three months to the work.
Venue recommendations. The system recommends publication venues matched to the type and scale of the contribution. This is more consequential than it might seem: submitting to the wrong venue is one of the most common and avoidable causes of rejection.
The Paper Writing Pipeline
The novelty report is only the first half of what re-search.ai produces. Once you have a direction you want to pursue, the system helps you write the paper — not as a template or a fill-in-the-blank exercise, but as a coherent academic document drafted in full.
The paper is structured as four sections: Introduction, Methodology, Results, and Discussion. Each can be generated independently, and each accepts optional researcher notes that get treated as ground truth — if you have actual findings, actual numbers, actual experimental details, you provide them and the system integrates them faithfully. If you're at the planning stage and don't yet have results, the system generates the section with explicit placeholders that signal to you exactly what you still need to fill in.
The part that required the most engineering care was making the sections coherent with each other. A naive implementation generates each section independently from the same context — the novelty report, the corpus, the hypothesis — and what you get are four sections that each describe a plausible paper, but not the same paper. The Introduction might use one framing for the contribution; the Methodology might set up experiments for a subtly different hypothesis; the Discussion might refer to results the Results section didn't claim. Each section sounds fine in isolation; together, they read as incoherent.
The fix was cross-section context injection. When generating any section, the system first fetches all other sections that have already been written for this project, in order, and injects them into the prompt under an explicit instruction: your output must be consistent with these — same terminology, same hypothesis, same baselines, same contribution framing, same voice. The Methodology sees the Introduction and knows exactly what contribution it's setting up an experiment to test. The Results sees the Methodology and knows which baselines to compare against. The Discussion sees all three and knows what findings it's interpreting.
The output is exportable as LaTeX — structured, correctly sectioned, ready to drop into a conference template.
Why the Architecture Is Built the Way It Is
A few technical decisions are worth explaining because they reflect real constraints that any serious research tool faces.
The LLM harness is entirely environment-variable driven. The model name, API endpoint, API key, and authentication scheme are all configurable without code changes. This matters because the research community doesn't converge on a single model provider — different groups have access to different APIs, different institutions have different contracts, and the landscape changes quickly. Building in hard dependencies on a specific provider would make the tool unmaintainable within months.
All reports and paper sections are versioned and stored. This is not just for persistence — it's for correctness. When the system fetches sibling sections to inject as context, it fetches the latest version of each section, not an arbitrary one. If you regenerate the Introduction with new researcher notes, the next time you generate the Methodology, it will see the updated Introduction. Version history also means you can regenerate a section without losing the previous draft, which is important when you're iterating on framing.
The job system for generation is asynchronous with real-time polling. Long-form LLM generation takes time — sometimes several minutes for a complete paper section — and blocking the HTTP request for that duration is not viable. The system creates a job, returns immediately with a job ID, and the frontend polls for completion. This lets the UI stay responsive and give meaningful progress feedback without a WebSocket infrastructure.
What This Is Actually Useful For
The most direct use case is early-stage novelty assessment. If you have an idea and want to know, before committing significant time, whether it's genuinely new and whether it's positioned correctly — re-search.ai gives you a structured answer in minutes rather than weeks.
But there's a second use case that emerged during development: sanity-checking ideas you've already committed to. Researchers frequently discover mid-project that a related paper exists, or that their framing is weaker than they thought, or that a baseline they didn't include is the obvious first question any reviewer will ask. Getting that analysis earlier — even mid-project — is better than getting it at rejection.
The paper writing pipeline is most useful for the structural work of a draft: getting the contribution framed correctly, the methodology organized logically, the results presented in a way that clearly answers the hypothesis, the discussion grounded in what the results actually show. It's not a replacement for the researcher's domain knowledge and actual findings; it's scaffolding that lets those things land more clearly.
What I Learned Building This
The gap between "the model produces the right kind of text" and "the model produces a coherent document" is larger than it looks. Getting each individual section to be high quality was not especially hard. Getting the four sections to read as one paper required explicit cross-referencing at inference time — you cannot rely on the model to infer consistency from shared context alone. The more explicit the instruction ("use the exact same hypothesis as stated in the Introduction you have already read"), the more consistent the output.
The second lesson is about the value of structure in research analysis. The novelty report is not just a summary — it's a structured decomposition into specific fields: hypothesis, rationale, experiments, baselines, critique, venues. Each field serves a different purpose in the research process, and having them separated makes the analysis actually usable, rather than a wall of text you have to re-interpret yourself. Structure is what turns an LLM output into a tool.
The version of research support that exists today — search engines, citation databases, AI chat assistants — treats research novelty as a retrieval problem. Find the relevant papers and you'll know whether your idea is new. re-search.ai treats it as an analysis problem. The papers are inputs, not outputs. What you actually need is a structured account of what those papers collectively imply about where your idea sits, what it would need to demonstrate, and whether it's worth pursuing. That's what I built.