Many projects ask for a "complete model," "LOD 400," or "all parameters" before answering the more consequential question: what decision is this information meant to support? Without a clear purpose, teams create more files and data, but not necessarily better project outcomes.
Information management begins before modelling. Organisational, project, asset and exchange needs must become requirements that teams can understand, assign and verify. An information requirements matrix provides that bridge.
More data is rarely the real answer
An information request becomes unreliable when it does not define the applicable asset population, delivery point, accountable party, format, acceptance criterion or expected evidence. By the exchange date, each participant may have formed a different interpretation.
"Provide panel information" cannot be tested consistently. A useful requirement identifies which panels are in scope, the properties needed, their intended use, the delivery owner, the review gate and the evidence required for acceptance.
Turning a need into a testable requirement
The ISO 19650 series sets out concepts and principles for managing information across an asset's life cycle. Part 2 addresses the delivery phase, while Part 4 provides process and decision criteria for information exchanges and information-model quality. As of September 2026, the 2018 editions of Parts 1 and 2 remain current, although ISO identifies both as being revised; each project should confirm the contractually applicable edition. SORA uses that logic as a practical reference: the workbook neither reproduces the standards nor certifies compliance.
Each matrix row connects eight elements:
- Requirement type: organisational (OIR), project (PIR), asset (AIR) or exchange (EIR).
- Purpose: the decision, use or outcome the information must enable.
- Object and scope: the asset, system, document or applicable population.
- Information need: the required delivery, distinguishing geometry, alphanumeric information and documentation.
- Ownership: who prepares it and who reviews it.
- Control point: this may relate to CDE states—such as WIP, Shared or Published—or to milestones such as Commissioning and Handover, always adapted to the project's process.
- Acceptance: the objective condition to be met.
- Validation and evidence: how compliance is checked and what record supports the decision.
Separating geometry, data and documents prevents "level of detail" from becoming a blanket demand. A sequence of operation may need no geometry but must define modes, alarms and interlocks. A coordination model needs geometry appropriate to its purpose, yet may not require every operational property. An asset register can demand precise alphanumeric information without increasing visual detail.
Where does IDS fit?
buildingSMART's Information Delivery Specification (IDS) expresses alphanumeric requirements in a computer-interpretable form and supports automated checking of IFC models. It is suited to properties, classifications, materials, quantities and relationships. IDS does not replace geometric review or test design rules on its own. The matrix therefore keeps the validation method explicit: IDS may be one method among document review, model federation, clash detection, field testing and cross-discipline audit.
Connected to the SORA ecosystem
The matrix is designed as an upstream control, not a standalone spreadsheet:
- Requirements define what information is needed.
- The RACI matrix determines who decides, performs, supports and receives information.
- MIDP/TIDP planning establishes when it is produced and exchanged.
- Naming rules preserve container identity and traceability.
- QA/QC confirms whether the result meets the requirement.
This reflects SORA's evolution beyond an isolated BIM practice: Engineering → Information → Coordination → Construction → Commissioning → Handover. Information becomes the thread that connects technical decisions, delivery and operations.
What the download contains
The current spreadsheet interface is in Spanish; an English interface has not been published yet. The Excel workbook includes:
- project and exchange configuration;
- editable catalogues;
- 20 starter requirements spanning information management, BIM, coordination, documentation, electrical, BMS/BAS, EPMS, commissioning and handover;
- mandatory-field controls;
- review and approval states;
- a dashboard with a five-outcome decision gate;
- usage guidance, references and limitations.
The gate avoids treating a populated spreadsheet as approved information. It distinguishes no configured scope, incomplete configuration, incomplete requirements, pending approval and ready for exchange.
How to begin
Start by defining the project, asset, appointing party or client and exchange. Then assess every starter row for applicability; remove, adapt or add requirements according to the contract, jurisdiction and execution plan. Document the reason whenever a requirement is not applicable. Assign real owners and write acceptance criteria that another person can test without having to infer the author's intent.
The workbook is a professional starting point, not a universal contractual requirement. Applicable standards editions, client requirements, legislation, manufacturer instructions and project conditions always take precedence.
A well-built requirements matrix does not remove a project's ambiguity, but it stops that ambiguity from travelling unchecked into the model, the data, or the final document.
Reference sources
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
