Skip to main content

Asset and Twin Context

Facility Operations needs a stable operational model before dashboards, inspections, work orders, energy review, and AI-assisted summaries can be trusted. This page explains how to prepare facility assets, spaces, systems, model assets, source aliases, and semantic relationships.

The asset and twin context layer should help an operator answer practical questions: where the asset is, which system it belongs to, what source data describes it, which work records affect it, and which nearby equipment or spaces may be impacted.

Context Flow

Prerequisites

RequirementWhy it matters
Facility ownerConfirms site, space, and system naming used by operations teams.
Asset source listProvides equipment IDs, source aliases, location, and owner fields.
Model sourceProvides 3D, BIM, CAD, or component references when visual context is needed.
Source-system mapShows how BMS, CMMS, meters, documents, and Inspector records name the same asset.
ReviewerApproves semantic relationships before they support energy, evidence, or AI workflows.

Core Model

LayerWhat to prepare
Site and spaceSite, building, floor, area, room, zone, and service boundary.
SystemsHVAC, chilled water, electrical, fire, water, elevator, IAQ, lighting, UPS, production utilities, or other site-specific systems.
EquipmentEquipment ID, name, class, owner, source aliases, location, status, and parent system.
Points and metersSensor, point, meter, setpoint, alarm, status, and unit references.
DocumentsManuals, SOPs, drawings, maintenance history, inspection records, and evidence files.
Model assets3D, BIM, CAD, component geometry, model versions, and twin-model bindings.

Step 1: Build the Facility Hierarchy

Start with the operating structure that users recognize.

  1. Create or confirm the site.
  2. Add buildings, floors, areas, rooms, or zones as needed.
  3. Group equipment under systems and service boundaries.
  4. Assign owner teams and responsible roles.
  5. Record source-system names and codes that users already use.

The hierarchy should support field work and operating review. It should be easy for a technician to find an asset by location, system, or equipment name.

Step 2: Normalize Equipment Identity

Each operational asset should have one stable identity inside FactVerse.

FieldReview note
Asset IDStable internal ID used by workflows and APIs.
Display nameHuman-readable name used by operators.
Source aliasesNames or codes from BMS, CMMS, EAM, meters, drawings, or spreadsheets.
Equipment classChiller, pump, AHU, meter, valve, panel, fan, elevator, UPS, sensor, or customer-specific class.
LocationBuilding, floor, room, zone, or area.
OwnerOperations team, maintenance team, contractor, or data owner.

Use DFS MDM and alias management when the same asset appears under different names across source systems.

Step 3: Bind Model Assets

Model assets connect geometry and operational identity.

BindingUse
Model assetRegisters a 3D, BIM, CAD, or imported model as a platform asset.
Model versionTracks changes when source geometry or metadata changes.
Component geometryLinks an equipment object or subcomponent to a model component.
Twin-model bindingConnects the operational twin object with the model asset and optional component.
Inspector bindingConnects alerts, work orders, or inspection tasks with the visual operating context.

Use model binding when the workflow needs spatial review, field navigation, equipment proximity, or visual evidence. Keep asset identity usable even when a model is unavailable.

Step 4: Add System Relationships

Facility Operations is stronger when systems, spaces, meters, and equipment relationships are explicit.

RelationshipExample
ServesAn AHU serves a floor or zone.
FeedsA panel feeds downstream equipment.
MeasuresA meter measures a building, floor, tenant area, or equipment group.
ContainsA room contains equipment, sensors, or stations.
Upstream or downstreamA pump affects a chilled water loop or connected load.
Evidence forA document, inspection, or record supports a work order or Green Mark evidence item.

Brick Schema or another asset ontology can help explain these relationships in a consistent way. Use it to make the facility graph readable for energy review, evidence preparation, and AI-assisted context retrieval.

Step 5: Validate with Operating Records

After model setup, test the context against real records.

  1. Open a known alert and confirm it resolves to the expected asset.
  2. Open a work order and confirm location, owner, and equipment are correct.
  3. Open an inspection task and confirm the checklist matches the asset or area.
  4. Search for a manual or SOP and confirm it links to the expected asset.
  5. Review a meter or BMS point and confirm it maps to the right space, system, or equipment.
  6. Check whether an AI Agent summary cites the same asset and source references.

Validation Checklist

  • Facility hierarchy matches the customer's operating language.
  • Equipment aliases are mapped across BMS, CMMS, EAM, meter, document, and drawing sources.
  • Model asset bindings point to the intended version and component.
  • Inspector alerts, inspections, and work orders resolve to stable asset records.
  • Semantic relationships are reviewed before being used for energy or evidence workflows.
  • Asset changes have an owner and audit trail.

Expected Output

At the end of this setup, the facility team should have a reviewed asset hierarchy, mapped source aliases, model asset bindings where needed, and enough semantic relationships to explain how spaces, systems, meters, equipment, documents, and work records connect.

Failure Handling

SymptomResponse
Asset cannot be matched across systemsAdd aliases, route conflicts to the steward queue, and delay downstream use until reviewed.
Model binding points to the wrong componentConfirm model version, component ID, and twin-model binding before field rollout.
Relationship graph is confusingReduce to the relationships needed by the active workflow and add reviewer notes.
Inspector record opens without contextCheck asset ID, target object ID, and binding route before using the record in operations.