Ontology

An ontology is the schema layer that turns provisional keyword mentions into a typed world model: entity types, relation types, and the patterns that connect them (Owner -[:HAS]-> Pet). Fontana’s Ontology Builder is standalone and runnable at any point in a namespace’s life: you can publish a schema before a single file exists, or upload your corpus first and let Fontana propose one from what it finds.

Building an ontology

You can build a schema through any combination of three sources:

Bring your own: author a schema directly in the Fontana ontology JSON format, then publish.
Algorithmic mining: Fontana’s free, no-LLM miner reads structure that is already explicit in your corpus (CSV and spreadsheet column headers, markdown table headers, repeated capitalized phrases and acronyms, folder and filename patterns) and emits draft candidate types with evidence counts for you to review.
AI discovery: on demand, Fontana samples representative chunks from your corpus and proposes a schema (entity types, relation patterns, aliases) using your namespace’s strongest configured model, since schema errors compound into every downstream extraction. You edit the proposal, then publish.

Neither order is privileged: schema-first and data-first namespaces both consume the same publish step, and publishing a schema for the first time triggers a cheap keyword re-index (seconds per file, no LLM) rather than a full reprocess.

Schema format

Fontana keeps your schema as Fontana ontology JSON: a closed-world, schema-first property-graph schema that your gazetteer matching and schema-guided extraction consume directly. Fontana does not import or export LinkML, SKOS, OWL, RDFS, or JSON-LD today. If you maintain a schema in one of those formats, translate it into Fontana ontology JSON before you publish it.

Entity type hierarchy

Entity types in a namespace form a hierarchy. Every entity type has at most one parent. A type with no parent is a top-level type. A type placed under a parent is a kind of that parent: Bond is a kind of Debt instrument, which is a kind of Instrument.

Fontana’s built-in types come with these default parents:

Parent	Kinds
Organization	Legal entity, Government entity, Not-for-profit organization, Financial institution
Legal entity	Corporation, Partnership, Trust, Sole proprietorship
Corporation	Private limited company
Instrument	Equity, Debt instrument, Derivative, Loan
Equity	Share
Debt instrument	Bond, Asset-backed security
Derivative	Option, Future, Forward, Swap
Swap	Credit default swap
Loan	Mortgage
Collective investment vehicle	Fund
Fund	Private equity fund, Private credit fund, Investment fund
Account	Cash account, Securities account
Transaction	Trade, Payment, Capital call, Distribution
Trade	Foreign exchange trade
Payment	Credit transfer, Direct debit
Corporate action	Dividend, Stock split, Merger, Rights issue, Spin-off
Document	Agreement

Every other built-in type is top-level. That includes Person, Organization, Party, and party roles such as Issuer, Investor, Custodian, and Counterparty.

When a type is first created in a namespace, it is placed under its default parent. A type is created when a file is processed and something of that type is recognised, or when the Ontology Agent proposes it. Any parent the namespace does not have yet is created with that type. A namespace that recognises Bond also has Debt instrument and Instrument, even when those two are not on its recognition list. The recognition list is the entity types included on the Ontology tab’s Recognition view. Recognition looks only for the types on that list.

A type that already exists keeps the parent it has, including a parent you chose. A new type created under a parent you have moved follows that parent.

A relation type declared between types also applies to their kinds. A relation whose source is Instrument applies to a Bond. Entity search by type includes kinds: asking for entities of type Instrument returns Bonds as well.

You change a parent on the Types view of the Ontology tab. With write access to the namespace, Move under… places a type under another type, and No parent makes it top-level. Kinds of the moved type move with it. Fontana refuses a move that would place a type under itself or under one of its own kinds, and shows the reason. Each move is recorded in the activity log.

Evolution policy: strict, log, evolve

During extraction, an LLM inevitably encounters entities or relationships that do not fit your published schema. You choose what happens to that off-schema signal, per namespace:

Policy	Behavior
`strict`	Off-schema types and patterns are dropped; only schema-conforming facts are written
`log`	Off-schema patterns (entity type → relation type → entity type) are queued in the proposal inbox with endpoint evidence; unknown instance relationships are not written until you accept and publish
`evolve` (default)	Off-schema patterns are applied to the published ontology in the same review pass, and matching instance relationships are written in that run (no second run solely to unlock the fact)

Under log, schema drift is an explicit review decision in the proposal inbox. Under evolve, Fontana grows the schema and writes the fact together; the inbox stays empty for that path.

When the Ontology Agent proposes a new entity type that is a kind of an existing one, it can name that type as the parent. With evolve, the type is added under that parent. With log, the proposal is kept for review with its parent. With strict, the proposal is dropped. The agent cannot move a type that already exists; you do that on the Types view of the Ontology tab.

Ontology tab

Open a namespace in KG Studio and choose Ontology. The tab has three views.

Recognition opens first. It is the standards picker and the included entity-type list, with Save and Reset to default. An unsaved change is still there when you switch to another view and come back.

Types shows the namespace’s entity types as a tree. Move under… and No parent change a type’s parent, as described in Entity type hierarchy.

Relations is a read-only list of each relation type and the types it goes from and to.

Types and Relations show the schema the namespace has. A type on the recognition list appears in Types once a file has produced it.

Where the ontology is kept

A namespace keeps its ontology as a file in Fontana Files, .fontana/kg/ontology.json. The file holds the draft and published schema, the evolution policy, the proposals that were accepted or rejected, and the proposals the Ontology Agent made that still wait for review. Every change to the ontology is written to that file first and to the graph after it: the evolution policy you set in KG Studio, a term the Ontology Agent proposes, or a proposal your policy applies. Proposals mined from your documents, and the evidence behind them, are not kept in the file; they come back when the graph reloads your documents’ processing results.

What the Ontology Agent writes about instances, its facts, the entity types it sets and the entities it merges, is appended to .fontana/kg/manual-triples.jsonl in the same namespace before it reaches the graph. Merge decisions go to .fontana/kg/finalize-decisions.jsonl. When the graph is rebuilt, Fontana loads the ontology first, then your documents’ processing results, then these files in the order they were written, so the rebuilt graph holds the same schema and the same curated facts without a model call. See Architecture.

Provenance of mined types

Every entity type Fontana mines from your documents keeps a record of where it came from: the documents whose headings, table headers, acronyms, or capitalised phrases produced it, and how often it occurred in each. Select a type in the KG Studio graph to see its Provenance, and switch on Entity types with Entities to see every entity attached to its type. When you reprocess or delete a document, its evidence is updated with it.

What publishing does and does not invalidate

Publishing a new ontology version is cheap for most of your corpus:

Data	Effect of a new publish
Chunks, outline, full-text index, embeddings	Untouched; never invalidated by a schema change
Keyword mentions and co-occurrence signals	A cheap keyword re-index job re-scans each file (seconds per file, no LLM)
Typed relationships and LLM-derived mentions	Marked extract-stale (hash mismatch); re-extraction is explicit and budgeted, not automatic

This is what makes running the Ontology Builder at any time safe: the expensive layers of your pipeline, parsing and embedding, are schema-independent by construction, so evolving your schema never forces a full reprocess of a large corpus.