---
title: "Overview"
description: "How the platform builds, maintains, and surfaces your organization's knowledge."
icon: "sparkles"
---
> **For AI agents:** the complete documentation index is at [llms.txt](/llms.txt). Append `.md` to any page URL for its markdown version.
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](/agentic/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](/platform/data-model#thing-type-definition),
[Metric Definitions](/platform/data-model#metric-definition), and
[Templates](/platform/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](/platform/data-model#metric-definition) over a time
window.
- **Identity and location** — its [Thing Type Definition](/platform/data-model#thing-type-definition),
its properties, and its [Place](/console/sites) 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](/platform/data-model#metric-definition) — a first-class part of the same
model everything else speaks. [Monitors](/console/monitors) watch that metric and fire through
egress [Integrations](/console/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](/agentic/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.
Need help onboarding workflows? Reach out to our solutions group for tailored support: support@aerovy.com
## Components
Generate and maintain the primitives that model your domain.
Compose primitives into executable, self-improving company tasks.