FFO/Facility Plane

How FFO/Facility models the operator datacenter and DCIM twin — distinct from per-tenant FFO/Platform IT twins, fed by HyperSync DCIM adapters and Frontier Floor.

The Federal Frontier Ontology is one ontology family with many TypeDB instances. Operators run a dedicated FFO/Facility instance for the physical estate (datacenter / DCIM twin). Each tenant runs its own FFO/Platform instance for IT. Instances join only through boundary bridges — not one shared mega-graph.

Naming (locked)

Written Spoken Meaning
FFO/Facility Facility FFO Operator datacenter / DCIM twin
FFO/Platform Platform FFO Per-tenant Federal Frontier Platform IT twin
FFO/Platform:<tenant> Tenant X’s Platform FFO A specific tenant instance
FFO/Applications Applications FFO Enterprise application twin (e.g. Oracle EBS)

Prefer Platform over “Infrastructure” for the IT plane. Prefer Applications for ERP/app twins — do not fold them into Platform.

HyperSync naming (locked)

Term Role
HyperSync DCIM (a.k.a. DCIM HyperSync) Product capability / facade — vendor-neutral projection of a site’s DCIM SoR into FFO/Facility
OpenData HyperSync Job name for Modius OpenData adapter #1 only — not the product capability
DcimAdapter Per-vendor adapter behind HyperSync DCIM (OpenData today; Nlyte, Sunbird, … later)

Prefer: “HyperSync DCIM projects the site’s DCIM SoR into FFO/Facility.”
Avoid: implying OpenData is the only SoR, or that Facility entity types are Modius types.

Why a Facility plane?

Existing FFO docs (compute, Ceph, findings, identity) describe the Platform twin — clusters, nodes, workloads, and related IT entities. Federal and colo operators also need a first-class twin for site → room → rack → asset and DCIM-managed gear:

  • Agents and field apps need live facility context (placement, power, cooling adjacency, commissioning state).
  • The site’s DCIM System of Record (SoR) (Modius OpenData today; other DCIMs via adapters) remains authoritative for inventory already managed in DCIM.
  • FFO/Facility is the agent- and app-facing graph — not a second CMDB and not a replacement DCIM product.
  • Facility schema stays vendor-neutral — no Modius-/Nlyte-/Sunbird-specific entity types and no schema fork per DCIM.

Systems that feed Facility FFO

System Role
DCIM SoR (via adapter) Authoritative facility inventory / hierarchy for objects already in DCIM (OpenData, Nlyte, Sunbird, …)
HyperSync DCIM Capability / facade: select adapter per site, project & reconcile SoR → FFO/Facility
OpenData HyperSync Job for Modius adapter #1 (vendor_id: opendata) — bulk reconcile / drift correction
Frontier Floor iPad field commissioning client — create/place/annotate into FFO/Facility; may propose SoR updates
FFO/Platform instances Per-tenant IT twins — consume facility placement only via boundary bridges

See Facility Ownership & Data Flow for the ownership matrix and MVP phasing.

HyperSync DCIM facade

HyperSync DCIM projects any DCIM SoR into FFO/Facility. OpenData HyperSync is the Modius job name only.

flowchart TB subgraph Adapters["DCIM SoR adapters"] direction LR OD["Modius OpenData
adapter #1"] NL["Nlyte
future"] SB["Sunbird
future"] OTH["Other DCIM…
future"] end HS["HyperSync DCIM Scout
facade / projector"] FAC["FFO/Facility TypeDB
vendor-neutral twin"] Floor["Frontier Floor iPad"] Plat["FFO/Platform:<tenant>
placement only"] OD --> HS NL --> HS SB --> HS OTH -.-> HS HS -->|project / reconcile| FAC Floor -->|writes / annotates Facility
not SoR| FAC FAC -->|boundary bridges| Plat style HS fill:#2b6cb0,stroke:#4299e1,color:#fff style FAC fill:#2c7a7b,stroke:#38b2ac,color:#e2e8f0 style Floor fill:#553c9a,stroke:#805ad5,color:#e2e8f0 style OD fill:#2d3748,stroke:#4299e1,color:#e2e8f0 style NL fill:#1a202c,stroke:#718096,color:#e2e8f0 style SB fill:#1a202c,stroke:#718096,color:#e2e8f0 style OTH fill:#1a202c,stroke:#718096,color:#e2e8f0 style Plat fill:#2d3748,stroke:#4299e1,color:#e2e8f0

Caption: HyperSync DCIM projects any DCIM SoR into FFO/Facility; OpenData HyperSync is the Modius job name only.

Adapters normalize SoR inventory to Facility-shaped DTOs and upsert with external_id + source (+ source_updated_at, commissioning_status). Vendor JSON stays inside the adapter. Optional later path: SoR proposals / write-back through the same adapter.

What Facility FFO is not

  • Not Matter / Thread. DCIM and Floor talk SNMP, Modbus, BACnet, Redfish, and vendor APIs. Frontier Home / Matter HomeAccount is a separate product.
  • Not a second DCIM. Frontier Floor complements the DCIM SoR; it does not replace it.
  • Not the SoR for DCIM-managed inventory. HyperSync DCIM projects SoR truth into the twin; Floor fills gaps ahead of or beside the SoR until it catches up.
  • Not a place to write tenant IT graphs. Clusters, nodes, and workloads stay in FFO/Platform.
  • Not vendor-locked. Adapters speak vendor APIs; Facility types stay Facility-shaped.

Relationship to the Platform schema

The published Schema Reference documents the Platform-oriented modules (compute, storage, security, identity, …). Those types live in FFO/Platform instances. Facility keeps a separate TypeDB schema for the physical estate — do not fold Platform compute/security entities into the Facility graph.

Facility schema (TypeDB)

The FFO/Facility instance models datacenter containment and DCIM-facing assets:

  • Containment: site → room → row → rack → facility_asset
  • Ops: sensor_point, power_feed, cool_feed
  • Boundary: bridge_endpoint via boundary_bridge (opaque Platform links only)

Entity types: ffo_entity (abstract), site, room, row, rack, facility_asset, sensor_point, power_feed, cool_feed, bridge_endpoint.

Relation types: site_room, room_row, row_rack, rack_asset, asset_sensor, power_feeds, cool_feeds, boundary_bridge.

Identity & provenance (required on ffo_entity)

Attribute Role
external_id Primary SoR / cross-system key (@key)
source Adapter/source id: opendata, nlyte, sunbird, frontier_floor, manual, import, …
source_updated_at SoR (or adapter) observation time
commissioning_status projected | field_created | field_verified | pending_sor | linked
name Display name

opendata_id is a legacy alias for the Modius OpenData adapter only (may mirror external_id). New adapters must not require it. Optional source_system / source_id may carry free-form labels or raw vendor keys when distinct from external_id.

HyperSync DCIM upserts are keyed by external_id + source (adapter vendor_id). Vendor JSON stays inside the adapter; Facility never gains vendor-specific entity types.

TypeDB Studio schema visualizer for the FFO/Facility ffo_facility database

TypeDB Studio schema visualizer for the FFO/Facility instance (ffo_facility). Click to enlarge.