Querying ontology data

Chat can answer questions about your organization's structured data — any ontology object type backed by a data source (incident reports, installations, observations, sensor readings, …). Ask in natural language; Chat discovers what data exists, filters it, and summarizes the matching records.

How it works

Four chat tools work together:

1. ontology_list_types — discovers the queryable surface: every object type across your readable ontologies that is backed by a data source. Chat calls this first when it doesn't know what data is installed.
2. ontology_query — fetches matching records for one or more object types, with optional filters and a row limit. Chat then reasons over the returned rows to answer your question.
3. ontology_search — hybrid search: an LLM translates the question into a structured ontology query (including relationship traversals — see below) while a keyword grep runs alongside it; results are merged with provenance tags.
4. ontology_neighbors — walks the ontology graph one hop from a known record: everything linked to it, with the relationship name and direction.

No configuration is required — installing a pack that ships data sources and an ontology makes its object types queryable immediately.

Asking questions

Ask Chat naturally. Examples that trigger a data query:

• "How many critical drone incursions were detected this month?"
• "List the defense installations in Estonia"
• "Which incidents mention GPS jamming? Summarize the latest three."
• "Compare incursion counts per country since June 1st"

For geospatial questions ("show them on a map"), Chat uses the map visualization tool instead — the two compose: ask for a filtered summary first, then "plot those on a map".

Following relationships

Ontologies declare link types between object types (a unit operates a UAV, an incident references an installation). Chat uses them two ways:

• Relational questions in one shot — "which UAVs does Falcon Squadron operate?" translates into a search that filters one type through its relationship to another. This works for any reference link whose link type declares a join rule (join: { sourceColumn, targetColumn } on defineLinkType); links without a join rule are reported back honestly ("this link needs a join rule") instead of silently returning unrelated keyword matches.
• Exploring from a known record — after any query or search result, Chat can ask for the record's neighbors: every linked instance, the relationship it came through, and its direction. Follow-up questions like "what else is connected to that installation?" resolve this way.

Listing questions that name a type directly — "print me all my drone observations" — also resolve through the ontology: when your question names one of the ontology's types, search returns that type's instances as structured matches rather than falling back to keyword hits. Relationship questions that would need two hops (X observed as O, O near Y) are answered one hop at a time; when a single search can't express the chain, the answer says so explicitly instead of returning an empty result.

Both paths run over the same governed reads as everything else — masked columns and clearance filtering apply before any linking happens.

Filters

Chat translates your question into filter clauses, combined with AND:

Result limits

Responses are kept compact so the conversation stays fast:

• Up to 100 rows per object type per query (Chat defaults to 25).
• Long text fields are trimmed in tool results.
• When more records match than are shown, Chat is told the honest totals ("Found 70 incursions. Showing the first 25.") so it can refine the filter or aggregate instead of guessing.

Access control

Queries run under your workspace scope: only ontologies readable in your workspace are searched, and rows come from the same governed projection that powers the rest of the platform — there is no side channel to the underlying tables.