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 entity recognition or embedding before becoming keyword and outline searchable. Between Structure and Vector, the NER lane recognises named entities in each file’s prose with a self-hosted model.

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.

Ingestion calls no language model

Every lane is deterministic. Entity recognition is a self-hosted NER service, not an LLM, so ingesting a corpus costs you nothing per file beyond whichever embedding provider you choose — and the same file yields the same graph every time. The language model sits above the pipeline as a review layer, not inside it.

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
NER (searchable_partial)	Typed entities and mentions from prose, and sentence co-occurrence	The NER service; runs when the namespace’s entity recognition is on
RESOLVE (searchable_partial)	Types for unknown entities, merges of duplicate pairs, relations for strong co-occurrences, verdicts on mined candidate types	TypeSafe System One, when the namespace’s entity resolution is on; metered against the namespace budget
EMBED (searchable_embedded)	Vector hybrid search, and optional entity similarity candidates	Your embedding profile (local or remote)

Namespace and folder configuration

You configure each lane per namespace, with folder-level overrides for the lanes themselves.

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)
Entity recognition (NER)	Platform default / fast / zero-shot / off	fast recognises people, organisations, places and similar with fixed labels mapped onto your entity types; zero-shot types entities straight into your ontology’s entity types and also extracts relationships between them, at a much higher compute cost; the platform default is fast when your deployment runs the NER service
Entity resolution (System One)	On / Off	After NER, hands each file’s open questions to TypeSafe System One for calibrated closed-set decisions; only confident answers are written, the rest waits for the ontology review; charged to the namespace budget
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
Ontology agent	Any eligible agent	The agent that reviews and corrects this namespace’s ontology. One choice per namespace
Budget cap	Dollar cap	A hard stop on language-model spend for this namespace’s ontology review

Entities of the same type whose names are nearly identical are merged automatically when the Vector lane embeds them, so duplicates do not accumulate as a corpus grows.

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): once markdown exists, chunk and token counts are exact, so embedding forecasts sharpen into a near-exact estimate.
• Budget governance: a namespace budget cap hard-stops language-model spend when the running ledger crosses it. Ingestion itself is unaffected — files continue to parse, index, recognise entities and embed.

Incremental reprocessing

Knowledge Graph never rebuilds a whole namespace for one file change:

• 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 re-runs keyword matching for affected files. Full-text, outline, and vector search remain queryable throughout.