Code and mixed corpora

Knowledge Graph’s ingestion pipeline is not one universal extractor. The generic document path (parse to markdown, chunk, gazetteer match, optional LLM extraction) is the default module; content types with exploitable structure get their own extractor module that builds the graph algorithmically, often making the LLM extraction stage unnecessary entirely.

The module contract

Every extractor module declares the same four things, so retrieval, citations, Finalize, and the evaluation harness work identically regardless of which module produced the graph:

Contract element	What it declares
Selector	Which files this module claims, by format or content signature and namespace preferences. The generic document module is always the fallback.
Stages fulfilled	Which readiness stages the module delivers, and how. A module may complete EXTRACT algorithmically, with no LLM call, and mark a file extracted directly from INDEX.
Ontology pack	An optional pre-defined, versioned ontology the module publishes into the namespace, using the same JSON contract as an author-written ontology.
Cost profile	The per-stage cost class (free, embed, or LLM), so the cost estimator prices mixed corpora correctly. A repository of source code forecasts near-zero EXTRACT cost, for example, because that module never calls an LLM to build its graph.

You can override module selection automatically (by file signature) or explicitly, at the namespace or folder level, when you want to force a particular module.

Document module (default)

Any file without a more specific module runs the generic document path: parse to markdown, deterministic chunking, outline building, ontology gazetteer matching, and optional LLM-based extraction against your published schema.

Tabular module

CSV, spreadsheet, and JSON files with a record shape (an array of objects, or JSONL object rows) get column-aware chunking. Nested JSON objects become a heading outline from their keys. Headers and object keys feed the Ontology Builder’s algorithmic miner as candidate entity types and attributes. JSON may be UTF-8 or UTF-16 (including a BOM).

Code module

Source code repositories get a dedicated module built on Tree-sitter, covering Python, JavaScript and TypeScript, Go, Java, and Rust:

1. Selection: file extensions and repository markers (package.json, pyproject.toml) identify a code corpus; binary assets are skipped.
2. Parsing: per-language Tree-sitter grammars extract definitions, imports, calls, class hierarchies, and exports.
3. Graph mapping: a pre-defined code ontology pack maps that syntax tree onto Repository, Package, Module or File, Class, Function, and Interface or Type entities, connected by IMPORTS, CALLS, DEFINES, EXTENDS, IMPLEMENTS, and EXPORTS relationships, each with MENTIONS evidence pinned to an exact file and line span.
4. Outline: the structural overlay becomes your module, class, and function hierarchy, which maps onto source code naturally.

Because Tree-sitter parsing is syntactic and deterministic, the code module completes EXTRACT algorithmically, at INDEX time, with zero LLM spend. An LLM is only used for an optional, separate enrichment pass that generates human-readable summaries on top of the algorithmic graph.

Why Tree-sitter and a thin mapping, not a code-analysis framework

Tree-sitter grammars are battle-tested, incremental, and native, the same technology Fontana’s own code-review-graph MCP tooling uses. The graph mapping from a syntax tree to Fontana’s schema is deliberately the small, in-house part: it has to target the same provenance, collection, and Falkor vocabulary as every other module anyway, so adopting a heavier code-analysis framework would add infrastructure without adding graph value.

Mixed corpora

A single namespace can hold documents, spreadsheets, and source code side by side. Fontana routes each file to its matching module independently, so a monorepo with a docs/ folder gets typed code relationships from the code module and a governed document graph from the generic module, both landing in the same Falkor graph with the same node and edge vocabulary, and both queryable through the same retrieval lanes.