A paper pipeline that stops once, and traces every figure to a claim

One human confirmation, then the loop runs

The workflow is described as evidence-first, and the order is the design. It confirms the research question and feasibility, matches or supplements data and method capabilities, executes the analysis, checks whether the figures support the claims, and only then builds the manuscript, the citation audit, the discipline review, the independent review and the PDF release, all from one evidence version.

The human sits at exactly one point in that chain, and it is early. What comes back for confirmation is a bilingual research blueprint, a claim contract, the statistical requirements and a main-figure storyboard, gathered for one focused decision rather than for a stream of approvals.

That is the part that makes the rest possible. A claim contract and a figure storyboard mean the figures are planned before they exist, so when the analysis later produces something that does not support the claim, there is something to compare it against.

After confirmation the writing order is also fixed and slightly unusual: Results, then Introduction, then Data, then Methods, then Discussion, all composed from the same evidence, stage-owned code, formulas, figures and literature. Results first is the discipline the traceability requirement implies.

A main figure is traced through seven hops

The traceability claim is specific enough to check. Each main figure is traced to a research-plan claim, a cohort, a data plugin, a method plugin, a run output, an evidence ID and the applicable discipline rules.

Seven links, and each one answers a question a reviewer asks. Which claim does this figure support. Which subjects are in it. Which connector brought the data in. Which method template produced the analysis. Which run wrote the output file. What identifier the evidence registry holds. And which discipline-specific rules apply to it.

The capability table frames the same thing as a figure and panel contract, a figure-code trace, result validity and Result Support, with main and supporting figures, a result manifest and an evidence registry as the artefacts left behind.

The Data and methods row adds that code is stage-owned, and the runtime rows add that a read-only environment contract, native PDF-parser checks, system Git detection and isolated XeLaTeX, pdfLaTeX and BibTeX verification produce a verification receipt and bilingual environment reports. So the trace points at an environment that was itself checked, not at whichever machine happened to run it.

Two blind reviews before the hash is computed

The release path is a transaction and the ordering is deliberate.

Before any reviewer looks at the manuscript, the project audits citation support, bibliography format, discipline statistics, the semantics of the Results section and reproducibility. Only then do two independent blind reviewers inspect the manuscript. The results of that are reviewer reports.

Afterwards comes the author-completion transaction: authors, affiliations, ORCID, funding, acknowledgements, data and code links, references and precise paragraph revisions are all gathered into one packet, and only then is the hash-bound main.pdf released.

The blind review step is the part worth interrogating, because two reviewers on the same artifact is a small sample and a claim about independence that the tooling cannot enforce. What it can do is ensure that two reads happened and that both reports exist before the file is frozen, which is a narrower and more defensible claim than independent review as a process.

Freezing on a hash after the metadata is settled also means the artefact people cite is the one that was checked, rather than a later edit nobody re-read.

It will not run the code it finds

Two capabilities exist purely to keep third-party code out of the execution path, and together they are the most reassuring part of the design.

The first is metadata-first research-code sources, implemented since version 0.36. Retained literature can carry metadata-only GitHub and Zenodo code leads, DOI and version lineage, provider receipts and a stable literature work identity. The index distinguishes paper sources from code sources, and the documented boundary is that discovery does not download, install, execute, or turn a code lead into a citation or a plugin.

The second is safe archive inspection, also since 0.36. An archive download that has been separately confirmed is checked for checksum, path traversal, symlink and device entries, size and compression limits, licence consistency and static structure before any plugin promotion. The summary is blunt: third-party code is never executed by metadata enrichment or static inspection.

So the route to running someone else's code is: a person confirms the download, the archive is inspected, and promotion is a separate decision. That is three deliberate steps between a mention of a repository and code executing on your machine, and for a workflow whose whole premise is trusting artifacts, it is the right place to be strict.

Read the human page first and the audit JSON only on request

The checkpoint capability, implemented since version 0.35, decides what you see before you confirm anything. Before a human confirmation the project writes bilingual readable decision pages, an artifact manifest, the confirmation request, a DecisionBrief, a scientific fingerprint, a machine audit JSON and readability reports.

The presentation rule is the interesting half. The agent shows the readable page's project-relative and machine-absolute path first, then the semantic delta, the unresolved items and the meaning of the confirmation. Technical audit HTML is rendered from the JSON only when someone explicitly asks for it.

That ordering is a decision about what an audit is for. A machine JSON file is complete and unreadable; a human-facing page can be incomplete and still usable, because it can name the unresolved items instead of hiding them in a schema.

Paired with it is session-preflight, which binds the source checkout, the wheel, the interpreter, the command registry, the schema registry, the Skill copies and the plugin catalog before any project write happens. The provenance of the code doing the writing is established before the writing starts.

Literature resolves first and fetches only on demand

The literature capability, implemented since version 0.40, defaults to resolve_then_fetch_on_demand. Discipline-routed sources, NASA ADS and OpenAlex among them, discover candidates, and Core writes hash-bound identity receipts for what it resolves. The section describing that loop is cut off partway in the copy of the README available for this review, so the rest of the sequence is worth reading in the repository.

The wider table row lists what surrounds it: Zotero support, local PDF and structured import, symmetric discipline gates, paper identity resolution, on-demand full text, post-fetch review, score preservation, bilingual HTML and a citation audit, with identity and fetch receipts, an active snapshot, a quarantine area and a library.bib as the artefacts.

Two of those entries are doing quiet work. Score preservation means a search ranking survives into the later stages rather than being recomputed, and the quarantine area implies fetched material is not trusted on arrival. Combined with the resolve-then-fetch default, the sequence avoids both failure modes of automated citation work: citing something you never read, and re-running discovery so the same paper gets a different identity each time.

The licence is a non-commercial reference

This is the first thing to establish, because it changes who can use the tool. The package licence is written as LicenseRef-Draftpaper-NonCommercial, and the repository carries a COMMERCIAL_LICENSE.md next to the licence file. A custom SPDX-style licence reference is not a standard open source grant, whatever the repository description implies about a local research workflow.

The technical footprint is modest for something of this scope. Python 3.10 to 3.12, five core dependencies, Pillow, PyYAML, bibtexparser, pypdf and jsonschema, which is a list short enough to read in full and to audit yourself.

Everything heavy is an optional extra. The mcp extra adds the MCP server and pydantic. plotting adds numpy, pandas, matplotlib, SciencePlots, scipy, seaborn, scikit-learn and rapidocr_onnxruntime, and plotting-full adds marsilea, reportlab and scikit-plot on top. fulltext is a separate group of eighteen packages led by PyMuPDF and trafilatura, and browser brings cloakbrowser.

One detail is worth reading twice. The mineru and mineru-agent extras are declared empty, with a comment saying the official MinerU Agent connector is part of the core package and the compatibility alias intentionally installs no local model or GPU runtime. That is a dependency group that exists to satisfy an install command rather than to install anything.

v0.43.2 is released, and main has already moved past it

The version story needs two dates and the README gives both. The current release is v0.43.2, and the v0.43 series combines explicit literature admission, stronger research contracts, discipline-specific astronomy semantics and verified publication environments.

The tags are recent and close together: v0.43.0 on 2026-08-31, v0.43.1 on 2026-09-01 and v0.43.2 on 2026-09-08, with the last push on 2026-09-29.

That gap matters, because the README also says what main has added since: evidence governance with an edit-first and reconcile-later mode, readable checkpoint changes, recovery after successful plugin reruns, and change-aware CI. The README is explicit that these additions have not yet received a new release tag, and it points to a Recent Updates section for the distinction between released versions and current source.

So there are two legitimate installs and they are not the same software. If you want the trace and the audits described above, either line gives you them. If you want the newer governance mode, you are taking main and you are taking whatever else main contains.

Two other files are worth a look before you commit to it: COMPLIANCE.md at the root, and a file named Draftpaper_loop_code_audit_report.md, which is the project's own code audit sitting in the repository.

Editorial conclusion

Adopt Draftpaper-loop if you write papers where a reviewer will ask which run produced a figure and want that answer to exist before you submit rather than after, since the trace from figure to claim to run output to evidence ID is the whole point. Do not adopt it in a commercial context without reading COMMERCIAL_LICENSE.md, and do not adopt it expecting it to fetch and run someone else's research code, because discovery and execution are deliberately separate. Verify first which version you are installing, since the released v0.43.2 line and the newer work on main differ by a governance mode that has no tag yet.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. xiejhhhhhh/Draftpaper_loop on GitHub