---
title: "An IFC Location Tree Cannot Tell You Which Equipment Ports Connect"
description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20."
canonical: "https://www.leviathansystems.co/articles/ifc-spatial-containment-versus-port-connections"
last-updated: "2026-10-20"
---

# An IFC Location Tree Cannot Tell You Which Equipment Ports Connect

Leviathan Systems — Technical content
Published 2026-10-20; updated 2026-10-20.

Buy the relationships needed for the recipient’s task. An IFC location tree can identify modeled equipment within a room, while port nesting identifies interfaces belonging to that equipment. Recovering the modeled peer of an interface requires the connection relationships as well. Equal room membership, port counts and connection counts can still describe different endpoint pairings.

## Define the question the recipient must answer

A coordinator may need to locate equipment in a room. A connection planner may need to follow one equipment interface to its intended peer. Both can receive an IFC exchange, but their tasks require different information.

A room tree can make the equipment population easy to browse. A convincing view can show the same equipment in the expected positions. Neither result answers which peer is associated with a selected port unless the necessary relationship is also present and usable.

Start a purchase discussion with a concrete recipient action: find interface S1 on equipment S, recover its modeled peer and identify the equipment that owns that peer. Then ask whether the proposed exchange carries the relationships needed for that result. This gives the provider a defined information task instead of an undirected request for a more detailed model.

The Revit/IFC deliverable guide addresses authoring versus exchange and recipient use. The additional question here is which relationships the recipient must be able to follow inside the delivered information.

## Read spatial containment as a modeled location relationship

buildingSMART’s IfcRelContainedInSpatialStructure definition assigns elements to a spatial level. It distinguishes one primary containment from potentially several spatial references. The project context determines the appropriate level; a room or storey is not a universal assignment for every element.

The definition also distinguishes element containment from the spatial hierarchy itself, which uses IfcRelAggregates. Treating every parent-child item in a viewer as the same relationship would lose that distinction.

For the recipient’s location task, primary containment helps answer where the issued information places an equipment object in its spatial structure. That says what the model asserts. Establishing the equipment’s actual installed location requires the appropriate physical evidence.

This article follows the official buildingSMART development-document definitions at immutable commit ecca26ca450e8f164eac1e6e876ce840410e407a, checked October 20, 2026. That is a pinned documentation source, not a declaration of the latest released IFC schema or a receiving application’s behavior. Identify the schema of an actual exchange separately.

References: [IFR1](https://raw.githubusercontent.com/buildingSMART/IFC4.x-development/ecca26ca450e8f164eac1e6e876ce840410e407a/docs/schemas/core/IfcProductExtension/Entities/IfcRelContainedInSpatialStructure.md)

## Follow port ownership and connection separately

IfcRelNests supplies an ordered whole/part relationship. Its definition includes ports nested under their distribution element. That relationship can identify which modeled equipment owns an interface and preserve the order of its listed ports. It does not choose another equipment object as the interface’s peer.

IfcRelConnectsPorts explicitly relates two port instances at their connection. Its attributes can also identify connection geometry or a realizing element. The two port references must differ. This is the relationship needed to follow a modeled port pairing rather than infer one from a location tree.

buildingSMART’s distribution-port definition gives interfaces their own system and flow meaning and permits placement information. A visible enclosing shape, a port position and a supplied semantic connection remain different information. The port may be positioned near another object without the exchange supplying the requested connection edge.

Compatibility conditions also travel with the applicable model semantics. This explanation supplies no rule for assigning real data-network directions, selecting a connector or treating visual contact as a suitable physical connection.

References: [IFR2](https://raw.githubusercontent.com/buildingSMART/IFC4.x-development/ecca26ca450e8f164eac1e6e876ce840410e407a/docs/schemas/core/IfcProductExtension/Entities/IfcRelConnectsPorts.md), [IFR3](https://raw.githubusercontent.com/buildingSMART/IFC4.x-development/ecca26ca450e8f164eac1e6e876ce840410e407a/docs/schemas/core/IfcKernel/Entities/IfcRelNests.md), [IFR4](https://raw.githubusercontent.com/buildingSMART/IFC4.x-development/ecca26ca450e8f164eac1e6e876ce840410e407a/docs/schemas/shared/IfcSharedBldgServiceElements/Entities/IfcDistributionPort.md)

## IFC-R01: one room, three equipment objects and six ports

IFC-R01 is an original fictional relationship example. Equipment objects S, P and Q share a stipulated primary containment in ROOM-A. S owns ports S1 and S2; P owns P1 and P2; Q owns Q1 and Q2. The selected port-ownership relationships use the nesting mechanism described above.

The example stipulates compatible modeled interface, system and flow conditions for both connection returns considered next. It supplies no actual equipment model, IFC payload, schema-conformity result or product compatibility. These premises let the comparison focus on endpoint relationships.

First suppose the delivered information contains only the room membership and port ownership. The recipient can find the three equipment objects in ROOM-A and associate each of the six ports with its owner. The recipient still cannot recover S1’s peer from those relationships alone.

That missing result does not establish that S1 is physically disconnected. It establishes that the selected exchange has not supplied the requested peer relationship. Guessing from a nearby shape or similarly named port would add a decision absent from the input.

## Two connection returns preserve the same location tree

Now add explicit connection information. Return A pairs S1 with P1, S2 with Q1, and P2 with Q2. Return B pairs S1 with Q1, S2 with P1, and P2 with Q2. The room membership and port ownership stay unchanged.

Each return contains three equipment objects, six selected ports and three connection pairs. Every port appears in exactly one pair. Two pairs have been replaced between the returns; the P2–Q2 pair is retained. Equal counts therefore cannot establish equal endpoint relationships.

Follow the buyer’s original question. In A, S1 reaches P1, whose modeled owner is P. In B, S1 reaches Q1, whose owner is Q. S1 has not changed identity or room membership. The different answer comes from the supplied connection relationship.

The compact table compares the pairings only. It is a conceptual extract for reasoning, rather than a complete IFC file, software result or drawing of an authorized physical network.

IFC-R01: unchanged populations, different endpoint pairings
| Return | Three explicit port pairs | Result when following S1 | Source |
| --- | --- | --- | --- |
| A | S1–P1; S2–Q1; P2–Q2 | P1, owned by equipment P | Planning analysis |
| B | S1–Q1; S2–P1; P2–Q2 | Q1, owned by equipment Q | Planning analysis |
All objects, relationships and compatibility premises are fictional. No physical connection or software exchange was tested.

## Compare the exchange output against that recipient action

A location-only exchange may be sufficient for a stated spatial-reference task. It leaves IFC-R01’s peer question unanswered. Paying for more geometric detail would not necessarily add the missing semantic relationships.

For an exchange intended to answer the connection question, ask the provider to demonstrate the recipient action on a representative population. The return should let the recipient find S1, follow its supplied connection and recover the peer’s modeled owner. It should identify the model issue, schema, relevant source issue and receiving environment used for the demonstration.

Compare the outcome with the intended return. A report repeating three equipment objects, six ports and three connections could be correct for either A or B. A useful result distinguishes their endpoint pairs and exposes a missing or unresolved peer instead of silently substituting one.

Keep the required population visible. Recovering one easy pair does not establish that every intended interface arrived, while an intentionally omitted relationship needs a clear scope explanation. Representative evidence establishes the behavior actually demonstrated; it does not certify every recipient product or the full untested population.

The provider may bundle model preparation, relationship reconciliation and recipient review commercially. Describe the included result for each task so an exchange containing location information is not priced as though it also returned a complete connection dataset.

## Retain what the model connection actually establishes

A retrieved edge answers what the supplied information says connects. It does not establish that the network designer approved that pair or that the corresponding physical connection exists and works. The relevant design source and installed evidence remain necessary for those claims.

Likewise, the pair supplies no cable length, optical loss, permitted pathway, connector arrangement or service clearance by itself. A realizing element or visible route needs its own identified information; its presence cannot fill missing equipment and site requirements.

Use the IFC/IDS guide for standard conformity and specified information checks. Use the effective-property guide when the recipient must resolve type and occurrence values. The COBie guide follows maintainable-asset, type and space references, while the operational digital-twin guide follows observation and time relationships. Those owners address different questions from IFC-R01’s endpoint graph.

This separation lets a bounded exchange be useful without overstating it. The buyer can accept an attributable relationship return for the agreed information task while the appointed design, equipment and facility owners retain their separate decisions.

## Bring a defined information task to physical planning

For a physical planning discussion, describe the recipient’s action and the available source information. Identify whether the requested package needs equipment locations, interface ownership, connection records or a defined combination. An authorized representative input can help establish the intended output without sharing restricted site assets through a public form.

Leviathan’s Physical Infrastructure Planning & CAD service is the route to discuss agreed layouts, cable pathways, point-to-point schedules, labels and physical documentation. The engagement confirms authoring resources, tools, supported formats and review responsibilities before committing a particular output.

Specialist IFC extraction, export, checking or a receiving-application demonstration must have its actual appointed owner. The definitions and fictional case here establish no Leviathan software capability. Use the related service and project inquiry to discuss the concrete physical-documentation task and the input decisions it depends on.

## Primary sources

- [IFR1 — buildingSMART: IfcRelContainedInSpatialStructure](https://raw.githubusercontent.com/buildingSMART/IFC4.x-development/ecca26ca450e8f164eac1e6e876ce840410e407a/docs/schemas/core/IfcProductExtension/Entities/IfcRelContainedInSpatialStructure.md). Checked 2026-10-20. Official development-document commit ecca26ca450e8f164eac1e6e876ce840410e407a; primary containment, spatial references and spatial-hierarchy distinction. Not a latest-release claim.
- [IFR2 — buildingSMART: IfcRelConnectsPorts](https://raw.githubusercontent.com/buildingSMART/IFC4.x-development/ecca26ca450e8f164eac1e6e876ce840410e407a/docs/schemas/core/IfcProductExtension/Entities/IfcRelConnectsPorts.md). Checked 2026-10-20. Same immutable development commit; explicit port relationship and attributes. No actual connection or product behavior tested.
- [IFR3 — buildingSMART: IfcRelNests](https://raw.githubusercontent.com/buildingSMART/IFC4.x-development/ecca26ca450e8f164eac1e6e876ce840410e407a/docs/schemas/core/IfcKernel/Entities/IfcRelNests.md). Checked 2026-10-20. Same immutable development commit; ordered whole/part relationship, including nested ports. No authoring procedure adopted.
- [IFR4 — buildingSMART: IfcDistributionPort](https://raw.githubusercontent.com/buildingSMART/IFC4.x-development/ecca26ca450e8f164eac1e6e876ce840410e407a/docs/schemas/shared/IfcSharedBldgServiceElements/Entities/IfcDistributionPort.md). Checked 2026-10-20. Same immutable development commit; interface meaning, nesting, placement and connectivity prose. No diagram or physical alignment method interpreted.

## Related Leviathan resources

- [Define the Revit or IFC exchange the recipient needs](/articles/gpu-cabling-revit-ifc-deliverable-brief)
- [IFC conformity and IDS information requirements](/articles/gpu-cabling-ifc-validation-vs-information-requirements)
- [Resolve IFC type properties and occurrence overrides](/articles/ifc-type-occurrence-property-value-resolution)
- [COBie asset, type and space relationships](/articles/cobie-type-component-space-operational-handoff)
- [Operational digital twins: identity, observations and time](/articles/operational-digital-twin-identity-time-relationships)
- [Physical Infrastructure Planning & CAD](/services/engineering-design)
- [Discuss a physical-documentation task](/contact?service=engineering-design&from=%2Farticles%2Fifc-spatial-containment-versus-port-connections)

## Define the physical-documentation result you need

Share the recipient’s task, authorized source information and requested layouts, schedules or connection records to discuss an engagement-defined planning scope.

[Discuss the scope](/contact?service=engineering-design&from=/articles/ifc-spatial-containment-versus-port-connections)