Systems do not fail only because of errors inside a single discipline. They also fail at the boundaries: when no one defines who supplies the power, what signal must travel, what space must be reserved, what protocol will be used, or who proves the integration actually works. The SORA MEP Technical Interfaces Matrix turns those boundaries into requirements that are visible, owned, and verifiable.
An interface is a dependency, not an interference
A geometric clash is only one class of interface. A technical interface exists whenever two systems, teams, organizations, or deliverables depend on one another to function, be installed, be tested, or be handed over correctly. It can be physical, electrical, digital, functional, documentary, or contractual.
A panel that feeds a controller, a BMS that receives status points from an ATS, a network that carries EPMS data, a structure that supports a piece of equipment, or an operations team that receives handover backups — all of these are interfaces, even when no clash exists in the model.
Why interfaces get lost
In fragmented projects, each discipline validates its own scope internally, but no one governs the space between scopes. Drawings can be correct in isolation while the integrated system remains incomplete. Generic phrases such as "coordinate with vendor" or "by others" do not define tension, protocol, tolerance, sequence, date, evidence, or authority.
The matrix forces each interface to name System A, System B, the direction of the dependency, the requirement, the reference, the responsible parties on both sides, the interface owner, the reviewer, the required date, the verification method, and the evidence.
The lifecycle of a controlled interface
First the dependency is identified. Then a verifiable condition is defined and responsible parties are assigned. The parties document the solution or agreement, prepare evidence, and carry out the review or test. An interface can only be considered accepted with a conforming result, or with an authorized and justified deviation.
Identified, in definition, and in coordination describe work that is still open. Ready to verify separates the stated solution from its confirmation. Verified indicates evidence exists; accepted adds the decision of the corresponding authority.
Interface types worth registering
Initial categories include space and physical condition, electrical supply, control and signal, network and protocol, data and metering, functional sequence, responsibility, installation and support, testing and commissioning, and documentation and handover information.
This taxonomy allows the same matrix to be used from engineering through operation without turning it into a BIM-only tool. Each project should adjust terms and criticality thresholds to its own contract, risks, and systems.
Relationship with ISO 19650 and IFC
ISO 19650-2 establishes an information management process during the delivery phase. ISO 19650-4 details criteria and decisions to secure the quality of exchanges and calls for an application proportional to scale and complexity. The matrix translates those principles into a practical control of dependencies, responsibilities, and evidence; it does not reproduce the standards or certify conformance.
ISO 16739-1 defines IFC as an open standard for shared information between applications and participants throughout the life cycle. IFC helps represent objects, properties, and relationships in an interoperable way, but it does not replace specific agreements on protocols, tolerances, supply, sequencing, or acceptance. The matrix complements digital exchange with human and technical governance.
What the tool contains
The Excel file includes configuration, a dashboard, one hundred available rows, eighteen cross-disciplinary examples, catalogs, a guide, and sources. It flags duplicate identifiers, inconsistent dates, pending responsibilities, partial verification, non-conforming acceptance, escalation without a reference, and deviations without justification or without a linked authorization.
The examples cover BMS electrical supply, HVAC signals, HVAC and electrical routing, EPMS metering, BMS networking, electrical room access, generators, ATS, fire protection, supports, functional testing, point-to-point testing, assets, backups, and as-built information.
How the matrix relates to issues, changes, and decisions
The matrix identifies a dependency before it becomes a problem: which party supplies the condition, how the signal or data is delivered, under what protocol, who verifies the result, and who accepts it. When that condition is not met by the required date, or verification comes back non-conforming, the interface can originate a formal issue in the SORA Technical Issue Register, which documents the matter from detection through closure.
If resolving an interface requires modifying an already-approved baseline — a drawing, a model, a requirement, or a previously accepted agreement — that modification should not be treated as an informal adjustment. It must be linked to a change record, or to the decision that authorized it, so there is a record of what was approved, who authorized it, and within what scope.
When information needed to close an interface is missing — a pending specification, a confirmation from another discipline, a data point neither party can yet supply — that gap can give rise to a request for information (RFI) addressed to whoever must resolve it.
Relating the matrix to issues, changes, and decisions is, today, an information-management practice sustained by the team's discipline — naming each link, recording each cross-reference, checking consistency across documents — and not an automated integration between platforms. No SORA tool today synchronizes these records with one another; traceability depends on each responsible party recording the link when it applies.
Download and rollout
Download the SORA MEP Technical Interfaces Matrix, configure the authorities, and run a pilot session with the leads for electrical, mechanical, BMS, EPMS, IT, architecture, structure, commissioning, and operations. Start with the critical interfaces and the ones that condition procurement, construction, or testing.
References
Note: the template must be adapted to the contract, BEP, ICD, QA/QC procedure, commissioning requirements, and jurisdiction.
Related free tool
Put this methodology into practice
SORA · Matriz de Interfaces Técnicas MEP
Download the free SORA tool associated with this article and adapt it to your project needs. The current workbook interface is in Spanish.
SORA_Matriz_Interfaces_Tecnicas_MEP_v1.0.xlsx · v1.0 · .xlsx
Does your organization need a tool adapted to its processes?
Tell us about the context, roles, deliverables and controls you need. SORA can help structure a tailored technical solution and define the right scope.
Discuss a tailored tool →Tags
