Turning a research idea into a complete paper requires more than text generation: the system must retrieve literature, design and execute experiments, revise claims according to evidence, produce publication-ready figures, and maintain consistency across a long generation process. We present Spark-to-Paper, an end-to-end research paper generation system implemented as thirteen composable skills inside an existing coding assistant, without requiring a separate agent platform or orchestration service. Spark-to-Paper separates model-based judgment from deterministic operations that can be directly executed and checked. It further separates experiment planning from reporting, so that required evidence is specified before results are observed and manuscript claims are revised according to measured outcomes. To improve reliability over long research trajectories, the system combines deterministic integrity checks with self-critique and bounds a failure mode we call the Self-Refutation Loop, in which repeated experiments continue to reject the original research objective. Spark-to-Paper also produces editable vector figures through programmatic plotting for experimental results and code-based reconstruction for generated method diagrams. Across eight controlled research topics, Spark-to-Paper achieves 99.5% citation validity and 96.4% figure editability. A controlled ablation increases fabrication detection from 14% for a single-pass draft to 92% with the full integrity and review stack, while adversarial review achieves 74% precision. The full system uses 11.9M tokens, costs $8.1 per manuscript, and requires 3.2 hours on average. These results show that end-to-end research paper generation can be implemented as a lightweight, composable workflow inside existing coding assistants while keeping experimental evidence central to how claims are accepted, revised, or abandoned.
Alex: Welcome to another episode of ResearchPod. Today, we're looking at Spark-to-Paper, a system designed to automate scientific writing—from the initial idea all the way to a finished draft.
Sam: The central puzzle it's trying to solve is this: how do you turn a research idea into an accurate paper without the AI making things up? Current AI models often act like black boxes. They can produce fake results, invent citations that don't exist, or present confident-sounding nonsense as fact.
Alex: So this is about building a reliable assistant—one that's actually anchored to real evidence rather than just predicting whatever sounds plausible?
Sam: Exactly. Think about how research actually works. It's a cycle: you plan, you run experiments, you check the results, and you revise. If an AI system isn't forced to prove its claims with actual data at each step, it tends to drift—filling gaps with guesses rather than facts.
Alex: Like a student who guesses their lab results to make their hypothesis look good?
Sam: That's a good way to put it. To fix this, the system uses thirteen "composable skills." Think of these like apps on your phone—each one does a specific job. There's a "cite" skill for finding references, a "plot" skill for generating figures, and so on. Instead of one giant AI trying to do everything at once, the work is broken into manageable, verifiable chunks.
Alex: So each chunk can be checked independently. If the citation tool finds a real paper, you know that step worked—regardless of what the rest of the AI is doing.
Sam: Precisely. And the key innovation is how the system handles evidence before an experiment even begins. It writes down exactly what proof it would need to support its claim—almost like signing a contract with itself. It commits to the standard of evidence upfront, before it sees any results.
Alex: A scientific contract. But what happens if the experiment fails? Does it just ignore the bad news and write a positive paper anyway?
Sam: That's where the design gets genuinely interesting. A lot of AI agents fall into what you might call a "self-refutation loop"—they keep pushing the same failed approach because they're optimized to produce a finished output, not an honest one. Spark-to-Paper is built differently. If a test contradicts the hypothesis, the system stops, writes a formal failure report, and returns to the planning stage. It treats failure as a legitimate scientific outcome.
Alex: So it's designed to be honest about failure, rather than quietly fudging the data to make things look better.
Sam: That's the goal. And to enforce it, the system uses what the paper calls "deterministic gates." These are hard-coded rules—not AI judgment calls—that check objective facts. Did this citation actually exist? Does this code actually compile and run? If the answer is no, the gate blocks progress. The AI can't talk its way past a gate the way it might talk its way past a softer check.
Alex: How does that apply to figures? I've seen AI-generated charts that look polished but are impossible to trace back to any real data.
Sam: That's a known problem, and the system addresses it directly. Every chart or graph is produced by code—not drawn by the AI from memory. The code runs on the actual experimental data, so the figure is always a direct output of real numbers. If the data changes, the figure changes automatically. There's no gap where the AI could substitute a plausible-looking result for a true one.
Alex: It's a meaningful separation—the AI decides the strategy, but the code does the actual work. And because code either runs correctly or it doesn't, there's no room for the model to quietly bend the truth.
Sam: Right. And the same logic applies to citations. Before any reference makes it into the paper, the system retrieves the actual source and verifies it exists. It's a "retrieve, then verify" approach—the paper is built on confirmed evidence, not on what the model thinks it remembers reading.
Alex: So the overall picture is less "AI as author" and more "AI as lab manager"—coordinating the process, but bound by the same standards a human scientist would be held to.
Sam: That's a useful frame. It plans the work, runs the checks, and accepts that experiments can fail. The integrity of the final paper is tied to the verifiable outputs of the process, not to the AI's confidence in its own answers.
Alex: You mentioned that it treats failure as a valid outcome. That seems like the most significant design choice here. Most AI tools are built to please the user—which usually means producing something that looks finished, whether or not it's accurate.
Sam: Exactly. By building in a stop condition—where contradictory evidence forces a pause rather than a workaround—the researchers have embedded a form of intellectual honesty into the system. The goal isn't to reach a finished paper. The goal is to reach a true paper.
Alex: What are the limitations, though? If the system relies on the model's own reasoning to diagnose failures, couldn't it still miss a deeper flaw in the original research design?
Sam: That's a fair point, and the authors acknowledge it. The system is still bounded by the underlying model's reasoning ability. If the initial logic is flawed in a way the model can't detect, the self-critique may not catch it. It's a tool for procedural integrity—it can't substitute for genuine human insight into whether the research question itself is well-formed.
Alex: A guardrail, not a replacement for scientific judgment.
Sam: That's the right way to think about it. What it does offer is a more reliable foundation. Future systems built on this approach could manage entire data pipelines—flagging when new results contradict established literature, or when an experiment's assumptions no longer hold. The direction is toward AI as a partner in the rigor of research, not just the production of it.
Alex: That's a clear and useful distinction. Thanks for walking through the mechanics, Sam. That's our look at Spark-to-Paper. Thanks for listening to ResearchPod.