Skip to main content

Overview

The Knowledge Learning Pipeline is a two-stage process that transforms raw sources (repositories, research, experiments) into structured wiki pages in the Knowledge Graph.

Using the Pipeline

Full Pipeline

Via Kapso API

Extract Only (No Merge)

Source Types

The Source namespace provides typed wrappers for knowledge inputs:

Stage 1: Ingestors

Ingestors extract WikiPages from sources. Each source type has a dedicated ingestor.

IngestorFactory

RepoIngestor

The most sophisticated ingestor, using a two-branch multi-phase pipeline: Phase 0: Repository Understanding (pre-phase)
  • Parse repo structure, generate _RepoMap.md with AST info
  • Agent fills in natural language understanding for each file
  • Subsequent phases read this file instead of re-exploring
Branch 1: Workflow-Based Extraction
  • Phase 1a: Anchoring - Find workflows from README/examples, write Workflow pages + rough WorkflowIndex
  • Phase 1b: Anchoring Context - Enrich WorkflowIndex with detailed implementation context
  • Phase 2: Excavation+Synthesis - Trace imports, write Implementation-Principle pairs together
  • Phase 3: Enrichment - Mine constraints/tips, write Environment/Heuristic pages
  • Phase 4: Audit - Validate graph integrity, fix broken links
  • Phase 4b: Repo Builder - Create GitHub repositories for workflows
Branch 2: Orphan Mining (runs after Branch 1)
  • Phase 5a: Triage (code) - Deterministic filtering into AUTO_KEEP/AUTO_DISCARD/MANUAL_REVIEW
  • Phase 5b: Review (agent) - Agent evaluates MANUAL_REVIEW files
  • Phase 5c: Create (agent) - Agent creates wiki pages for approved files
  • Phase 5d: Verify (code) - Verify all approved files have pages
  • Phase 6: Orphan Audit - Validate orphan nodes

Research Ingestors

Research ingestors convert web research results into WikiPages using a three-phase agentic pipeline: Phase 1: Planning
  • Analyzes content and decides what pages to create
  • Writes _plan.md with page decisions
Phase 2: Writing
  • Creates wiki pages following section definitions
  • Writes pages to staging directory
Phase 3: Auditing
  • Validates pages and fixes issues
  • Ensures graph integrity
There are three specialized research ingestors:

Stage 2: Knowledge Merger

The merger uses a hierarchical sub-graph-aware algorithm with a single Claude Code agent call. It processes connected pages as units, respecting the Knowledge Graph DAG structure.

Wiki Hierarchy

The Knowledge Graph follows a top-down DAG structure:

Merge Algorithm

The merger executes a 5-phase process: Phase 1: Sub-Graph Detection
  • Parses outgoing_links to build an adjacency list
  • Finds root nodes (no incoming edges from proposed pages)
  • Groups connected components into sub-graphs
Phase 2: Planning (Top-Down)
  • For each sub-graph, makes merge decisions starting from root:
    • Root decision: Search for similar pages of same type → MERGE or CREATE_NEW
    • Children decisions (recursive):
      • If parent = CREATE_NEW → child inherits CREATE_NEW (no search needed)
      • If parent = MERGE → search only among target’s children → MERGE or CREATE_NEW
    • Special case: Heuristics with multiple parents use lowest parent for scoped search
  • Computes execution order (bottom-up): Environment → Heuristic → Implementation → Principle
  • Records deferred edges (which parent adds edge after processing)
Phase 3: Execution (Bottom-Up)
  • Processes nodes in computed order
  • For CREATE_NEW: Get page structure, prepare content, call kg_index
  • For MERGE: Get page structure, fetch target, merge content intelligently, call kg_edit
  • Updates outgoing_links to point to processed children’s result_page_id
Phase 4: Audit
  • Verifies nodes exist (CREATE_NEW/MERGE)
  • Verifies edges (parent has edge to child’s result_page_id)
  • Handles failures with retries (max 3)
Phase 5: Finalize
  • Collects all result_page_id values
  • Categorizes as created (CREATE_NEW) or edited (MERGE)
  • Writes final summary to _merge_plan.md

Merge Actions

Edge Types

Important Rules

  1. Same-type search only: Principles search among Principles, Implementations among Implementations, etc.
  2. Scoped search: When parent is MERGE, children search only among the target’s children
  3. Inherited CREATE_NEW: If parent is CREATE_NEW, all descendants are CREATE_NEW (no search)
  4. Additive edges: When merging, keep existing edges and add new ones
  5. Bottom-up execution: Process leaves (Environment, Heuristic) before parents
  6. No cross-type merges: Never merge a Principle with an Implementation, etc.

MCP Tools Used

The merger uses these MCP tools via the kg-graph-search server:

Using the Merger

Merge Modes

The merger operates in two modes based on whether a KG index exists:
  1. No Index Mode: Creates all pages as new, writes to wiki directory, then creates index
  2. Merge Mode: Runs agentic hierarchical merge using MCP tools
Index detection order:
  1. Explicit kg_index_path from config
  2. Auto-detect .index file in wiki directory

Merge Result

WikiPage Structure

CLI Usage

CLI Options

Pipeline Result