Research & Knowledge Core
Shared model for the research-knowledge cluster. Every research, literature, database,
codebase, and reference spoke depends on these two interlocking ideas — keep them consistent
here so no spoke contradicts another.
1. The evidence ladder (this cluster's defining discipline)
Answer with the lightest lane that actually answers the question, and escalate only when a
heavier one is justified. Climbing a rung costs time, tokens, and quota — earn it.
local context / docs / ck memory ← cheapest, no network
│ (not present or stale?)
▼
fast discovery (exa-search, single DB query)
│ (one source not enough? need synthesis?)
▼
multi-source synthesis (deep-research, systematic literature review)
│ (claim needs judging?)
▼
evaluation / verification (scholar-evaluation, citation checks)
Rule: never start a heavyweight pass when a lookup answers it; never stop at one source
when the claim is load-bearing and contested. research-ops is the operator that picks the
starting rung — route ambiguous "research this" asks there first.
2. The four provenance tiers (every claim carries one)
Each statement you return is labeled by where it came from. Never let one tier bleed into
another unlabeled — that is the single most common way research output misleads.
| Tier |
What it is |
Source obligation |
| Sourced fact |
From a citable source (paper, page, record, DB) |
Name the source + date |
| Supplied context |
The user gave it to you |
Attribute to the user |
| Inference |
What follows from the evidence |
Mark as reasoning, not fact |
| Recommendation |
Your answer / next move |
Flag as a judgment call |
3. Conventions
- Freshness: date every freshness-sensitive claim; say "as of ". Drift-prone MCP
spokes (
deep-research, exa-search, documentation-lookup) — verify configured tool
names and current API docs before quoting coverage or live counts.
- Reproducibility: database spokes (
pubmed, uspto, gget) log the exact query,
parameters, and result IDs so a run can be repeated. Prefer official APIs over scraping.
- Citations: carry a stable identifier (DOI / PMID / patent no. / URL) per source; never
cite a source you did not actually open.
- Scope before search: convert the prompt into a searchable question first (PICO for
clinical/biomedical); pick the review type (narrative → scoping → systematic → meta-analysis)
to match the rigor the claim needs.
- Persistence: when a result should survive the session — onboarding facts, ongoing
research state — write it to
ck memory rather than re-deriving it next time.
4. Question-type → spoke matrix
| Question type |
Spoke |
Lightest-lane note |
| Ambiguous "research this" / compare / latest |
research-ops |
Picks the lane below |
| Fast web · code · company · people discovery |
exa-search |
Rung 2 |
| Thorough multi-source cited report |
deep-research |
Rung 3 — earn it |
| Systematic literature review & synthesis |
scientific-thinking-literature-review |
Rung 3 |
| Judge a paper / proposal / evidence quality |
scientific-thinking-scholar-evaluation |
Rung 4 |
| Biomedical literature (MeSH / PMID / E-utils) |
scientific-db-pubmed-database |
Rung 2, reproducible |
| Patents & trademarks (official IP records) |
scientific-db-uspto-database |
Rung 2, reproducible |
| Genomic DB / sequence / enrichment |
scientific-pkg-gget |
Rung 2, reproducible |
| Map an unfamiliar repo → onboarding guide |
codebase-onboarding |
Rung 1 (local) |
Step-by-step .tour walkthrough |
code-tour |
Rung 1 (local) |
| Up-to-date library/framework docs |
documentation-lookup |
Rung 1 — before web |
| Persist / resume project context |
ck |
Rung 1 — before re-deriving |
5. Conventions for combining spokes
- "Review the literature and rate the key paper" →
scientific-thinking-literature-review
→ scientific-thinking-scholar-evaluation.
- "What's the current state of X and save it" →
deep-research → ck.
- "Onboard me to this repo and leave a tour" →
codebase-onboarding → code-tour.
- A heavyweight web pass that a docs lookup would answer is an anti-pattern — try
documentation-lookup first when the user named a framework.
6. Shared guardrails
- Lightest lane first: local / docs /
ck before the web; one source before many;
scoping before systematic. Escalate only on a real synthesis or verification need.
- Label every claim by provenance tier; never fold inference into sourced fact.
- Date freshness-sensitive answers; name every source; never cite an unopened source.
- Reproducible database runs — log query, params, and result IDs.
- Don't re-derive what
ck memory or a prior onboarding already captured.
- Drift-prone MCP spokes: confirm live tool names + quotas before promising coverage.
1---2name: research-knowledge-core3description: Shared reference for the research-knowledge cluster: the evidence ladder (lightest lane first → escalate on synthesis need), the four provenance tiers every claim carries, source/freshness conventions, and the question-type → spoke matrix. USE WHEN running any research, literature, IP, genomic, codebase, or docs-lookup task — the discipline every spoke in this cluster shares.4---56# Research & Knowledge Core78Shared model for the `research-knowledge` cluster. Every research, literature, database,9codebase, and reference spoke depends on these two interlocking ideas — keep them consistent10here so no spoke contradicts another.1112## 1. The evidence ladder (this cluster's defining discipline)1314Answer with the **lightest lane that actually answers the question**, and escalate only when a15heavier one is justified. Climbing a rung costs time, tokens, and quota — earn it.1617```18local context / docs / ck memory ← cheapest, no network19 │ (not present or stale?)20 ▼21fast discovery (exa-search, single DB query)22 │ (one source not enough? need synthesis?)23 ▼24multi-source synthesis (deep-research, systematic literature review)25 │ (claim needs judging?)26 ▼27evaluation / verification (scholar-evaluation, citation checks)28```2930**Rule:** never start a heavyweight pass when a lookup answers it; never stop at one source31when the claim is load-bearing and contested. `research-ops` is the operator that picks the32starting rung — route ambiguous "research this" asks there first.3334## 2. The four provenance tiers (every claim carries one)3536Each statement you return is labeled by where it came from. Never let one tier bleed into37another unlabeled — that is the single most common way research output misleads.3839| Tier | What it is | Source obligation |40|---|---|---|41| **Sourced fact** | From a citable source (paper, page, record, DB) | Name the source + date |42| **Supplied context** | The user gave it to you | Attribute to the user |43| **Inference** | What follows from the evidence | Mark as reasoning, not fact |44| **Recommendation** | Your answer / next move | Flag as a judgment call |4546## 3. Conventions4748- **Freshness:** date every freshness-sensitive claim; say "as of <date>". Drift-prone MCP49 spokes (`deep-research`, `exa-search`, `documentation-lookup`) — verify configured tool50 names and current API docs before quoting coverage or live counts.51- **Reproducibility:** database spokes (`pubmed`, `uspto`, `gget`) log the exact query,52 parameters, and result IDs so a run can be repeated. Prefer official APIs over scraping.53- **Citations:** carry a stable identifier (DOI / PMID / patent no. / URL) per source; never54 cite a source you did not actually open.55- **Scope before search:** convert the prompt into a searchable question first (PICO for56 clinical/biomedical); pick the review type (narrative → scoping → systematic → meta-analysis)57 to match the rigor the claim needs.58- **Persistence:** when a result should survive the session — onboarding facts, ongoing59 research state — write it to `ck` memory rather than re-deriving it next time.6061## 4. Question-type → spoke matrix6263| Question type | Spoke | Lightest-lane note |64|---|---|---|65| Ambiguous "research this" / compare / latest | `research-ops` | Picks the lane below |66| Fast web · code · company · people discovery | `exa-search` | Rung 2 |67| Thorough multi-source cited report | `deep-research` | Rung 3 — earn it |68| Systematic literature review & synthesis | `scientific-thinking-literature-review` | Rung 3 |69| Judge a paper / proposal / evidence quality | `scientific-thinking-scholar-evaluation` | Rung 4 |70| Biomedical literature (MeSH / PMID / E-utils) | `scientific-db-pubmed-database` | Rung 2, reproducible |71| Patents & trademarks (official IP records) | `scientific-db-uspto-database` | Rung 2, reproducible |72| Genomic DB / sequence / enrichment | `scientific-pkg-gget` | Rung 2, reproducible |73| Map an unfamiliar repo → onboarding guide | `codebase-onboarding` | Rung 1 (local) |74| Step-by-step `.tour` walkthrough | `code-tour` | Rung 1 (local) |75| Up-to-date library/framework docs | `documentation-lookup` | Rung 1 — before web |76| Persist / resume project context | `ck` | Rung 1 — before re-deriving |7778## 5. Conventions for combining spokes7980- "Review the literature **and** rate the key paper" → `scientific-thinking-literature-review`81 → `scientific-thinking-scholar-evaluation`.82- "What's the current state of X **and** save it" → `deep-research` → `ck`.83- "Onboard me to this repo **and** leave a tour" → `codebase-onboarding` → `code-tour`.84- A heavyweight web pass that a docs lookup would answer is an anti-pattern — try85 `documentation-lookup` first when the user named a framework.8687## 6. Shared guardrails8889- **Lightest lane first:** local / docs / `ck` before the web; one source before many;90 scoping before systematic. Escalate only on a real synthesis or verification need.91- **Label every claim** by provenance tier; never fold inference into sourced fact.92- **Date** freshness-sensitive answers; **name** every source; never cite an unopened source.93- **Reproducible** database runs — log query, params, and result IDs.94- **Don't re-derive** what `ck` memory or a prior onboarding already captured.95- Drift-prone MCP spokes: confirm live tool names + quotas before promising coverage.
Sheshiyer