L
LROHub
Living, verifiable research.

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.

Get startedLog in
How to get started·Pipeline·Roles·APIs·About·Contact

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

Partly shipping· 20 of 20 LROs carrying an extraction manifest

“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. 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 20 papers it executed 93 checks, reproduced 91, and found 2 articles that contradict their own numbers: one prints an estimate of −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. 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.

Not yet built

This is not re-running the authors' analysis, and must not be described as reproducing a study. 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 now 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. 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 above. 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· 129 of 451 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. 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.

Not yet built

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 11 of 806 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· 20 of 20 LROs carrying agent output

“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. 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.

Not yet built

Two of nine agents run over the corpus, and both are started by hand rather than on a schedule — scheduling the Claim Auditor is a spend decision, not a switch, because it makes one model call per claim, bounded at 120 by its declared budget. Six are wired into the orchestrator's runner and reachable over HTTP. Every figure an agent emits is now 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. Neither running agent scores, and none transitions a review state.

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 — 20 of 20 LROs carrying agent output. 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

Zero-Hallucination Architecture

Partly shipping· 1508 of 1509 claims anchored to a verified source span

“Graph-constrained decoding — the core patentable method”

Decoding is constrained to approved node IDs + pre-approved verbs. Free-text only in summarization zones with mandatory citation anchors.

  • Decoding constrained to node IDs + approved verbs
  • Every sentence ships with provenance_hash
  • Bayesian confidence interval — not a vibe
  • 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. The copilot refuses an ungrounded answer. Measured on the corpus: 1,508 of 1,509 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.

Not yet built

Graph-constrained decoding is not achievable as named, and this text used to promise it. Constraining a decoder requires logit-level control of the model; extraction runs against a hosted model through LiteLLM, which exposes response_format and nothing finer. No amount of engineering here changes that — it needs a different serving arrangement. Grounding is therefore enforced AFTER generation: a claim whose span cannot be verified is marked for review and never published. That is a real architecture and a weaker guarantee than constrained decoding, and the difference is worth stating rather than blurring. What remains genuinely unmeasured is ACCURACY: the evaluation corpus is machine-seeded from the extractor's own output, so scoring against it returns F1 = 1.00 and measures agreement with the current extractor. Independent annotation is the critical path, and it is a staffing question, not an engineering one.

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· 15 of 108 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 — UMLS, ChEBI, Gene Ontology and UniProt — attached where a text miner found the term inside the claim's own verbatim sentence, so a concept match between two papers is grounded in both source texts. A second node can be asked about them, and as of this release the endpoint is part of the PRODUCT API rather than a demo script: `/api/v1/federation/node` and `/api/v1/federation/claims` are served by the same app that serves the read model. Measured on this deployment: the node reports 108 canonical concepts and answers a concept query with claims each carrying the publisher that issued it. Each publisher signs what it issues, so a claim carries its own proof rather than resting on the connection it arrived over — `scripts/federation_demo.py` runs two nodes in two processes over disjoint halves of this corpus, where a node holding no endometrial-cancer paper answers 57 claims about it through its peer, all 57 cryptographically verified, and a peer that rewrites a claim in flight has that one claim refused and the other 56 kept. Two parties can now exchange keys out of band with `scripts/federation_identity.py`: each side exports a public block and enrols the other's, so a trust store is populated from the counterparty rather than from the response being verified. Unconfigured means closed — a node serves nothing until both a node id and a peer secret are set.

Not yet built

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: 11 of 806 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): 414 of 1,509 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

Partly shipping· 20 of 20 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. Nine schedules run — retraction and correction polling, re-deposit detection, a bounded action drainer, causal adjustment backfill, arithmetic recomputation, reproducibility grading, watcher notification and catalog materialize — and `make schedules` reports 9 enabled, 0 needing attention. 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. A failing job never stamps a success timestamp, so it reports FAILING or OVERDUE rather than looking healthy — four states, because a job that has never run once looks identical to a healthy one if you only check for errors.

Not yet built

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.

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

Pipeline

From paper to living LRO

Six stages, fully automated, human-gated where it matters

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

Competitive landscape

Nothing else comes close

Every column to the left is a step backward in scientific infrastructure

CapabilityPDFsJATS + SearchRAG / AISciSpace / SciteLROHub
Structured claims
Causal reasoning
Executable methods
Zero-hallucination
Cross-publisher mesh
Cryptographic provenance
Living / self-updating
Regulator-grade output
Parameter-swept what-ifs
Full support
Partial
Not supported

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.

Ingest pipeline LRO catalog

Researcher

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

Research Copilot Browse LROs

Editor

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

Review queue

Reviewer

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

Claim review

Auditor & regulator

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

Analytics Audit LROs

Platform administrator

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

Platform config

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.
Register for accessEnterprise integration

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.

Create accountSign inCompare roles

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.

Create your accountSign in

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