Living Research Objects

Turn published research into living, verifiable knowledge.

LROHub turns a published paper into an LRO — every claim anchored to the sentence that proves it, every figure carrying its source, and the whole object re-checked on a schedule when the paper behind it is corrected or retracted.

Want the full tour first? Explore the platform story

What you get

Production-ready

Grounded extraction with evidence spans and confidence.

Human-in-the-loop review and auditable provenance ledger.

Publisher workflows for ingestion, curation, and publishing.

For visitors

Below: architecture pillars, end-to-end pipeline, comparison matrix, roles (publisher through admin), REST automation overview, and four onboarding steps. Sign in to use the app and open the in-app Product guide from the sidebar.

One-line pitch

“Every paper becomes an executable, auditable continuously‑learning knowledge object.”

Architecture

Six foundational pillars

Each pillar is a defensible, production-wired capability that compounds with the others.

These pillars describe the LROHub north star. Deployments ship a growing subset — ingestion, grounded claims, human review, Copilot, evidence APIs, and governance — with more capability releasing over time.

Pillar 01

Executable Science Runtime

Shipping today· 102 of 106 reported figures recomputed and reproduced

“Every paper becomes a callable function”

Every methods.json becomes a sandboxed, deterministic, reproducible OCI container — pinned data, pinned seeds, byte-for-byte replayable.

  • Replay byte-for-byte (reproducibility score 0–100)
  • Parameter-sweep within author-declared safe bounds
  • Compose with other LROs' methods to build pipelines

Running today

Every LRO records the model, prompt version and content hash that produced its claims, so an extraction can be traced to exactly what ran.

How this is measured

The reproducibility checklist and artifact links are read from the article itself, not asserted. And the runtime EXECUTES something: it recomputes the arithmetic each paper reports — a count against its percentage, an estimate against its own confidence interval — and reports what disagrees. Across 15 papers it executed 106 checks, reproduced 102, and found 4 articles that contradict their own numbers: three print an estimate that falls outside the interval reported with it — an estimate of 6 against [1.01, 1.1], 0.5 against [−0.7, −0.3], and −0.71 against a 95% interval of [−4.44, −3.39], which no rounding can make true — and one reports 508/3824 as 13.2% where the division gives 13.28%. Tolerance is the precision the paper itself wrote, so 17/30 as "57%" passes and "57.4%" does not. Two further checks returned `insufficient_data` rather than a verdict — an interval reported with no point estimate before it — and are counted as neither reproduced nor inconsistent. Pure arithmetic over numbers already extracted: no model, no network, 0.9 ms per LRO. Separately, the runtime can now EXECUTE a registered method in a locked-down container and check that it is reproducible: a Monte Carlo method over 300,000 samples ran twice through the HTTP API and produced byte-identical output.

Scope and limits

The name this pillar used to carry — Executable Science Runtime — promised re-running the authors' analysis, and that is not what runs. No environment is pinned or rebuilt, no author code is executed, no figure is regenerated from data. That gap is not waiting on engineering: measured across the corpus, 0 of 12 papers report a random seed, hyperparameters, hardware or a compute budget, and only 2 declare that code exists anywhere — so a sandbox would have an empty input set. There is a REAL sandbox — a container with no network, a read-only root filesystem, an unprivileged user, no capabilities and hard ceilings, from an image pinned by digest, proven by attempting each forbidden thing and requiring it to fail. What is missing is not the runtime any more, it is the input: a paper that publishes no code, no seed and no environment gives a sandbox nothing to run. The in-process executor still provides no isolation, is labelled as such, and refuses any spec asking for a backend it is not. What the checks verify is internal consistency, which is a real and checkable property of a paper, and a narrower one than reproducibility — which is why this pillar is now named for the checks rather than for a runtime. The nightly skip that makes this affordable was itself the biggest risk to it: its cache key covered the paper's text and not the checking code, so adding a check left every paper skipped and the gate reported the corpus CLEAN over both errors it should have caught. The key now includes the checker.

Why it matters

Regulators and pharma pay premium for reproducible, executable evidence. No competitor has this.

Our view of the market, not something this product measures. Everything above under “Running today” is measured from the catalogue.

esr.query
lro://10.1234/xyz#method[
  drug=A, dose=20mg,
  population="elderly"
]
Pillar 02

Causal Knowledge Engine

Partly shipping· 346 of 1,560 asserted relationships in the corpus graph

“Beyond correlation — true scientific reasoning”

Pearl's do-calculus and structural causal models (SCMs) layer over the Claim Graph. Every causal claim becomes a DAG with assumptions, confounders, and mediators.

  • Causal DAG per claim — not just keyword association
  • Counterfactual queries: what if population = pediatric?
  • Flags unidentifiable claims (no valid adjustment set)

Running today

A relationship graph built from the entities the extractor names in each claim, with every one of 451 edges carrying a written verdict rather than a verb a consumer must re-read: 322 not_established, 120 associational, 8 asserted_causal, 1 tentative.

How this is measured

Where a claim reports a comparison against an outcome, the edge is built from the extractor's structured measurement rather than from the sentence — 89 of 451 edges are derived this way and 52 carry a parsed effect with its confidence interval. Values the parser cannot read as a single number ("20%–30%; up to 50%") are refused with the reason rather than guessed. Every edge that asserts a relationship then carries an identifiability label computed by the back-door criterion over the graph: whether the graph names a set of variables that would block confounding, and when it does not, which reason applies. Every graph now also states its own SHAPE where it is drawn, because the count of asserted relationships says nothing about whether they connect: 3,602 of 4,099 graph variables touch exactly one relationship, so most of these graphs are a small traversable core inside a large fringe of separate observations. nearly every graph says so as a core-and-fringe, a few hold no path at all, and the reader is told which — along with the pipeline's own identifiability caveats, which were written on every row and rendered nowhere until now.

Scope and limits

The label runs over the whole corpus and returns `unknown` for all 129 edges it applies to — every one for the same reason, that the treatment has no asserted cause — with 0 named confounders and 0 adjustment variables across twenty papers. That is the honest output of a correct implementation over papers that do not state what it needs, and it is exactly what a "causal knowledge engine" must not be sold as. The count went DOWN on purpose: an earlier pass counted variables a paper said a FUTURE study should adjust for, which is not an adjustment the paper made. No effect is estimated anywhere, by design — the numbers on edges are the ones the papers reported, never ones we computed. There is no do-calculus, no counterfactual query, and no cross-paper graph: each graph is per-paper, and only 50 of 4,099 variables carry an ontology id, so the graphs cannot yet be joined. The standalone `causal-engine` service is parked, not wired: its back-door check returns true for an empty adjustment set and it keys on a role every shipped graph leaves as "variable", so connecting it would produce confident wrong answers.

Why it matters

This is the difference between correlation retrieval and scientific reasoning. Nobody at scale does this today.

Our view of the market, not something this product measures. Everything above under “Running today” is measured from the catalogue.

cke.query
do_calculus.query(
  outcome="MACE",
  intervention="Drug A",
  population="pediatric"
)
Pillar 03

Autonomous Research Agents

Partly shipping· 38 of 259 agent/paper pairs an agent has reported on

“A fleet of specialized agents — graph-grounded, not text-grounded”

Each agent operates on LRO nodes, not on raw text. Zero tokens emitted without a traceable graph anchor.

  • Claim Auditor — verifies evidence, flags over-claims
  • Contradiction Hunter — scans federated mesh cross-publisher
  • Reproducibility Grader — score 0–100 with failure modes
  • Gap Finder — missing populations, understudied subgroups
  • Hypothesis Generator — proposes next experiments
  • Regulator Narrator — FDA/EMA/ICH-formatted narratives
  • Meta-Analyst — auto-builds forest plots from compatible LROs
  • Peer Reviewer v2 — traceable, evidence-linked critique

Running today

Nine agents are implemented. The Reproducibility Grader runs over every LRO in the catalogue — it makes no model call, reading the paper's own text against the checklist its domain pack declares, with the sentence that proves each item.

How this is measured

The Claim Auditor re-reads each claim against the evidence cited beside it. Both write to `ai_runs` and nothing else: findings are surfaced to a human, and no agent transitions a review state.

Scope and limits

Coverage is per (agent, paper), not per paper. The figure beside this pillar used to be `lros_with_agent_runs` — papers carrying output from ANY agent — which one scheduled agent takes to 100% and holds there: it read 28 of 28 while four of the seven agents had run on a single paper. The metric measured the wrong claim, and an agent that never runs now counts against the denominator rather than being invisible. Three agents were registered, reachable by name, and never constructed by the app, so every run skipped them in silence; four more called a model with no ceiling applied, because the budget map named only two of them. Both are fixed and gated. `run_agents_over_corpus.py` runs the six over the catalog through the orchestrator's own use case and skips a paper already carrying a report for the same claim content, so a scheduled pass prices the delta rather than the corpus — a full pass is about 10,700 model calls at the registry ceilings. The Claim Auditor remains the expensive one at one call per claim. Every figure an agent emits is checked, including ones in a report's metadata: an agent that emitted no findings used to bypass the contract entirely, which let a computed meta-analytic pooled effect reach the API with no citation. No agent scores, and none transitions a review state — that is the contract, not a gap: agents write `ai_runs`, humans decide.

Why it matters

Graph-grounded agents cannot hallucinate. Every output traces to a node.

Our design intent, not a guarantee. The agents here are language models and can be wrong, which is why their findings are advisory and a person decides.

ara.query
agent.run("claim_auditor",
  lro_id="10.1234/xyz",
  mode="strict"
)

Built and tested; not yet run against a catalog — 160 of 224 agent/paper pairs an agent has reported on. The contracts, the budget ceiling and the write path exist, so what each agent does below is what it is built to do, not what it has done.

Claim AuditorVerifies every claim against its evidence; flags over-claims
Contradiction HunterScans Federated Mesh for contradicting / confirming claims
Reproducibility GraderScores 0–100; explains failure modes in plain language
Gap FinderIdentifies understudied subgroups & missing populations
Hypothesis GeneratorProposes next experiments by combining claims across LROs
Regulator NarratorWrites FDA / EMA / ICH-formatted submission narratives
Meta-AnalystAuto-builds forest plots & meta-analyses from compatible LROs
Peer Reviewer v2Produces traceable, evidence-linked critique for editors
Pillar 04

Traceable-or-refused answers

Shipping today· 2,897 of 2,900 claims anchored to a verified source span

“A figure is traceable to its source, or it does not ship”

Names the design this pillar is built around, not a mechanism running today. Decoding is not constrained at the logit level — extraction runs against a hosted model, so grounding is enforced after generation instead: a claim whose source span cannot be verified is marked for review and never published. Scope and limits, below.

Every claim carries a verified source span and every figure a citation key. Assembly strips any number that cannot be traced, and the copilot refuses rather than guessing.

  • Every claim anchored to a verified span of its own source
  • Every sentence ships with provenance_hash
  • Untraceable figures stripped in assembly, not flagged
  • Free-text only in mandatory-citation zones

Running today

Every claim carries a verified source span, every figure a citation key, and assembly strips any number that cannot be traced.

How this is measured

The copilot refuses an ungrounded answer. Measured on the corpus: 2,897 of 2,900 claims carry a verified snippet, and the one that does not is held in needs_review rather than published — the enforcement working, not an exception to it. Extraction asks the provider for JSON-schema structured output where it is supported, which tightens the SHAPE of a response and not its grounding.

Scope and limits

The name this pillar used to carry — Zero-Hallucination Architecture — promised graph-constrained decoding, and that is not achievable as named: constraining a decoder requires logit-level control of the model, and extraction runs against a hosted model through LiteLLM, which exposes `response_format` and nothing finer. What is enforced instead runs AFTER GENERATION rather than during it: every claim's source span is verified against the document once the model has produced it, assembly strips any figure that cannot be traced to one, and the copilot refuses rather than answering. That is a weaker promise than constrained decoding and a checkable one — a sentence is admitted because it was checked, not because the decoder could not have written anything else. The claim is narrowed to that guarantee rather than dropped, and the landing page still marks the aspirational mechanism as a design rather than a running one. Anchoring is not total: a couple of claims carry no verified source span — one methodological, one a stated limitation — and the measured figure is the one shown beside this pillar rather than a number frozen into this sentence. Both are extraction misses rather than a design choice, and the strip-or-refuse guarantee still applied to them.

Why it matters

The single feature pharma and regulators cannot get anywhere else.

Our view of the market, not something this product measures. Everything above under “Running today” is measured from the catalogue.

zha.query
claim {
  text: "...",
  provenance_hash: "sha256:...",
  confidence: [0.81, 0.90, 0.96]
}
Pillar 05

Federated Knowledge Mesh

Partly shipping· 129 of 746 canonical concepts appearing in more than one LRO

“The protocol layer for a scientific internet”

LROs from different publishers expose a standard GraphQL/JSON-LD interface. Claims queried across publishers without sharing raw text. Cryptographic Provenance Ledger Merkle-chains every transformation.

  • GraphQL / JSON-LD standard interface across publishers
  • Cross-publisher claim queries — no raw text sharing
  • Every edit/retraction Merkle-chained and signed
  • Optional blockchain anchor for regulator-grade immutability

Running today

Claims carry canonical ontology identifiers, resolved against the vocabularies each paper's domain is LICENSED to use rather than whatever a text miner happened to emit.

How this is measured

MeSH 2026 is the primary medical vocabulary — NLM publishes it free of charge for commercial use, and it is cached locally so resolution needs no network and costs nothing per paper. Which vocabulary applies is declared per domain in packs/vocabularies.json, so a new research field is a data edit; a paper whose domain has no licensed vocabulary records that reason rather than appearing to mention nothing. Europe PMC's text-mined UMLS, ChEBI, Gene Ontology and UniProt concepts are kept alongside, each labelled with the vocabulary it came from. UMLS is supported for an operator who holds a licence and its identifiers are withheld at serving otherwise, because NLM's terms prohibit redistributing UMLS subsets. A second node can be asked about any of them: /api/v1/federation/node and /api/v1/federation/claims are part of the product API, served by the same app that serves the read model.

Scope and limits

Two independently administered deployments, operated by the SAME TEAM. `publisher-b` has its own signing key generated in its own home, its own three papers with no DOI in common with this repo's twenty, and its own trust store holding only the other side's public key — asserted before anything is demonstrated, because a demo printing “verified” while both sides share a key has demonstrated nothing. Every technical reason a third party could not be the second node is gone; what is left is a counterparty, which is a business relationship and cannot be manufactured. Do not say “two organisations” unqualified. It is JSON over HTTP — not GraphQL and not JSON-LD, both of which earlier copy named and neither of which is built. One concept at a time, by canonical id: there is deliberately no free-text search and no unfiltered listing, because an endpoint answering an empty filter is a bulk export wearing the shape of a query. There is no peer discovery, no rate limiting, and one shared secret for the whole endpoint rather than a credential per tenant. A signature proves who issued a claim, not that the claim is true, and it has no expiry — a claim retracted yesterday still verifies today, because there is no revocation and federation is unaware of time. The join surface is still thin: 50 of 4,099 graph variables carry an identifier, because extracted names carry modifiers — "persistent obesity I" — where ontologies hold bare terms, and resolving those automatically was measured and refused after an exact-label search matched "ComBat", a batch-correction algorithm, to a gazetteer place. Coverage is bounded by what the miner recognises (diseases, chemicals, genes, organisms): 940 of 2,900 claims carry a concept and the rest carry none, rather than being linked to something approximate. The node holds its rows in memory, so this suits a catalog that fits in one — ten million LROs needs the concept lookup to be a query.

Why it matters

Turns every publisher into a node in a scientific internet — with ATLAS as the protocol owner.

Our view of the market, not something this product measures. Everything above under “Running today” is measured from the catalogue.

fkm_+_cpl.query
mesh.query({
  claim_type: "causal",
  subject: "Drug A",
  publishers: ["all"]
})
Pillar 06

Living Loop

Shipping today· 37 of 37 papers re-checked against the retraction registry

“LROs are not built once — they learn forever”

Every LRO re-evaluates itself when new papers cite or contradict a claim, datasets are retracted, method dependencies drift, or regulatory guidelines change.

  • Re-evaluates on every new citing paper
  • Detects dataset retractions and method drift
  • Tracks regulatory guideline changes
  • Health Score 0–100 evolves in real time

Running today

The loop turns unattended, and a container turns it.

How this is measured

Seventeen schedules run — retraction and correction polling, re-deposit detection, a bounded action drainer, causal adjustment backfill, arithmetic recomputation, reproducibility grading, watcher notification, catalog materialize, ledger sealing, a backfill for papers nothing has ever looked at, three rights sweeps, the corpus-shaped research agents, canonical projection, orphan-vector pruning and database maintenance — and `make schedules` reports 17 enabled and states each job's health, naming the ones that are FAILING or OVERDUE with the error rather than showing a count that is only true on the day it was written. Detection asks the registry what changed rather than asking each paper whether it did, scoped to the DOI prefixes we hold: about seven HTTP requests a day at ANY corpus size, where the per-paper design it replaced would need 10,000,000 a day at ten million LROs. Every paper carries a DATED registry observation — verdict, timestamp, source and the publisher's deposit stamp — recorded at ingest and refreshed by the loop, so the reader is told what was checked and when rather than being shown a clean tick that means nothing. A failing job never stamps a success timestamp, so it reports FAILING or OVERDUE rather than looking healthy, and it retries under an exponential backoff that is bounded rather than re-running every minute for as long as the failure lasts.

Scope and limits

Nothing acts on a retraction — no LRO is unpublished or re-extracted when its paper is withdrawn — by design; the sweep records the notice and a human decides. Model spend is capped at one re-ingest per run, so a day with many changed papers drains over several days rather than in one bill; a ceiling DEFERS work and never drops it, and queue depth is reported every run so a backlog is visible rather than silent. Change detection reads Crossref's deposit record, so an article edited without a new deposit is not seen, and there is no citation ingest, no method drift detection and no guideline tracking — "a new paper contradicts this claim" is not a trigger. The work queue is a Postgres table with SKIP LOCKED claim semantics where a DSN is configured, and the JSON file elsewhere, so a deployment without a database still runs the loop.

Why it matters

This is what actually makes them Living — not just a marketing word.

ll.query
lro.health {
  score: 87,
  reproducibility: 94,
  freshness: 82,
  contradiction_free: 91
}

The object

Every paper becomes claims, each traced to the sentence it came from

Not a summary of the paper, and not a chunk of it in a vector index. A claim is a statement, what was measured, and the address of the passage that says so.

one claimillustrative — structure is real, content is invented
textThe intervention reduced the primary outcome relative to control.
claim_typefinding
claim_roleprimary
evidence_origincurrent_study

measurement

outcomeprimary composite outcome
comparisonintervention vs control
effecthazard ratio
reported_value0.74 (95% CI 0.61–0.89)

source_span — the address in the paper

section_idsec-results
paragraph_index4
sentence_index2
char_start1180
char_end1297
matchexact
verified_snippetwithheld where the licence forbids excerpts

A claim knows where it came from

Section, paragraph, sentence and character range — an address precise enough to reopen the paper at the exact passage. Not a page number, and not a similarity score.

The text is quoted, never summarised into fact

The matched passage is recorded as it was written, and whether the match was exact is recorded with it. A claim whose passage cannot be verified is marked for review rather than published.

The address survives when the quotation cannot

Where a licence does not permit redistributing excerpts, the quoted text is withheld and the pointer is kept, with a notice saying where to read it. The claim still works — copyright does not reach the facts a claim is made of.

Proof

We recompute what a paper reports, and say where it disagrees with itself

No model runs here. It is arithmetic over numbers already extracted — which is why a better model cannot make it unnecessary, and a worse one cannot break it.

impossible
An estimate of −0.71 printed against a 95% interval of [−4.44, −3.39].

Outside its own interval. No rounding can make this true.

substantive
508/3824 reported as 13.2%, where the division gives 13.28%.

Past twice the precision the paper itself wrote.

A percentage against its own counts

The paper reports a share and the numbers it was taken from. The division is redone.

An estimate against its own interval

A point estimate that falls outside the confidence interval printed beside it cannot be right.

A percentage against a stated denominator

Where the denominator is given in the text, the figure is recomputed from it.

Tolerance is the precision the paper chose

Half a unit in the last place it was written — so a figure written to one decimal is held to one decimal, and no further. A checker that reports rounding noise as error is switched off within a week, and then it is checking nothing.

Past twice that, the number no longer comes from the arithmetic at all. That is the line between a truncation and a mistake, and the two are reported differently.

A paper we could not check is not a paper that passed

When a figure lacks the numbers to verify it, the result is insufficient_data — never a pass. Papers never checked are reported apart from papers found consistent.

Merge those two and an unchecked corpus reads as a healthy one, which is the single easiest way for a quality report to lie.

Pipeline

Nothing reaches a reader until a person approves it

Six stages from paper to LRO. The last one is a gate, not a step.

1
Ingest
Any format
JATS XML · HTML · PDF · DOCX · ePub · Markdown
2
Extract
LLM + span grounding
Claims · Outcomes · Results · Source-span verified
3
Review
Human-in-the-loop
Review queue · Approve · Reject · Span-highlighter
4
Publish
Versioned + signed
SemVer · Merkle hash · Health score · Ledger
5
Export
Publisher-grade
PDF (paginated) · ePub3 · HTML
6
Live
Forever learning
Agents · Health updates · Contradiction detection

Publishing is refused while anything is unreviewed

Not a warning, not a quality score — a refusal. Ask to publish an LRO with outstanding claims and the request is rejected, with the count of what is still waiting:

409 Conflict
Cannot publish: 3 claim(s) and 1 structured finding(s) still require human review.

And review is not a comment box. Every approval, rejection and correction extends a hash-chained provenance ledger and re-signs its head, so the record of who decided what cannot be edited afterwards without the chain saying so.

The states an LRO moves through

  1. draftaccepted, not yet read
  2. extractingclaims being lifted from the text
  3. validatingstructure checked before anything is stored
  4. needs_reviewa person has work to do
  5. review_completederived, not set — the outstanding count reached zero
  6. publishedand only now can a reader see it

Improvement

A better extractor improves the papers you already have

Re-reading replaces. It does not duplicate, and it does not ask you to re-ingest.

An id names a reading, not a paper

Every LRO id is derived from the text it was built from. Read the same paper again with a better extractor and you get a different id, deliberately — because it is a different reading. The paper itself is identified separately, by its DOI.

One paper, one row, decided by rule

When two readings of one paper exist, which one a reader sees is not a judgement call:

  1. 1A content-addressed reading beats a legacy onean id derived from the text is evidence of what was read; an assigned id is not
  2. 2Then the newer reading winsa later read used a later extractor
  3. 3Then the richer one — more claimsa re-read that found less has not improved anything
  4. 4Then the id, so the winner is never arbitrarytwo readings that tie must still resolve the same way on every machine

You can re-read only what needs it

Each claim records the pipeline version, the model and the prompt version that produced it. So “which claims came from the extractor we replaced?” is a query, and re-processing exactly those is a job — not a migration, and not a reason to re-ingest a corpus.

A replaced reading is named on the one that replaced it, so an improvement can be traced rather than discovered.

Which means a paper ingested early is not debt. It is a reading awaiting a better read — and the corpus gets better without being rebuilt.

Working with a paper

Four things you can do with a paper that a PDF cannot answer

Each one reports what it checked and what it could not. That second half is the product: a system that only ever tells you what it found teaches you to trust it where it is silent.

Read the paper as a research object

/lros/{id}/read

The published article, with every extracted claim anchored to the sentence it came from. Tables stay tables, equations are read structurally rather than shown as pictures, and a figure referenced in a claim opens where the claim is.

Nothing is paraphrased. A claim you cannot trace to a span is not shown as a claim.

Ask the paper a question — with or without a model

/lros/{id}/read · Ask this paper

Non-AI mode answers from the research object's own structure across 10 answer sources, and spends nothing. AI mode is there when a question needs reasoning. The switch is explicit, and every answer says which mode produced it.

The zero-cost promise is enforced, not asserted: a gate walks the Non-AI route's import graph and fails the build if anything in it can reach a model client.

See what else bears on a claim

/lros/{id}/read · any claim

Claims in other papers that share a declared basis with this one — the same ontology concept, the same reported endpoint, a citation between the two papers. The shared value travels with every edge, so a related claim always says why it is related.

Three separate questions, never merged: why it was surfaced, what the evidence says (conflicts with this claim / checked, no conflict found / nobody has checked), and whether the two figures may be compared at all. Being about the same thing is not evidence about it.

See how reproducible it is, without a score

/lros/{id}

7 dimensions, read separately: reported numbers, method completeness, data and code, compute environment, independent replication, executable artifact, stated limits.

No composite figure, and no count of how many passed. The dimensions are not comparable with each other, so a number averaging them would move for reasons nobody could attribute — and a question that does not apply to a paper is never recorded as a gap in it.

For researchers

Four steps, and they are the four you sign in to

This is not a diagram of an ideal workflow. It is the product’s own navigation, in its own order — what you will see on the left of every screen.

  1. Read

    The papers, their claims and where each one is grounded

    /lros
  2. Assistant

    Ask a question and get an answer from the papers, with citations

    /copilot
  3. Compare

    Your questions, and what the papers in them found side by side

    /compare
  4. Notes

    What you saved, wrote down, and cited

    /library

When two papers disagree, it says what kind of disagreement it is

/contradictions

Two findings pointing opposite ways are usually not a contradiction — they are different patients, a different method, or a different dose. Flagging them as conflicting is the easy half and the useless half. Each pair is classified, on the axes the two findings share and the ones they do not:

  • Direct contradiction
  • Magnitude disagreement
  • Dose/regimen difference
  • Methodology difference
  • Population difference

It also reports the denominator — how many claims carried enough structure to be compared at all. “Nothing conflicting was found” and “almost nothing was comparable” are different statements, and a tool that cannot tell you which one it means is not worth trusting with the question. Same corpus, same findings, every run.

Read what a paper claims, ask across all of them, put two side by side, keep what you found. Every answer carries the claim it came from — so the note you write today is still checkable next year.

Scale

The work does not grow with the corpus

Ingestion is meant to grow deliberately — by domain, by subject area, by demand. These are the properties that let it, and none of them depend on how much is held today.

Aggregates are answered by the database

Totals, state counts and quality rankings are asked as one query rather than assembled in the application. A backend that can answer them in SQL does; one that cannot still works, because each capability is optional and has a fallback. Adding one makes the product faster without changing a single caller.

corpusTotals · stateCounts · qualitySnapshot · getManyByIds · getManyByDois

Ranking is an index, not a scan

Quality lives in a real column with its own partial index, ordered so the best come first. It was a value inside a JSON document, which can be sorted — as a sequential scan with a cast on every row, wearing the shape of a query. And a paper whose health was never computed is held as unknown rather than as zero, because counting it as poor reports a failure that did not happen.

lro (tenant_id, health_score DESC) WHERE health_score IS NOT NULL

What would not scale refuses, loudly

Loading the whole catalogue stops at a declared ceiling and says so, naming the limit and the fix. A system that quietly takes a minute instead has a fault nobody can point at, and one that has never been told where its edge is does not have one.

the caller needs a page, not the whole catalog

Which is why the honest claim is not how much we hold. It is that holding more does not change the shape of the work — and where that stops being true, the system says so instead of slowing down.

Governance

What happens to a paper after it is read

Where the authoritative copy lives, what a retraction reaches, and what a second reading replaces. Each of these is enforced where it cannot be forgotten rather than where it was convenient.

A withdrawn paper stops being cited — including by the assistant

Retract a paper and it leaves the catalogue, the reader, filtered search and the assistant's own retrieval at the same moment. The rule is a clause in the query, so a reader cannot forget to apply it and a feature added next year inherits it.

One authoritative record, and every copy says so

Each paper has a single canonical record. The read model, the export object and the file catalogue are declared as copies, each naming what it derives from and the command that rebuilds it. A registry with two sources of truth for one thing does not pass the gate.

Deletion is complete, recorded, and reversible

A delete removes the paper from every store in one transaction — claims, evidence, concept links, graph edges and search vectors — and records who did it, when and why. The provenance ledger and the source document survive, and the withdrawal can be undone.

Evidence keeps its place in the paper

A claim's evidence carries where it came from — section, paragraph, sentence and character offsets — not only the sentence it quotes. A quote you cannot locate is a quote you cannot check.

Re-reading a paper replaces it, never duplicates it

Extraction improves, so papers are read again. The second reading updates the paper rather than adding a second one: claims, evidence and vectors are replaced, not accumulated. The corpus does not drift as the method gets better.

Each statement above has a row in the claims register naming the code that delivers it and the test that proves it.

For publishers

Your corpus becomes an asset you can audit, export and run yourself

The researcher’s workflow is what makes a structured corpus worth having. This is what makes it yours.

Your corpus is scoped to you

A publisher sees its own papers and its own people. The isolation is decided in one place, against the caller's stored record rather than a claim in a token — and an account with no organisation is refused rather than shown everything, because the guess that reads no-publisher as every-publisher is the whole vulnerability that field exists to close.

The audit trail includes the people

Every approval, rejection and correction extends a hash-chained ledger over the paper it belongs to. A regulator asking who accepted a figure, and when, gets an answer that cannot be edited afterwards without the chain saying so. Where a signing key is configured, the head of that chain is signed too.

Run it yourself, with your own model

Self-host the whole stack. The model is configuration, not architecture — 9 providers are supported from a single definition read by every service, including local ones, so nothing here requires sending your unpublished corpus to a third party.

Nothing is trapped in the format

An LRO leaves as JATS or RO-Crate, renders as HTML, PDF or ePub, and its references export as BibTeX, RIS or CSL-JSON. The value is the structure, and a structure you cannot take with you is a hostage rather than an asset.

Ingestion is a capability, not a free-for-all

Bringing a paper in is governed by one permission, in the interface as well as the API, so a reader cannot start work that costs money. Searching outside the platform sits behind the same permission, because reaching outside is the first move of an ingest.

A pile of PDFs is a cost. The same papers as claims, with their provenance and their review history, are an asset — and one that improves every time extraction does.

Technology

The model reads. Everything that decides is deterministic.

Every product uses a model now, so that fact distinguishes nothing. What matters is where the model sits, and what happens when it is wrong.

with a model

Reading prose

  • Lifting claims, populations, outcomes and effect sizes out of an article's text
  • Proposing a study design for a human to confirm
  • Drafting comparisons, and answering questions in the Assistant

The smallest part of the system. The model reads; it does not decide, and it does not get the last word.

around the model

Making its output accountable

  • A figure with no citation is stripped from an answer, or the answer is refused outright
  • An agent finding that names a claim it was never given, or states a number appearing in none of them, is removed — not flagged
  • Removals are recorded, because a finding that vanishes silently looks identical to an agent that found nothing
  • Verification is post-hoc, and described that way: the check runs after generation, not inside it
  • A deterministic rule runs first and the model only takes the remainder — which is a cost argument as much as a quality one

Most of the engineering is here. The model is a component with a contract, not the product.

without a model

The parts no model release can obsolete

  • Recomputing the arithmetic a paper reports, and reporting what disagrees
  • The state machine that refuses to publish while review is outstanding
  • Tenancy, decided against a stored record rather than a claim in a token
  • Idempotent, content-addressed ingestion, and the rule deciding which reading a reader sees
  • Citations built from stored metadata, with missing fields named rather than invented

A better model does not make any of this unnecessary, and a worse one does not break it.

the whole

What the composition buys

  • The governing rule is a code path, not an instruction — a prompt can be talked out of a rule
  • Absence is a finding everywhere: unchecked is not clean, unscored is not poor, no data is not no effect
  • Every claim on this page is held by a test that fails when it stops being true
  • The model is configuration: swap it, or run a local one, and none of the guarantees move

None of these is remarkable alone. Together they are what makes the answer checkable.

Any model can read a paper. What is hard is refusing to answer when the evidence is not there — and that part was never the model’s job.

What is actually different

A better model does not make any of this unnecessary

Half of what research tools do is becoming free. Being straight about which half is what makes the other half worth believing.

Everyone has this, and soon everyone will have it free

  • Chat over a folder of documents
  • Semantic search across a corpus
  • Summarising a paper
  • Pulling out entities and keywords
  • Exporting a citation

We do these too. None of them is a reason to choose anything.

This is what a model release does not replace

  • Recomputing the arithmetic a paper reports, and saying where it disagrees with itself
  • Refusing to answer, by design, when a figure cannot be traced to a source
  • Treating absence as a result — unchecked is not clean, unscored is not poor
  • A hash-chained record of every human decision, over the paper it belongs to
  • Improving a paper already ingested, by re-reading it rather than re-adding it
  • Guarantees that survive changing the model, because they were never the model's
CapabilityPDFsJATS + SearchRAG / AISciSpace / SciteLROHub
Structured claims
Causal reasoning
Executable arithmetic checks
Traceable-or-refused answers
Cross-publisher mesh
Cryptographic provenance
Living / self-updating
Regulator-grade output
Parameter-swept what-ifssoon

Our column is read from the measured capability file, so a pillar that is partial shows as partial here and one that is not built shows as “soon”.

Nothing else comes close — every column to the left is a step backward in scientific infrastructure.

Our view of the market, not something this product measures. The table above is; this sentence is an argument, and you should weigh it as one.

Who it's for

Every stakeholder in the research lifecycle

Publisher

Run ingestion pipelines, curate claims, and publish versioned LROs with cryptographic provenance for readers and integrations.

Researcher

Explore verified claims, query the catalog through Copilot scoped to real evidence, and use analytical views where enabled.

Editor

Shape manuscript-ready LROs: refine extracted claims with source-span context before publication gates.

Reviewer

Validate AI-assisted extraction in a dedicated queue — approve, reject, or escalate claims with full audit trail.

Auditor & regulator

Evidence-first oversight: trace claims to sources, monitor portfolios, and export structured materials suitable for compliance packs.

Platform administrator

Operate the tenant: users, feature flags, model routing, ingest policies, backups, and configuration history with validate-before-import safeguards.

Automation

APIs & integrations

LROHub exposes REST endpoints for dashboards, LRO detail, Copilot, ingest jobs, evidence snapshots, and tenant configuration (each behind appropriate roles). Where enabled, trusted workloads can use an LROHub API key or CLI alongside interactive sessions so pipelines and operators stay aligned.

Representative REST surfaces

  • GET /api/v1/dashboard/lros
  • POST /api/v1/copilot
  • GET /api/v1/evidence-graph/lros/[id]
  • POST /api/v1/ingest …

Routes and payloads vary by feature flags. After you sign in, open Product guide from the app sidebar for routes that match your tenant.

Trusted automation

Automation uses the same contracts as the UI — fewer surprises between scripts and reviewers. Major policy changes flow through configuration export/import with validate-before-apply for administrators.

  • Secure sessions for people; optional API keys for approved integrations where your deployment allows it.
  • Human review gates remain available for anything that affects publication quality or compliance.

First-time visitors

Get started in four steps

No prior knowledge of LRO internals required — register, sign in, explore your role-specific workspace, then use the in-app guide when you need deeper workflows or API detail.

01

Create an account

Pick the role that matches your job (you can ask an admin to adjust access later).

02

Sign in

Land on a personalized home dashboard with shortcuts aligned to your permissions.

03

Explore the workspace

Open LROs, Copilot, review queues, analytics, or ingest — depending on what your tenant enables.

04

Learn as you go

Use Product guide (signed-in) for role workflows, feature maps, and API references.

Mission

LROHub is for science itself — a living, executable, verifiable, federated operating system where every paper is a citizen, every claim is a function, and every result is replayable.

We are not rebuilding publishing. We are building the substrate on which the next century of science will run.

After you sign in, use the home dashboard to reach LROs, Copilot, and review tools. Go to catalog · Onboarding steps