Valanor Ontology
A shared model of a physical site, the things within it, and the work happening around them.
On this page
What is an ontology?
A camera sees activity. An access system records an entry. A maintenance system tracks an inspection. Each system describes part of the same site, but those records often have different names, identifiers, and histories.
Valanor Ontology is being designed to connect those records into a model that applications can understand and use. It describes what exists, where it is, how things relate, what has been observed, and which actions are permitted. It is an operational model, not just a drawing of a site or a collection of device feeds.
In this documentation, a fictional site called North Yard has an East Entrance, Gate B, Camera 12, and a patrol robot named Agent 104. The same example appears throughout. It does not describe a customer deployment.
Why a shared operational model?
Without shared identity, an application may treat the gate in an equipment register and the gate in an incident report as unrelated things. Without time and source information, it may confuse an old observation with the current condition.
The intended ontology keeps those distinctions explicit. An operator could open Gate B and find its location, the camera that observes it, the incident under review, and the outstanding inspection. Each claim can retain its source and time instead of losing that context when records are combined.
This also separates applications from hardware details. Replacing a camera should primarily change its integration and source mapping. An application can continue asking about Gate B, provided the replacement offers the required capability and meets the operating constraints.
Three parts of the product
| Component | Purpose | Status |
|---|---|---|
| Ontology Studio | Define types, configure source mappings, explore objects and history, and review action records. | Design |
| Ontology Runtime | Maintain definitions, identities, relationships, state, observations, events, permissions, and action execution records. | Design |
| Ontology API and SDK | Give applications a shared boundary for queries, permitted updates, and action requests. SDK means software development kit. | Design; public SDK release planned |
The Integration Fabric connects this product to external systems. It manages adapters, source mappings, identity reconciliation, capabilities, and connection health. Connectors may run in the cloud or in a customer environment using optional Edge software.
The ontology and the Valanor application
Valanor is the intelligence layer for physical sites. Valanor Ontology is being designed as a standalone product within that direction. Mithril is the name used for the core ontology engine and developer platform in the software overview.
The existing Valanor application is the first intended consumer of the standalone boundary. Its maps, investigations, and operational views are applications of the model; they are not the model itself. Other applications should be able to use the same service boundary, subject to their permissions.
That separation is an architectural direction. It does not mean the existing application has already been migrated to a released standalone ontology service.
What exists, and what is being designed?
Status is scoped to each capability. Available means implementation was verified in the reviewed application code. It is not a guarantee of public access, production deployment, or availability in a particular customer environment.
| Scope | Status | What this means |
|---|---|---|
| Site, device, and incident records in the existing Valanor application | Available | Record models and application reads were verified in source code. These are existing application features, not a public standalone ontology API. |
| Standalone Studio, Runtime, and Integration Fabric boundaries | Design | Accepted architecture. A complete independent product implementation has not been verified. |
| Common ontology query, update, and action interfaces | Design | The intended developer contract is explained here. Interface names and transport are not a released specification. |
| Public SDK distribution and general prediction interfaces | Planned | No released package, installation procedure, or general predictive service is documented as available. |
These pages describe the public product concepts and integration boundaries of architecture v0.1, reviewed on September 28, 2026. Proprietary algorithms, model configuration, internal schemas, and deployment details are outside their scope. They are not a compatibility catalog or a production API reference. Integration support must be assessed for a specific system, version, deployment, and use case.
Where to go next
- Core concepts
Learn the model through Gate B, then how access to records, evidence, and actions is scoped.
- Architecture
See the data flow, the application boundary, and how existing systems connect.
- Developer guide
Understand how an application would query, subscribe, and request actions, with conceptual examples.
- Workflows
Plan a first workflow, then put the concepts together in investigations, inspections, and handovers.