Processing lanes

Knowledge Graph splits ingestion into steps that each keep their own record for every file: what input the step ran on and what it produced. Those records, and everything a step produces, live with the Knowledge Graph engine on its own disk. Your files stay as you uploaded them, and nothing is written back among them. A step runs again only when that input changed, so a restart, a crash or a paused namespace loses nothing, and the same file yields the same result. Index writes a file into the graph as soon as Parse is done, so a large upload becomes keyword and outline searchable before entity recognition or embedding finish; NER and Embed run beside each other after Parse, Resolve follows NER, and Index writes each of their results as it lands.

Ingest and search

Hover any node in the processing graph to read what that step does and its current counts. The diagram above is ingestion for one file. Parse turns the file into markdown and an outline. Index splits it into chunks and keyword search. Embed writes a vector for each chunk. Entity recognition extracts entities and relations. Resolve types unknown entities, merges duplicates, and adds relations. Ontology review corrects those types.

Under that diagram, the Edges card compares edges that came from parsing with edges that came from extraction.

A question follows a separate path. The assistant searches with full text, embeddings, and a Cypher graph hop, then fuses them by rank. Co-annotation is an extra lane on that search. See Retrieval.

Ingestion calls no language model

Every step 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 steps complete their work. These are not a single binary “processing” flag: the workspace UI shows each step’s 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	Chunk full-text search, the outline tree, and ontology keyword mentions; later also what NER, Embed and Resolve produced	Parse, then each later step as it finishes. The Index count reports a file as done only once every enabled step before it has landed, so it climbs once and its total means finished
NER	Typed entities and mentions from prose, and sentence co-occurrence	The NER service; runs when the namespace’s entity recognition is on
RESOLVE	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	Vector hybrid search, and optional entity similarity candidates	The platform embedding profile on Models → Embeddings

Namespace and folder configuration

You configure each stage per namespace, with folder-level overrides for parse and index and for embeddings.

Setting	Values	Meaning
Parse and index	On / Off	On parses and indexes each file when it arrives. Off leaves the file until you reprocess it
Embeddings	On / Off	On embeds after indexing. Off embeds only when you choose Embed now on a file
Entity recognition (NER)	On / Off	On recognises people, organisations, places and similar entities in each file’s prose with the entity recognition service installed on your platform. Off skips that step
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	On / Off	On proposes types from table headers, headings and acronyms while files are indexed. Off does not
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 Embed writes their vectors, 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: Index 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:

• Parse runs on the file’s committed content id, so a re-upload of identical bytes is a no-op and an edited file parses again without the engine hashing it.
• 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 by keyword and outline, and Embed retries on its own without re-parsing. A failure that needs you shows on the Status board with a Retry action.
• Rebuild graph on the namespace menu drops the graph and replays it from the processed files: no parsing, entity recognition or embedding runs again.
• Publishing a new ontology re-runs keyword matching for affected files. Full-text, outline, and vector search remain queryable throughout.