Processing lanes

Knowledge Graph splits ingestion into three lanes, each scheduled independently across your entire corpus. Scheduling is priority-based, not barrier-based: the Structure lane has absolute priority, so a large upload does not wait for embedding or extraction ceremony before becoming keyword and outline searchable.

Priority 1Structure lanePARSE + INDEX · Free (CPU only)

Markdown parse, deterministic chunks, outline tree, FTS, gazetteer keyword graph. Claims engine capacity first, always.

Priority 2Vector laneEMBED · Free local (TEI / Infinity) or metered remote

Batched chunk and entity embeddings, vector indexes, SIMILAR_TO candidates. Consumes remaining capacity once Structure is caught up.

Triggered / budgetedReasoning laneEXTRACT · LLM-metered

Schema-guided LLM extraction, typed relationships, ontology proposals. Runs on demand or under an auto budget, never ahead of Structure.

Scheduling is priority-based, not barrier-based: a 5,000-file upload is fully structure-searchable before any embedding or LLM spend happens anywhere in the namespace.

What full extraction actually costs

Exhaustive LLM extraction across a large corpus is real spend and real time, even with cheap models. Fontana makes extraction selective and lazy by default: you scope it by folder, collection, file list, or entity-dense heuristic, and you always see a forecast before committing. A corpus is searchable the same hour it lands; it is typed-graph-complete only as far as the budget you choose.

Readiness stages

Each file moves through readiness stages as the lanes complete their work. These are not a single binary “processing” flag: the workspace UI shows partial progress so you know exactly what is queryable right now.

PARSESeconds→INDEXSecondssearchable_partial→EMBEDTens of secondssearchable_embedded→EXTRACTMinutes to batchextracted

Structure lane (PARSE, INDEX) always runs first and free. Vector lane (EMBED) follows with remaining capacity. Reasoning lane (EXTRACT) runs only when triggered or budgeted, never ahead of Structure.

Stage	What becomes queryable	Blocks on
PARSE	Markdown text and a heading outline skeleton	Document parsing (anydoc, Docling OCR fallback, JSON or JSONL, or plain text)
INDEX (searchable_partial)	Chunk full-text search, the outline tree, and ontology keyword mentions	A published ontology, for keyword matching; no LLM call
EMBED (searchable_embedded)	Vector hybrid search, and optional entity similarity candidates	Your embedding profile (local or remote)
EXTRACT (extracted)	Typed relationships, upgraded mentions, and entity descriptions	An LLM call and a published ontology

Namespace and folder configuration

You configure each lane per namespace, with folder-level overrides. Configuration is deliberately not a per-file persistent setting: at thousands of files that becomes unusable, so per-file actions (reprocess, extract now, skip) are one-off actions instead.

Setting	Values	Meaning
Structure lane	auto / manual	Parse and index on upload, or only when you trigger it
Vector lane	auto / manual / off	Embed after index, on demand, or never (for full-text and keyword-only namespaces)
Reasoning lane	auto / manual / off	Continuous extraction with a budget, operator-triggered with a forecast, or never
Ontology mining from data	auto / manual	The algorithmic miner feeds draft candidates during the Structure lane, or only on demand
Embedding profile	TEI, Infinity, OpenAI-compatible, or Bedrock Titan	Which embedding provider this namespace uses
Reasoning budget	Dollar cap and model choice	A hard stop for automatic extraction, and a forecast gate for manual runs

You can stand up a namespace and load its ontology before any file exists, or upload data first and let algorithmic mining and discovery propose a schema afterward. Neither order is privileged: the Structure lane gazetteer-matches from whichever file arrives once a published ontology exists.

Cost and time estimation

Fontana shows a forecast before you commit a corpus, and a live ledger while ingest runs:

• Pre-parse estimate (at upload time, before any cost): a token forecast per stage from file bytes, format, and page count, calibrated from your workspace’s own historical ingest costs.
• Post-parse refinement (after PARSE, still before any LLM spend): once markdown exists, chunk and token counts are exact, so embedding and extraction forecasts sharpen into a near-exact estimate.
• Budget governance: a namespace budget cap hard-stops the Vector and Reasoning lanes when the running ledger crosses it. Files remain at their last completed stage, so you can resume later without losing progress.

Incremental reprocessing

Knowledge Graph never rebuilds a whole namespace for one file change, and never blocks search on extraction:

• A content-hash check skips PARSE entirely when a file’s bytes have not changed.
• Reprocessing one file replaces only that file’s lexical and structural subgraph (its chunks, outline, and mentions); shared entities stay in place unless their last evidence disappears.
• If PARSE and INDEX succeed but EMBED fails, the file stays searchable_partial and retries EMBED without re-parsing.
• Publishing a new ontology marks affected files stale for extraction only. Full-text, outline, and vector search remain queryable until you re-extract, and re-extraction only pays for chunks whose content or ontology hash actually changed.