LitCurate is a generic, config-driven literature-to-database pipeline. It turns a research goal into structured JSON from peer-reviewed papers, with checkpointing and resume so long runs can stop and continue safely.
It is not tied to one science domain. Domain knowledge lives in YAML configs, JSON/YAML schemas, and prompt files. The same codebase can support materials, biomedicine, or any other extraction task you define.
- Generate search queries from a user goal (LLM)
- Search the literature (OpenAlex)
- Rank and filter papers (rules + optional LLM screening)
- Download PDFs and convert them to markdown
- Extract structured records into your schemas (LLM)
- Export a single merged
database.jsonfor downstream ingest
Stages are independent CLI steps. You can run them one at a time, resume after failures, and re-run a single stage with --force when config changes.
| Idea | Meaning |
|---|---|
| Config over code | Goals, filters, models, schemas, and prompts are YAML/files — no Python changes for a new domain |
| Checkpoint / resume | Per-run SQLite ledger + artifact manifests; finished work is not repeated |
| Schema-shaped output | Extractions follow declared schemas; results are wrapped with provenance (model, time, validation) |
| Provider-flexible LLMs | Anthropic and OpenAI-compatible endpoints (e.g. local Ollama) per stage |
| Export for ingest | Final artifact is database.json: all successful papers and their schema envelopes in one file |
Teams that want a reusable literature curation engine as a dependency or sibling repo: clone LitCurate, install it, point a config at your schemas/prompts, and produce a database-ready JSON export. Experimental runs (specific topics, paper sets, or GPU servers) are usage, not part of the package identity.
- Python package
litcurate+litcurateCLI - Example configs, schemas, and prompts
- Tests and MIT license
Runtime outputs (runs/, PDFs, markdown, extractions) are not part of the package; they are created when you execute a pipeline.
Another project (database UI, analysis notebook, domain app) should treat LitCurate as:
- The producer of
database.json(and optional per-paper extraction folders under a run) - A tooling dependency installed via
pip install -e .(or from a published git tag) - Configured through its own YAML + schemas — not by hard-coding LitCurate internals
Downstream code should consume the exported JSON (or per-paper envelopes), not assume a particular scientific vocabulary beyond what that project’s schemas define.