Research knowledge core

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 <date>". 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.