Graphs & Provenance
Structured knowledge graphs are core to Insight LM — they are what separate it from tools that let a language model create objects freely. The long-term direction is simple to state: the system of record is the graph, not a pile of files. Documents don't disappear — they become views of graph-held knowledge, so they can't quietly go stale the way dead documents do.
This page is candid about what ships today versus what is in active build.
What ships today
An in-app ontology and query service. Insight LM includes its own graph service — no external database required — organized as three rings:
- a core ontology: the reviewed, read-only vocabulary the application itself is described in;
- a growth ring: new vocabulary can be added organically during work, but is never auto-merged into core — promotion is a deliberate human review act;
- an instance ring: rows recording actual work as it happens.
The Assistant queries all three with SPARQL, so "what do you know about X?" is answered from the graph, not from model memory.
File-based graphs as first-class documents. Turtle (.ttl) files live
inside workbooks like any other document, with a dedicated viewer offering
source, rendered, and diagram views. Teams can keep graphs in files, version
them alongside other work, and still get graph tooling — both modes are
supported, and that stays true.
Write-once, versioned graph publishing. Published graphs are immutable snapshots with stable, versioned identifiers. A snapshot can never be silently edited — the application enforces this, rejecting ambiguous updates. This is what makes notebook analyses reproducible: a computation pins the exact graph version it read, so re-running it later means re-reading the same facts.
A gated publish workflow. Getting a graph published goes through a governed pipeline — discovery, version gate, verification, receipt read-back, exactly-once commit — run by the Assistant but checked deterministically at every step.
Provenance on claims. References link generated artifacts back to the sources that support them, and published graphs carry provenance metadata about where their contents came from.
Ontology stewardship. A bundled ontology extension ships with a steward agent that walks a user from a vocabulary need to a drafted, agreed, published ontology through the same gated workflow — keeping graph growth structured instead of free-form. See Managing Ontologies.
Optional external stores. Deployments can attach external triple stores and graph databases through extensions. These are always references, never dependencies — core capabilities work with the in-app graph service alone.
Where this is going (in active build)
Full work capture: the decision loop. Real work follows a loop — an event raises a question; assumptions are declared; data is gathered; models are built; simulation and analysis run; a decision is made; artifacts ship; and the decision itself becomes the next event. The core ontology already carries preliminary vocabulary for every station of that loop, including candidate decisions and decision ensembles. The build goal is that the whole loop is captured in the graph as it happens — so "why did we decide this?" is a query, not an archaeology project.
Graph as the system of record. Today the graph records work; the direction is that views, dashboards, and documents become projections of the graph, generated from it and traceable to it. Where results are produced, the aim is graph-only capture — no side files whose contents can drift from the record.
Ontology stewardship, deepened. The steward ships today; in build are richer review tooling for promoting organically grown vocabulary into the reviewed core and broader lifecycle support around published ontologies.
Graph-first extensions. New extensions are being built with graphs as their base layer. The first is a lightweight systems-modeling extension (SysML-inspired) where the model is a file-based graph in the workbook, the Assistant is a first-class modeler working through structured methods, and edits reload live. The pattern generalizes: an extension's domain objects live in the graph and inherit provenance and traceability for free.
Provenance-aware CI and automation. We are starting to run our own continuous integration with these same graph features: builds, verification runs, and automations record provenance (PROV) into the graph as they execute. The goal is a system that self-integrates capability — an automation's outputs, checks, and lineage land in the graph the same way a user's work does, and are queryable the same way.
A system that extends itself — governed. Extensions already contribute agents, skills, and workflows through the public Extension API, and the Assistant can author new extensions using those same structured methods. Hot-loading of extensions is in build; today a new extension requires a restart. Together these point at a carefully governed form of self-evolution: the Assistant proposes and builds capability, deterministic gates and human review decide what lands, and the graph records the provenance of every step.
A workspace that grows with the graph. As graphs accumulate, the surfaces of the application — views, dashboards, documents — grow out of them rather than being hand-maintained.
Items in this second list are under active development and evolving by design — vocabulary marked preliminary, interfaces still moving. We publish the direction because it drives the architecture that already ships.