Question to report
Configure a PICO/PECO-style question, search PubMed, screen records, retrieve full text, extract, appraise, synthesize, verify, and render the report.
View pipelinePubMed-centred research workflow
Use it for full literature reviews, manuscript-oriented evidence projects, and lightweight one-paper or selected-paper summaries — all backed by immutable source snapshots, character-offset extraction spans, and appraisal records that a script re-checks rather than a reader trusting.
Configure a PICO/PECO-style question, search PubMed, screen records, retrieve full text, extract, appraise, synthesize, verify, and render the report.
View pipelineWrite-once snapshots, character-offset spans, an append-only retrieval log, and an assembler that re-slices every excerpt instead of trusting one. Agent-written text is never itself evidence.
View evidence kernelCreate a repo with canonical paper metadata, source snapshots, reusable extractions, project-scoped appraisals, manuscript files, and exports.
View architectureSummarize one paper or a user-specified set by reusing the same registry, extraction, appraisal, and verifier machinery without running a full review.
View summariesRanked full-text and facet search over the registry, questions answered from papers you already hold with span-verified citations, saved PubMed searches that report what's new, personal tags/star-ratings/notes, and a bridge into an OKF knowledge-graph bundle.
View reference managerReadCube is the library UI and PDF viewer, not deep-research. Prepare a RIS + PDF import bundle from the registry, with checksum-verified staged publishing and incremental re-export.
View ReadCube export| Need | Use | Output |
|---|---|---|
| Literature review or evidence synthesis | Full Stage 0-8 pipeline | Verified report, evidence table, PRISMA flow, optional HTML/PDF/docx |
| One article summary with appraisal | /deep-research:summarize | Single-paper summary plus appraisal and verification |
| Several specified papers | /deep-research:summarize-set | One summary per paper plus optional bounded overview |
| Just the structured data, no write-up yet | /deep-research:extract | Verified extraction fetched and promoted into the registry — no appraisal, no summary |
| A question answered from papers you already hold | /deep-research:ask | An answer built only from spans that still verify — not a literature search |
| A reusable extracted-paper pool, no report | A run with pipeline.stop_after_stage: 5 | Extractions every later run reuses instead of redoing |
| Manuscript project without wiki-manager | /deep-research:init and /deep-research:project create | Standalone project, reusable paper pool, exports |
your question papers you already have
│ │
▼ ▼
┌───────────────┐ ┌───────────────────┐
│ Stage 0-8 │ ─── extractions ─▶ │ canonical store │ ◀── summarize / summarize-set
│ pipeline │ ◀── reuse ──────── │ registry.jsonl │
└───────┬───────┘ │ extractions/ │ ──▶ search · ask · annotate
│ │ appraisals/<p>/ │ ──▶ bib · RIS+PDF · OKF bundle
│ └─────────┬─────────┘
▼ │
report · digest ▼
verification.json data/sources/ snapshots + events.jsonl
(every span re-sliced from here, twice)
Work done once is available everywhere. A paper extracted by a review is reused by a later one-paper summary; a paper registered for a summary is already in the pool the next review seeds from. Appraisals are the deliberate exception — they are scoped to the project whose question they answer.
Scientific claims flow through structured records: source snapshot → extraction span → appraisal domain → summary record → verification. The tool does not free-form summarize from a PDF when a structured extraction should exist, and it does not let an agent supply its own quotation. Every excerpt in a finished artifact was cut from an immutable snapshot by a script — once at assembly, once at publish.
| # | Rule |
|---|---|
| 1 | No PubMed-backed claim without a PMID actually retrieved this run. |
| 2 | No claim from any source without a retrieved evidence id: PMID, DOI, PMCID, preprint DOI, guideline URL, report URL, or bundle-relative concept path. |
| 3 | Abstract-only vs. full-text is tagged on every extraction. Abstract-only is never appraised as if full text. |
| 4 | Null and negative findings are actively searched for. Screeners must not exclude on outcome positivity. |
| 5 | Conflicts are surfaced with an explanation, never averaged away. |
| 6 | "New insights / hypotheses" is hard-walled from "what the evidence shows". |
| 7 | Retracted and Expression-of-Concern papers are flagged at screening and at every point of use. |
| 8 | PubMed attribution is honored: cite PubMed and DOIs. |
| 9 | No paywall circumvention of any kind. No credentials, sessions, proxies, captcha solving, or mirrors; no retrying a 401/402/403 by another route. Fail closed. |
| 10-11 | Bundle concepts preserve full PubMed metadata; per-claim attribution uses footnotes keyed to source ids. A body-only citation list is not acceptable. |
| 12-13 | The wiki's own wiki/ tree is never written to; standard markdown links are the graph layer, wikilinks additive only. |
| 14 | Unknown values are null. Never invent a bibliographic field, a number, or a citation. |
| 15 | Whenever a PDF is handed to you, its DOI is stated alongside the PMID — or the absence of a DOI is stated. |
| If you are… | Read |
|---|---|
| Setting up for the first time | Quickstart — prerequisites, a real repo, a first summary, and a troubleshooting table |
| About to ask a research question | Scientific questions — pick the framework before searching, not after |
| Running or debugging a review | Full pipeline — every stage, every gate, every failure mode |
| Wondering whether to trust a quote | Evidence kernel — how a claim is made checkable |
| Deciding where papers and judgements live | Repo architecture — source of truth vs. derived, and what a backup must contain |
| Looking for a flag | Command reference, then python3 scripts/<name>.py --help |