Overview
How the platform builds, maintains, and surfaces your organization's knowledge.
The platform maintains a single structured model of your organization's knowledge — your ontology — and keeps it current as the systems and documents it describes change over time. The Ontology Agent builds and maintains this ontology, reading from and writing to a single source of truth so your structured definitions stay aligned with reality as your systems and documents change.
How it works
The system operates in three stages — build, maintain, and surface — which also describe the lifecycle of any piece of knowledge it holds.
The Ontology Agent reads your documents and connected data sources and instantiates the primitives that compose your ontology: Thing Type Definitions, Metric Definitions, and Templates. You review each proposed primitive, edit it as needed, and publish it.
As the underlying sources change — a revised specification, a new data field, a hardware revision — the same agent detects the drift and proposes targeted updates to the affected primitives. The model stays aligned with reality instead of decaying after each change. Users can also edit and maintain ontology resources and links via API, Agent, or Console.
The published ontology is continuously available as a structured, queryable model that your teams, applications, and agents build on — and, through the representation layer below, as the foundation every downstream capability consumes.
The design goal is to provide the rigor of a typed ontology and broad accessibility — to your teams, applications, and agents — at the same time, rather than trading one for the other.
One representation, many tasks
The ontology is the durable model of your domain. On top of it, the platform continuously produces a representation of every Thing: a compact numerical encoding (an embedding) of how that Thing is behaving over a window of time. Raw sensor values are a poor basis for comparison — two Things doing the same work can produce different traces. The representation re-encodes behavior so that meaningful similarity becomes measurable: Things behaving alike sit close together, Things behaving differently sit far apart.
Each representation fuses up to four sources of signal, all anchored to the ontology:
- Behavior — the Thing's Metrics over a time window.
- Identity and location — its Thing Type Definition, its properties, and its Place in your hierarchy.
- Reference knowledge — the documentation linked to its Thing Type.
- Event history — records linked to the specific Thing, incorporated only as of when they occurred, so the representation never sees an event before it happened.
Because the representation is general-purpose, capabilities that would each be a separate modeling project become lightweight configurations on a shared foundation — find similar Things, detect drift from a Thing's own baseline, detect anomalies against a peer cohort, spot emerging patterns, and predict outcomes like fault risk or remaining useful life. Build a capability once and it applies across every Thing Type; add a new Thing Type and every existing capability applies to it immediately, the moment data starts flowing — no upfront training project.
A closed loop
The platform learns from what happens next. A predictor's output can be instantiated as a derived Metric Definition — a first-class part of the same model everything else speaks. Monitors watch that metric and fire through egress Integrations into your operational systems as work orders and alerts; the outcomes flow back through ingress Integrations as new measured metrics, linked to the Things they concern, sharpening the next prediction. See Workflows for how this runs end to end.
Three principles keep the loop trustworthy:
- It learns from reality, not itself. Every metric carries its origin — measured, derived, or model-produced — and only measured facts and confirmed outcomes become training labels, so a model's own predictions never silently become its own training data.
- It respects time. A representation used to predict an event never contains information from after that event, enforced structurally rather than left to analyst diligence.
- Every output traces back to its evidence. Because predictions are metrics, alerts are Monitors, and the data behind them is linked in the graph, every result arrives with the trail back to the assets, values, and records that produced it.
Where to start
Don't try to model everything at once. Start from the work that matters most:
- Pick the workflow with the most leverage. The highest-volume task, the biggest time-sink, or the single decision with the most leverage over revenue.
- Define a great outcome. Decide what success looks like for that workflow — faster, cheaper, or more accurate — so you can tell when you've reached it.
- Pull in only what that outcome requires. Connect just the data sources and integrations the workflow needs, not everything you have.
- Get the highest-value capability live as soon as possible. Ship that one workflow, prove the outcome, then expand from there.