Skip to main content

Managing Ontologies

An ontology is a team's shared vocabulary, written down precisely: the things a domain talks about, what properties they have, and how they relate. When that vocabulary is explicit, people and the Assistant mean the same thing by the same word — and everything recorded against it stays queryable instead of ambiguous.

Insight LM treats ontologies as working artifacts you manage, not reference material you file away. This page covers how that management actually works.

Vocabulary grows in rings​

The built-in graph service (see Graphs & Provenance) organizes vocabulary in three rings:

  1. a core ontology — reviewed, read-only, the vocabulary the application itself is described in;
  2. a growth ring — new vocabulary added organically during work;
  3. an instance ring — rows recording actual work as it happens.

The important rule sits between the first two: new terms can appear freely in the growth ring, but nothing is auto-merged into core. Promotion is a deliberate human review act. Vocabulary can grow at the speed of work without the reviewed core silently accreting whatever a model made up on a Tuesday.

Ontologies are files in your workbook​

A domain ontology lives in the workbook as a Turtle (.ttl) document — a normal file you can read, version, diff, and share, with a dedicated viewer offering source, rendered, and class-diagram views. There is no hidden database it disappears into: the file is the record, and the graph service holds a copy for querying. The same versioning that covers every workbook file covers the ontology (see Versioning & History).

The ontology steward​

Writing a good ontology is a skill most teams don't have in-house, so Insight LM ships one: the ontology steward, an agent bundled with the application. A stewarded session runs in three deliberate stages:

  1. Co-design. You describe the domain in plain language; the steward drafts a small, focused vocabulary with you in chat — classes, properties, relationships — applying lifecycle practices like validation shapes and pinned imports so the draft is well-formed from the start.
  2. Agreement gate. Nothing proceeds until you explicitly agree the draft says what you mean. This is a real stop, not a courtesy prompt.
  3. Governed publish. The agreed ontology goes through the same gated publish workflow every graph uses — discovery, version gate, verification, receipt read-back, exactly-once commit — so the published version is checked deterministically, not just generated confidently.

The steward works out of the box against the built-in graph service. If a deployment attaches an external triple store through a connector extension, the steward can publish to the shared store as well — and it will tell you plainly when a capability needs infrastructure you haven't attached, rather than failing mysteriously.

Published means immutable​

A published ontology is a write-once, versioned snapshot with a stable identifier. Revising it produces a new version; the old one remains exactly as everything that referenced it saw it. That is what lets analyses, models, and documents pin the vocabulary version they were built against and remain reproducible later.

Where this is going​

The stewardship loop is young and deliberately conservative. In active build: richer review tooling for growth-ring promotion, and graph-first extensions whose domain objects are defined against published ontologies from the start — so new capability arrives already speaking a governed vocabulary.