PLATFORM

Ontology Framework

The ontology is the structural spine of the Bruviti AIP. It defines the entity types and relationship types that organize all platform knowledge, drives disambiguation during retrieval, scopes search to relevant context, aligns embedding models to equipment-domain semantics, and enables graph-based reasoning for forecasting sparse data.

What the Ontology Is

The ontology is a formal definition of the equipment service domain — a typed graph schema that specifies what kinds of things exist (entity types) and how they relate to each other (relationship types). Every piece of data ingested into the platform is tagged against this schema, and every retrieval, compilation, and reasoning operation uses the ontology to scope and structure its work.

Unlike a flat taxonomy or keyword-based tagging system, the ontology encodes structural relationships. It knows that a pump seal is a component of a pump subsystem, which is part of a vacuum system asset. It knows that a specific procedure requires specific parts and mitigates specific symptoms. This structural understanding is what enables the platform to resolve ambiguity, scope retrieval, and reason across entities — capabilities that flat document search cannot provide.

Ontology entity types and relationship structure with seven node types
Figure 1: Ontology entity types and relationship structure

Entity Types

The ontology defines seven core entity types that cover the equipment service domain. Every piece of ingested data is tagged as one or more of these types during the data ingestion pipeline.

Entity Type Definition Examples
Asset Top-level equipment unit — a complete machine or system that is deployed, serviced, and tracked as a single entity Vacuum pump system, CNC machining center, data center cooling unit, EV charging station
Subsystem A functional grouping within an asset — a major module or assembly that performs a distinct function Hydraulic subsystem, control electronics, power supply module, exhaust system
Component An individual part or assembly within a subsystem that can fail, be replaced, or require maintenance independently Pump seal, bearing assembly, circuit board, motor, filter element
Part A replaceable item with a part number — the unit of inventory, procurement, and field service logistics Seal kit P/N 4528-A, bearing P/N 7720-C, gasket set, O-ring
Procedure A defined sequence of steps for maintenance, repair, inspection, or diagnostic activity Seal replacement procedure, annual PM checklist, calibration routine, diagnostic workflow
Symptom An observable indicator of a problem — reported by a user, detected by a sensor, or identified through diagnostics Excessive vibration, error code P0420, unusual noise at startup, temperature drift
Parameter A measurable operating characteristic of an asset or component — used for monitoring, diagnostics, and condition assessment Operating temperature, pressure differential, vibration frequency, power consumption, cycle count

These types are hierarchical where appropriate (Asset → Subsystem → Component → Part) but also cross-linked through non-hierarchical relationships. A symptom can reference components across multiple subsystems. A procedure can require parts from different suppliers. A parameter can be monitored across an entire asset class.

Relationship Types

Relationships are the edges that connect entities in the knowledge graph. Each relationship type has defined semantics that the platform uses for scoping, traversal, and reasoning.

Relationship Semantics Example
part-of Structural containment — entity A is a physical or logical component of entity B Seal assembly part-of vacuum pump subsystem
requires Dependency — executing a procedure or replacing a component requires specific parts, tools, or conditions Seal replacement procedure requires seal kit P/N 4528-A
mitigated-by Resolution — a symptom or fault condition is resolved by a specific procedure or action Excessive vibration mitigated-by bearing replacement procedure
compatible-with Interchangeability — a part can be used in place of another part in specific contexts Seal kit P/N 4528-A compatible-with seal kit P/N 4528-B (same fit, different material)
supersedes Replacement lineage — a newer part replaces an older one, with forward and backward traceability Seal kit P/N 4528-C supersedes P/N 4528-A (engineering revision)
references Association — a parameter, document, or data point is associated with an entity without a structural dependency Operating temperature parameter references compressor component

Relationships are directional and typed, which means graph traversal is deterministic. When the platform follows a part-of edge upward from a component, it reaches the parent subsystem and then the parent asset. When it follows mitigated-by from a symptom, it reaches the resolution procedure. This structure enables the scoped retrieval described in the next section.

Ontology-Driven Retrieval

The ontology serves three functions during retrieval: disambiguation, scope control, and graph-based reasoning. These functions are used throughout the agentic retrieval workflow.

Disambiguation

When a query references "the pump," the ontology resolves which pump is meant. Using the service context (customer, site, equipment hierarchy), the system traverses the part-of relationships to identify the specific asset, subsystem, and component being referenced. Without ontology-driven disambiguation, a query about a pump seal in a vacuum system would also return results about hydraulic pumps, coolant pumps, and fuel pumps across the entire knowledge base.

Disambiguation is particularly important for enterprises with large installed bases where the same component name appears across hundreds of equipment models. The ontology's structural hierarchy ensures that "pump seal" in the context of a semiconductor vacuum system resolves to a different entity than "pump seal" in the context of a building HVAC system.

Scope Control

Once an entity is disambiguated, the ontology controls how far retrieval extends. Scope is determined by traversing relationships outward from the target entity:

  • Narrow scope — only the target entity (e.g., just the seal kit entity card)
  • Component scope — the target entity plus its parent component and sibling parts (e.g., the seal kit plus the seal assembly and all associated parts)
  • Subsystem scope — everything within the parent subsystem (e.g., all components, parts, procedures, and symptoms for the vacuum pump subsystem)
  • Asset scope — the full equipment context (e.g., the entire vacuum system including all subsystems, service history, and operating parameters)

The retrieval system selects the appropriate scope based on the query type. A parts lookup uses narrow scope. A diagnostic workflow uses subsystem scope. A pre-visit briefing uses asset scope.

Graph-Based Reasoning

Beyond scoping individual queries, the ontology enables reasoning across the knowledge graph. The platform can follow relationship chains to answer questions that no single document contains:

  • Which symptoms have been reported for this component's sibling components? (Traverse part-of to parent, then down to siblings, then follow mitigated-by backward to symptoms)
  • What other procedures require the same part? (Follow requires backward from the part to all procedures)
  • Which compatible parts exist if the specified part is out of stock? (Follow compatible-with and supersedes from the part to alternatives)

This traversal-based reasoning is what powers the context product compilation — the system can assemble comprehensive entity cards and service packs by walking the graph rather than searching documents.

Ontology-Aligned Embeddings

Standard text embedding models encode content based on surface-level linguistic similarity. The platform's embedding models are trained on the ontology structure so that semantically related equipment concepts are close in vector space — even when they use entirely different terminology.

Standard vs ontology-aligned embedding spaces comparison
Figure 2: Standard vs. ontology-aligned embedding spaces

The training process uses the ontology graph as a supervision signal. Entity pairs connected by short graph paths (e.g., components in the same subsystem, parts connected by compatible-with) are trained as positive pairs — their embeddings are pulled closer. Entity pairs that are ontologically distant (e.g., components in unrelated subsystems) are trained as negative pairs — their embeddings are pushed apart.

The result: retrieval queries automatically capture ontological relationships without requiring explicit query expansion. A search for a component implicitly retrieves content about that component's parent subsystem, sibling components, compatible parts, and associated procedures — because all of these are nearby in the aligned embedding space.

Why alignment matters for retrieval: In equipment service, the same concept is described differently across data sources. A manufacturer's manual refers to "rotary shaft seal assembly," the parts catalog lists "seal kit, centrifugal," and a technician's service note says "replaced the pump seal." Standard embeddings treat these as loosely related. Ontology-aligned embeddings treat them as near-identical because the ontology connects them to the same component node.

Ontology in Forecasting

The ontology's most distinctive application is enabling forecasting for entities with sparse or zero transaction history — the "long tail" problem that affects the majority of parts in any equipment service operation. This application is covered in depth in the Predictive Forecasting documentation; this section describes the ontology's specific role.

The Peer Selection Problem

Traditional forecasting treats each part as an independent data series. If a part has three replacement records over two years, statistical models produce unreliable predictions. If a part has zero history (new to the catalog, recently superseded, or newly deployed), traditional forecasting produces nothing at all.

The ontology reframes this problem: a part with sparse data is not isolated — it exists in a graph of relationships. Parts that share functional roles, operating contexts, and equipment families are ontological peers whose histories can be pooled to produce statistically grounded predictions.

Peer Discovery Through Graph Traversal

The ontology identifies peer parts through multiple relationship paths:

  • Same-subsystem peers — other consumable parts in the same subsystem (traverse part-of to parent subsystem, then down to sibling components and their parts). Example: other vacuum pump consumables like O-rings, gaskets, and lubricant cartridges.
  • Same-function peers — parts with the same functional role in different equipment types (traverse to components tagged with the same ontology function). Example: seal kits in centrifugal pumps, diaphragm pumps, and rotary vane pumps.
  • Same-environment peers — parts operating in similar conditions regardless of equipment type (traverse through parameter relationships to find parts sharing operating condition tags). Example: corrosion-resistant seals across all equipment operating in high-humidity, chemical-exposure environments.
Ontology-based peer selection for a sparse-history part
Figure 3: Ontology-based peer selection for a sparse-history part

Similarity Scoring

Each identified peer is assigned a similarity weight between 0.0 and 1.0 based on three factors:

  • Ontological distance — how many graph edges separate the target part from the peer (shorter path = higher weight)
  • Operational overlap — how similar the operating conditions are (temperature range, duty cycle, chemical exposure)
  • Failure mode similarity — whether the peer fails through the same mechanism (wear, corrosion, fatigue, thermal degradation)

These weights are used in the statistical modeling phase to produce weighted pooled estimates — closer ontological peers contribute more to the forecast than distant peers.

From rows to relationships: The ontology enables a fundamental paradigm shift in forecasting. Traditional approaches require sufficient transaction data per part (rows). The ontology approach substitutes structural knowledge (relationships) for missing transaction data — even a part with zero history can be forecasted if the ontology identifies strong peers with data.