Semantic Knowledge Graph (Ontology)
An interactive map of what your assistant knows — its knowledge bases, database tables, and how they connect — so it picks the right source and writes accurate queries.
The Semantic Knowledge Graph is a live map of everything an assistant can draw on: every knowledge base, every database table, and the relationships between them, each carried with a short plain-language description of what it holds. Your assistant reads this map before it answers, so it knows where to look and what each source means instead of guessing.
You don't build the map by hand. When you attach data to a model, Data Hub reads through your sources and writes the descriptions and relationships for you. You can then review, curate, and version the result from Ontology in the Customize Model workspace.
The graph page
Open a Customize Model and select Ontology. You get an interactive canvas where each source is a node and each connection is an edge:
- Knowledge bases and their documents
- Database tables (and views) with their foreign-key links
- Concepts — named entities and facts pulled out of your documents
Click any node to open an inspector with its description, where it comes from, and its details (columns for a table, source documents for a concept). Click an edge to see the relationship it represents — for a document-derived relation, the original sentence it was extracted from. A stats line shows when the map was last scanned and how long it took.
Generating the map
Generation takes a description language. Table, column, shared column name, and knowledge base descriptions are all written in that language, and business logic drafted afterwards follows it too.
Regenerating runs an AI describe step on the assistant's base model, billed to the owner's wallet, so you're asked to confirm before it spends. Descriptions you've edited by hand are what the assistant reads — regenerating refreshes the AI-written ones.
What the map captures
The graph is built from two pipelines, one per kind of source.
For each connected database, Data Hub reads its tables, columns, and foreign keys and produces:
-
One node per table with a one-line description of what it stores.
-
Column descriptions — a short note on what each column actually means, because real column names are often terse or cryptic.
-
Relationships — a foreign-key edge wherever one table references another, so the assistant knows how to join them.
-
Value domains — a column with few distinct values (status codes, category codes) is recorded together with its complete set of values, for example
status_cd ∈ {OPEN, PAID, CANCELLED}, so the assistant never has to query the database just to learn which values exist.
While writing descriptions, the platform reads a few real rows according to that connection's AI sample rows setting — a column named f_0001 cannot be described from its name alone. Sampling respects the connection's own permissions, and sampled values are used only for that description and never stored in the map. Set the connection's sample rows to no sampling to turn it off entirely.
Table and column descriptions are the single most useful part of the map. They're what let "revenue by region last quarter" land on the right fields even when nothing is named revenue or region.
For each knowledge base, Data Hub captures:
- One node per knowledge base, with a summary of what it's about, plus a node for each document it contains.
- Concepts — the people, organizations, contracts, amounts, dates, and terms mentioned across your documents, merged so the same entity is one node no matter how many documents name it.
- Relationships between concepts — facts stated in the text (for example, this contract → renewal amount → USD 380,000), each kept with the sentence it came from so you can trace it back to the source document.
Curating descriptions
The map is yours to refine. In a node's inspector you can:
- Edit a source's description — rewrite the summary the assistant reads. If it keeps reaching for the wrong table, this is usually the fastest fix.
- Describe individual columns — add or edit the note on any column inline.
- AI regenerate a single table's description without rebuilding the whole graph.
Better descriptions mean better answers. A few precise edits on the tables you query most often go a long way toward accurate results.
Keeping the map fresh
Open Auto-update to have the graph rebuild itself when its data changes, instead of clicking Regenerate by hand. You can turn on rebuilds:
- after a data sync — when a connected dataset refreshes,
- after a knowledge-base sync — when documents are added or updated,
- on live database changes — throttled so a busy source doesn't rebuild constantly.
Versions and snapshots
Every rebuild is saved as a snapshot, so the map has a version timeline along the top of the page. Click a point on the timeline to time-travel to that version (read-only), or use Compare with previous to see exactly what changed — nodes added since the last version are ringed, and nodes that were removed appear as ghosts. It's an easy way to confirm a schema change or a new batch of documents landed the way you expected.
How the agent uses it
Before your assistant answers, the map is handed to it as a compact data map — a list of the sources it can use and what each one is for. With that in context it can:
- Choose the right source — search the documents for a policy question, query the database for a numbers question — without spending a step to discover what exists.
- Write accurate queries the first time. For text-to-SQL, the foreign-key relationships also pull in tables the question never names — so a join to
customersstill happens when you ask for "orders by region" — and the table and column descriptions point the query at the right fields. - Stay focused on your data, since only the sources you've attached appear on the map.
The map underpins both plain-language answers and Conversational BI charts — both rely on the assistant reaching for the right source and reading it correctly.