seren_ — research statement
A Bloomberg terminal for scientific knowledge.
Hypothesis-first workspaces and an epistemic map of evidence.
Seren Research · 2025
Abstract
Research reasoning is mostly invisible. Researchers state what they believe, but the structure of that belief — which sub-claims are well supported, which are contested, and which the field has never properly tested — is rarely made explicit. Evidence accumulates in PDFs and notes; decisions get made in meetings and vanish. When a collaborator or regulator asks why a researcher chose a direction six months ago, the answer has to be reconstructed from memory.
We propose a workspace model that starts with the hypothesis: what do you believe is true? The system decomposes that hypothesis into sub-claims, maps each claim onto the literature, and assigns an epistemic state — established (green), contested (amber), assumed but untested (grey), or unknown (white). The result is an epistemic map: a structured, real-time view of what the field actually knows, what it disputes, and what it has not yet answered.
This model is implemented in Seren as a single workspace containing a hypothesis tree, an evidence foundation keyed to each claim, an analysis library (nine methods from theory mapping to replication audit), mechanisms linked to evidence, a Research Terminal that answers questions in full context, research proposal generation, data artifacts, an uncertainty map, writing review, continuous monitoring, and a decision log that preserves every significant choice with a frozen evidence snapshot and the uncertainty the researcher accepted. We define the core sets, relations, and invariants formally. The outcome is a single source of truth for what a researcher believes, what the evidence says about it, and why they decided as they did — so that researchers, teams, and institutions can make decisions grounded in the true state of evidence.
1. Introduction
Seren is built on a simple premise: the right entry point for research tools is the hypothesis, not the library. A researcher does not start by collecting papers. They start by stating what they believe — and then they need to see, in one place, how well that belief is supported by the literature, where the field disagrees, and where there is no data at all.
In practice, that map is almost never explicit. Most researchers hold it in their heads, partially in reference managers, partially in slides and meeting notes. When the map is invisible, three things go wrong.
First, decisions lose their reasoning. A researcher makes a consequential choice — which mechanism to pursue, which arm to fund, which claim to stake the proposal on — and months later cannot reconstruct why. The reasoning was real; it is gone.
Second, evidence is not organised against the claim. A library of hundreds of papers is not an evidence foundation. An evidence foundation maps each paper's specific proposition to a specific sub-claim and classifies it: does this support the claim, contradict it, or qualify it? Without that mapping, the researcher cannot know whether their hypothesis is well supported or merely surrounded by papers on the same topic.
Third, gaps and disagreements stay invisible until someone else finds them. A new paper contradicts the central claim. A key citation is retracted. The researcher did not know. The reviewer did.
Seren addresses all three by making the epistemic map explicit and durable. The researcher states their hypothesis; the workspace decomposes it, scores it against the literature, and keeps a permanent record of every decision and the evidence state at the moment that decision was made. This document defines that model precisely.
2. Hypothesis-first entry and the epistemic map
2.1 Entry: what do you believe is true?
The workspace does not ask "what are you trying to figure out?" It asks: what do you believe is true? The researcher states their hypothesis in natural language. The system decomposes it into sub-claims (via structured decomposition), queries a knowledge graph and domain-appropriate literature (e.g. PubMed, Semantic Scholar, arXiv where relevant), and assigns each sub-claim an epistemic state. Domain is inferred from the hypothesis; the researcher is not required to pick a field before they start. The result of this process is the epistemic map: a tree of claims, each coloured by the state of the evidence.
2.2 Four epistemic states
Every sub-claim is assigned one of four states, derived from the linked evidence and literature scan:
- Green (established): Well supported — replicated, expert consensus, or multiple concordant papers with no significant contradiction.
- Amber (contested): Conflicting evidence, active disagreement in the literature, or insufficient papers to conclude. Contradicted claims are treated as contested (amber); the distinction is one of degree.
- Grey (assumed, untested): The field treats the claim as true, but it has not been directly tested in the relevant population or context. Assumed without evidence.
- White (unknown): No published data addresses this specific claim. Genuinely unknown.
Red is reserved exclusively for retraction notices and urgent alerts. It is not an evidence-strength state. This keeps the map interpretable: colour reflects epistemic state; red means "attention required."
2.3 The epistemic map and the uncertainty partition
The epistemic map is the primary object in the workspace. It is a rooted tree of hypothesis nodes, each with a label (the claim), a parent, and an epistemic state. The uncertainty partition groups nodes into: Known (green), Contested (amber), Assumed untested (grey), and Unknown (white). The researcher sees at a glance what the field knows, what it disputes, and what it has not answered — and can prioritise evidence gathering, mechanism validation, and decisions accordingly.
3. The workspace model
3.1 Primitive sets
Let:
- U — users.
- W — workspaces (projects). Each workspace has an owner and a root hypothesis with decomposed sub-claims and epistemic states.
- H — hypothesis nodes. Each node has a label (a proposition), belongs to one workspace, has an optional parent, and an epistemic state (green, amber, grey, white).
- D — documents (papers, preprints). Metadata, abstract, and where available full text.
- C — claims extracted from documents, associated with a document and relevant to a hypothesis node.
- L — evidence links. A link associates a document (and optionally a claim) to a hypothesis node with a support status (supports, contradicts, qualifies, unrelated).
- M — mechanisms. Linked to hypothesis nodes and to evidence; classified as confirmed, contested, or unknown.
- Δ — decisions. Each decision records the decision text, reasoning, confidence, key uncertainty accepted, and an evidence snapshot at the time of logging.
- Π — pivots. Significant changes to a hypothesis label; old label, new label, reason, timestamp. History is preserved.
3.2 Relations and evidence strength
parent : H → H ∪ {⊥} defines the hypothesis tree per workspace (rooted forest). workspace : H → W. σ : L → {supports, contradicts, qualifies, unrelated} is the support status of each link. strength : H → {green, amber, grey, white} is derived from link counts and rules: green when support is strong and uncontradicted; amber when contradicted or disputed; grey when assumed without direct evidence; white when no evidence exists. The strength function drives the epistemic map and the uncertainty partition.
3.3 Decisions and snapshots
A decision δ ∈ Δ is a tuple: (nodeId, decisionText, reasoning, confidenceLevel, keyUncertaintyAccepted, evidenceSnapshot, timestamp). The evidence snapshot freezes the evidence state at decision time — which links existed, support statuses, key papers — so that the record is permanent and auditable. The researcher can always show what they knew when they decided and what uncertainty they accepted.
4. The workspace in practice
One workspace holds the full research lifecycle:
- Hypothesis tree — Sub-claims under the root hypothesis, each rated green / amber / grey / white.
- Evidence foundation — Papers ranked by relevance to each claim; relevance scores; support status per link.
- Analysis library — Nine methods: Theory Mapper, Method Auditor, Evolution Timeline, Quote Miner, Weakness Scanner, Bridge Builder, Replication Audit, Future Agenda, Jargon Translator. Run against the foundation to surface structure, gaps, and narrative.
- Mechanisms — Linked to evidence; confirmed vs contested vs unknown.
- Research Terminal — Live commands (/find papers, /add mechanism, /decision) with full workspace context. Every answer is grounded in current literature search, not memory; every empirical claim is cited.
- Research proposal — Specific Aims, Background, Innovation, Approach generated from the evidence and linked back to the foundation.
- Data artifacts — Uploads (CSV, XLSX, etc.) parsed, linked to the hypothesis, with QC flags where relevant.
- Uncertainty map — Known ●, Contested ◐, Unknown ○ (and assumed-untested) in one place.
- Writing review — Flags unsupported claims and contradictions with the decision log and evidence foundation.
- Monitoring — Alerts when new papers match the hypothesis; retraction and correction notices for papers in the foundation.
- Decision log — Permanent record of what was decided, why, and what uncertainty was accepted, with evidence snapshots.
Nothing is separate. The hypothesis is the spine; every artifact is connected to it. The result is a Bloomberg terminal for scientific knowledge: a real-time, structured map of what is known, contested, and unknown, so that researchers, companies, and governments can make decisions grounded in the true state of evidence.
5. The Research Terminal
The Research Terminal is not a general chatbot. It receives every question with the full workspace context — all hypotheses, evidence links, mechanisms, and the decision log — and searches domain-appropriate literature (PubMed, Semantic Scholar, and others by domain) before answering. Invariants:
- Search before answer. Literature is queried on every substantive question. The terminal does not answer from training data alone.
- Cite every empirical claim. No factual assertion about what research shows is made without a citation to a retrieved paper.
- Name what the researcher missed. Responses surface findings that change the picture of the hypothesis or the design — the standard that makes the terminal irreplaceable for experts who already know their field.
Commands such as /find papers, /add mechanism, and /decision operate in this context. The researcher works in one place; the terminal has full awareness of the epistemic map and the evidence foundation.
6. Monitoring and integrity
Monitoring runs over active hypothesis nodes. For each node, the system builds queries from the claim and linked evidence, runs them against publication feeds, evaluates new papers for relevance and impact, and checks foundation papers against retraction and correction sources. Alerts are created for new papers that support or contradict the hypothesis, retractions of foundation papers, and other material changes. Severity is classified so that critical issues (e.g. retraction of a key citation) are unmissable. The researcher reviews alerts and decides whether to add or re-evaluate papers; the evidence foundation remains under their control.
7. Properties of the model
Completeness: Hypothesis formation, decomposition, evidence evaluation, mechanisms, analysis, proposal writing, writing review, and decision logging all live in one workspace. No part of the research reasoning process requires leaving it.
Durability: Evidence links and decision snapshots are permanent. Deleting a paper does not erase the decision that was made when that paper was in the foundation; the snapshot preserves the state at decision time.
Honest uncertainty: The epistemic map is computed from actual evidence. A claim with no evidence is white or grey, not green. A claim with mixed evidence is amber. The system does not allow a researcher to claim certainty the evidence does not support.
Shareability: Decision snapshots (and selected views of the epistemic map) can be exported and shared with supervisors, collaborators, or regulators who do not use Seren. The reader sees what the researcher saw when they decided.
8. What the model does not do
The model does not make decisions. It makes the evidence visible, the gaps explicit, and the reasoning recordable. The decision is always the researcher's.
The model does not replace search engines or reference managers. PubMed, Semantic Scholar, and similar tools help find papers. Seren helps researchers know what to do with them — how they bear on a specific hypothesis, where the field agrees and disagrees, and what was decided in light of that evidence.
The model does not assert the truth of hypotheses. It represents the current state of the evidence. A hypothesis with strong support may still be wrong; one with weak support may be right but understudied. The epistemic map is a map of evidence, not of truth.
9. Conclusion
We have specified a workspace model that starts with the hypothesis and builds an epistemic map: a structured view of what is established, contested, assumed, and unknown. The model is implemented in Seren as a single workspace — hypothesis tree, evidence foundation, analysis library, mechanisms, Research Terminal, research proposal, data artifacts, uncertainty map, writing review, monitoring, and decision log — with formal relations for evidence strength, uncertainty partition, and decision snapshots.
The core claim is simple: a researcher who uses this workspace produces a record that proves they thought carefully, evaluated the evidence honestly, knew what they were betting on when they committed to a direction, and will know when the literature moves in a way that changes the picture. That record is what distinguishes a researcher who can defend their work from one who cannot — and what makes Seren a Bloomberg terminal for scientific knowledge.
Notation summary
| U, W, H, D, C, L, M, Δ, Π | Users, workspaces, nodes, documents, claims, links, mechanisms, decisions, pivots |
| parent : H → H ∪ {⊥} | Hypothesis tree — parent or root |
| σ : L → support status | Supports, contradicts, qualifies, unrelated |
| strength : H → {green, amber, grey, white} | Epistemic state from evidence |
| Known, Contested, Assumed, Unknown | Uncertainty partition of workspace nodes |
| δ = (node, text, reasoning, confidence, uncertainty, snapshot, t) | Decision with evidence snapshot |
seren_ — Bloomberg terminal for scientific knowledge