Research Knowledge Pipeline

Research Knowledge Pipeline

Purpose

Coordinate the user's research stack: source-grounded research, browser-native output, Obsidian/wiki capture, and learning support when useful.

For research-learning work, HTML is the canonical deliverable. Treat the final HTML as a textbook-grade artifact: the user should be able to learn the topic by reading the HTML itself, as if it were a textbook chapter, mini-textbook, or whole private course. Source links, source matrices, Markdown drafts, notebooks, and Obsidian notes are support artifacts; they must not carry the main substance instead of the HTML.

Sub-Skills

• REQUIRED SUB-SKILL: Use deep-research-brief for evidence strategy, source appraisal, matrices or memos, synthesis, uncertainty, and citation verification.
• REQUIRED SUB-SKILL: Use html-output for the default final deliverable unless the user explicitly asks for chat-only or another format.
• REQUIRED SUB-SKILL: Use obsidian-wiki-maintainer when the vault is available or the user asks for wiki, vault, Obsidian, notes, or knowledge-base updates.
• CONDITIONAL SUB-SKILL: Use learning-session when the user asks to learn, practice, quiz, or understand; when the topic is conceptually dense; or when tutoring would make the research reusable.
• REQUIRED TEXTBOOK CONTRACT: When research produces a substantial lesson, chapter, course, field guide, or canonical teaching artifact, use learning-session and apply its canonical textbook lesson contract after the evidence memo passes. The research pipeline owns evidence quality; the learning contract owns teaching architecture and pedagogy.

If a sub-skill is unavailable, follow the closest local workflow and report the gap.

Orchestration Contract

1. Define the research question, decision context, freshness needs, scope, expected outputs, and vault availability. State reasonable assumptions instead of blocking unless the missing fact changes source choice or note location.
2. Declare the deliverable contract before building. Name the canonical artifact, normally HTML, and list what it must contain: thesis, prerequisites, mechanisms, worked examples, counterexamples, uncertainties, source-grounded claims, retrieval checks, and transfer exercises.
3. Run the research workflow first. Keep a working capture ledger with accepted sources, source-note candidates, concept-note candidates, key claims, uncertainties, and review items.
4. Write the teaching synthesis before polishing the artifact. For expert-track or learning requests, apply the learning-session textbook contract so the synthesis has a dependency-aware chapter architecture, field-appropriate rigor, worked reasoning, boundaries, progressive practice, synthesis, and transfer. Do not treat source count, source links, or reading lists as substitutes for teaching.
5. Update Obsidian progressively but carefully:
   • create source notes after a source is accepted;
   • mark immature synthesis as draft;
   • promote or update concept and map notes only after citation verification;
   • preserve source URLs or paths, dates, limitations, confidence, and backlinks.
6. Build the HTML artifact from verified synthesis. Include the main lessons in the page itself, not only summaries or links to Markdown/source files. The HTML should be self-contained enough to teach the user, while still pointing to original sources for deeper study.
7. Add the learning track:
   • default to compact retrieval checks in the brief and HTML;
   • run a full active learning loop when requested or clearly valuable;
   • end with spaced review prompts or next exercises.
8. Run the required gates before final response:
   • evidence gate: citations support load-bearing claims, weak evidence is labeled, and source limitations are visible;
   • substance coverage gate: the canonical HTML includes the actual lesson body, not just an overview, source spine, or reading plan;
   • artifact equivalence gate: if a Markdown memo/course/notebook contains substantive teaching, verify the HTML contains the same core substance or explicitly explain any intentional exclusion;
   • semantic fidelity gate: verify math, code, figures, captions, cross-references, tables, and citations survived conversion and render as intended;
   • depth critique gate: for expert-track work, run a critique pass asking where the artifact is still shallow, generic, over-neat, source-dumpy, or unable to help the user generate novel work;
   • visual/render gate: render the HTML on desktop and narrow/mobile widths, check console errors, horizontal overflow, missing assets, hidden text, and main interactions;
   • vault gate: vault file changes are intentional and marked draft/reviewed appropriately.

Final Response

Report:

• HTML artifact path or why no HTML was produced.
• Whether the HTML is the canonical deliverable and what textbook-grade content it contains.
• Vault path touched and files created or modified, or why no vault update happened.
• Source count/types and key confidence level.
• Learning output included, offered, or skipped.
• Evidence, substance coverage, artifact equivalence, semantic fidelity, depth critique, and render checks performed.
• Open review items, inaccessible evidence, or claims needing user judgment.