Free owner + information-management tool
Turn business decisions into project information requirements.
Build one traceable chain from an organisational need to a project decision and a team exchange. Name what is needed, when, for whom and how it will be accepted—before asking a delivery team for a BEP.
Three levels, three jobs
Requirements first. Execution response second.
OIR records a business decision or obligation. PIR translates it into a project outcome and milestone. The appointment or exchange requirement tells a particular team what to provide, when, for whom and against which checks.
AIR stays separate because it defines detailed operational asset information. A BEP stays separate because it explains how the delivery team proposes to respond.
Check the current source
Use the latest project and national guidance.
The published ISO 19650 series and national guidance can change. This builder uses plain-language planning logic and does not reproduce the standards.
ISO 19650-1:2018 on ISO.org ↗
ISO/DIS 19650-1 edition 2 status ↗
ISO 19650-4:2022 on information exchange ↗
Questions people ask
Keep the requirement useful and proportionate.
01What is the difference between OIR, PIR, AIR and an exchange requirement?+
OIR records an organisational decision or obligation. PIR turns that need into a project decision and milestone. AIR defines detailed operational asset information. An appointment or exchange requirement states what a particular team must provide, when, for whom and how it will be accepted.
02Is an exchange requirement the same as a BIM Execution Plan?+
No. The requirement states what the appointing side needs. A BIM Execution Plan explains how a delivery team proposes to produce, manage and check the information.
03Does this builder make a project ISO 19650 compliant?+
No. It creates an original working brief. The project team must adapt it to the current standard edition, national guidance, contracts, appointments, security needs and professional responsibilities.
04Is an LOD label enough to specify an information exchange?+
Usually not. A useful requirement also names the purpose, recipient, scope, data and document needs, submission date, review period, sources, responsibilities and acceptance tests.
05Why are submission and useful-by dates separate?+
The team needs time to review, comment, correct and accept information before it supports a project decision. Using the same date for both often removes that review window.
06What if our operational asset requirements are not defined?+
Use the separate Asset Information Requirements starter to define operational uses, asset scope, data fields, receiving systems and upkeep. Reference that AIR in this requirements chain.
We review each tool against the decision it helps someone make, the clarity of its assumptions and how people use the result. Tell our team what would make this tool more useful.
Start with the deliverable
Want to review one real exchange before tender or mobilisation?
Send the generated chain with one representative package. Our team can help tighten the scope, dates, responsibilities and acceptance checks.