Writing exchange information requirements that actually get answered

The information manager who wrote last year's EIR can usually tell you, if you ask, that nobody answered it. Appointed parties sent BIM execution plans that promised compliance. Mid-term reviews never opened the appendix. Come handover, the asset data still had to be rebuilt. None of that is mysterious once you look at what was issued. An exchange information requirement is a question the appointing party asks of an appointed party at a named moment, and last year's appendix never asked a question a task team could put a number on.

If the question does not name a container, a state, a field, and a test that can fail, the supply chain will not answer it. They will price a slogan, copy the slogan into the BEP, and carry on. Most EIRs die that way — not because the industry is careless, but because the document never asked for anything that could be priced.

January is when the next year's appointments get written. Put a row per exchange in the pack this time, not last year's appendix.

How to use the sheets

Print them. One row per exchange, not one manifesto for the job. Fill four blocks — container, state, fields, acceptance — until a subcontractor who has never sat in your kick-off can say what they will deliver, when, in which state, and how you will reject it. If a row still needs a meeting to interpret, it is not ready to issue.

ISO 19650, the UK BIM Framework, and the contract forms each have owners. They assume you can say what must be exchanged. They do not write the rows for you.

The slogan is not a requirement

A slogan EIR is a paragraph that sounds like the standard and cannot be priced. You already know the sentences.

"The project shall comply with ISO 19650." That is a claim about a process. It does not name a file.

"BIM Level 2 is required." That phrase was a UK policy object. It names neither an information container nor a level of information need.

"All models shall be LOD 300." Level of development is a geometry slogan. ISO 19650 talks about level of information need: purpose, objects, and the information those objects must carry. LOD 300 does not tell a services contractor whether a terminal needs a fire rating, a flow rate, or a system name.

"A common data environment shall be provided." Provided by whom, holding which states, with which suitability codes, and what happens when a work-in-progress model is treated as published? The sentence buys a login.

"COBie shall be delivered at handover." One spreadsheet, once, at the end, against a schema nobody validated at Stage 3, is how handover becomes a reconstruction project. If you mean structured asset data, say which types, which fields, which units, and which exchange before practical completion will prove the fields exist.

"The supply chain shall collaborate using open BIM." Collaborate cannot be delivered, and open is not a format. IFC 4.3 with a named model view, or it is a poster.

These sentences survive because they are cheap to write and expensive to challenge in a tender meeting. The appointed party cannot ask "which container?" without looking difficult. So they write "we will comply" in the pre-appointment BEP, and the EIR has been answered with another slogan.

Ask for containers, states, dates and tests a supply chain can price. An EIR that cannot be answered will be ignored.

What gets answered

ISO 19650 distinguishes three neighbouring documents. Project information requirements say what the appointing party needs in order to decide. Exchange information requirements say what appointed parties must produce, at which exchanges, so those decisions have something to stand on. Asset information requirements say what operations will query after handover. A slogan EIR tries to be all three in one paragraph, and so is none of them.

Four things make an EIR answerable. If any one is missing, you still have a slogan with metadata.

Containers. Name the information container, not the discipline. A container is a managed file or dataset: one coordinated architectural model for a volume, one drawing series, one asset-data table, one clash report, one health and safety file extract. Give it a type, a naming pattern that will survive site, a format, and a count. "All models" is not a container. "One IFC 4.3 federation for Zone B, plus the four native authoring models that produced it" is.

States. Say the CDE state at the moment of exchange — work in progress, shared, published, or archive — and the suitability the container must carry. Shared for coordination is not published for construction. S2 is not A1. If you do not name the state, the appointed party will deliver whatever is on their laptop that week, and you will accept it because the date in the MIDP was met.

Fields. For structured data, list the properties you will actually query. Each field needs a name, a definition, a unit or allowed list, an example, and a named author. "Asset data as required" is how the register is rebuilt by facilities. "IfcFlowTerminal.FireRating, from the project enumerations, authored by the services task team, example FD30" is a field.

Acceptance tests. Write a pass or fail that can be run without calling a meeting. Who runs it, on what sample, against which rule, and what happens on fail. If the only test is "the information manager will review", you have a personality rather than a test. The rejection rule is part of the requirement. An EIR with no reject path is a wish list.

Those four are the whole of what an appointed party can price. Purpose, stage, and date sit around them. They do not replace them.

A reusable template

Copy this structure into a sheet. One row is one exchange. Do not hide exchanges in prose.

Appointment header

Fill this once per appointment, not once per project slogan.

01
Appointment
What you writeNamed contract or work packagenot "the design team"
02
Appointing party
What you writeThe organisation that will accept the exchange
03
Appointed party
What you writeThe organisation that must produce it
04
Project information standard
What you writeThe namingclassification and status list this appointment uses
05
CDE
What you writeThe system of record for states and issuenot "to be confirmed"
06
Related PIR / AIR
What you writeWhich project decisionsor which asset fieldsthis appointment serves

If the header still says "TBC" after the invitation to tender leaves the building, you are asking for a BEP that will invent the standard for you.

Exchange sheet

One row per information exchange. This is the EIR. Everything else is commentary.

ID	Purpose	Stage or date	Container (name, type, format, count)	State	Suitability	Fields or sheets in scope	Acceptance test	Reject if	Who accepts
EX-01

Purpose is a decision or an action the appointing party must take, not "coordination". Stage or date is a calendar the programme can hold. Who accepts is a role that can say no.

Field sheet

Use this wherever the exchange is structured data rather than a drawing series. One row per property.

Field name	Object or sheet	Definition	Unit or allowed values	Example	Author	Required from exchange
						EX-

If you cannot write an example, you do not yet know the field. If two authors could both fill it, you will get both and neither.

Acceptance card

Write this on the back of the exchange row. Four lines. No paragraphs.

Sample. What is inspected — every container, a named percentage, or a named package.
Rule. The pass condition in one sentence a document controller can apply.
Evidence. What is kept: a report, a transmittal, a record of state and suitability, a field-completeness extract.
Fail path. Reject, return to shared, or accept with a dated defect list. Name the resubmission date.

A test that cannot fail will not protect you at the exchange. A test that can only be run by the person who wrote the EIR will not be run when that person is on leave.

One exchange written out

The grain looks like this. Copy the grain, not the project.

EX-04 — Coordinated services model, Level 03, end of Stage 3.

Purpose. Appointing party will freeze coordination for the Level 03 ceiling zone before the Stage 4 architectural issue.
Container. One IFC 4.3 model for Level 03 MEP, named to the project information standard; four native models (ventilation, public health, electrical, controls) that produced it; one clash report as PDF plus BCF.
State / suitability. Shared. S2 — suitable for coordination. Not published. Not A1.
Fields. Every IfcFlowTerminal and IfcFlowMovingDevice on Level 03 carries SystemName from the project system list, FireRating from the project enumerations or NA, and Reference matching the equipment schedule. Units as the project information standard.
Acceptance. Controller exports the IFC. Zero unclassified terminals. Every required field populated from the allowed lists. Clash report lists remaining open items by GUID, not by "to be coordinated". Container is in Shared with S2. Native models match the IFC date-stamp.
Reject if. Any required field blank; suitability missing; file is a coordination-viewer export with no IFC; container still in work in progress; clash report is a screenshot.
Who accepts. Appointing party's information manager, in writing, on the transmittal. Not a comment in a meeting.

A tenderer can price that. They can put hours against the fields, a date against the state, and a risk against the reject rule. They cannot price "LOD 300 MEP".

Test the EIR you already have

You do not need a new appointment to see whether last year's appendix is a slogan. Take the EIR in the current pack. For each paragraph that claims a requirement, ask five questions and write the answers in the margin.

Which information container is this about? If the answer is "models" or "BIM", it is a slogan.
In which state, with which suitability, must it be delivered? If the answer is "on the CDE", it is a slogan.
Which fields, with which units or allowed values? If the answer is "as per COBie" or "as required", it is a slogan.
What is the pass-fail test, and who runs it? If the answer is a review meeting, it is a slogan.
What happens on fail, by which date? If nothing happens, it was never a requirement.

Highlight every paragraph that fails three of the five. That highlight is the work for this week. Rewrite those paragraphs onto the exchange sheet. Leave the rest of the PDF where it is.

If a row cannot be filled without inventing a project information standard, write the standard first — naming, classification, status list, units — and put its name in the appointment header. An EIR that points at a standard that does not exist is another slogan.

The sheets will not certify ISO 19650, replace the UK BIM Framework, write an information protocol, or stand in for the conditions of appointment. Asset information requirements are a different document, for operations; they need their own sheet. A shared drive remains a shared drive. What the appointing party can do, this January, is issue containers, states, fields and tests that a document controller can run without a consultant sitting in the room. Issue that, and the BEP has something to answer.

The cost is real. Someone has to write the project information standard before the invitation to tender leaves the building, and someone has to sit with last year's appendix and move the slogans onto rows. That someone is usually the appointing party's information manager, and they need time in the appointment programme to do it — not a Friday afternoon after the commercial pack has already gone. Until those rows exist, the supply chain will keep answering "we will comply", and you will keep being surprised that they did.