In many projects, we often hear a familiar line:
Please provide all the information according to the delivery requirements.
This sentence has almost become an unspoken rule — as if once the delivery checklist is complete, the project’s information is complete too.
That checklist might include things like:
- Submit the IFC model and native source files
- Follow a specific naming convention for files
- Use a defined codification for elements
- Meet a certain fire safety rating
- Achieve at least a energy performance level B
- …and so on
But these are delivery needs, not information requirements.
We’ve grown used to finding certainty in “what to deliver,” while rarely questioning the logic behind “what to know.” In reality, these two ideas may seem close, but they belong to completely different layers.
Delivery needs describe results; information requirements describe the foundation for reasoning and decision-making. Understanding their difference is not just a technical matter, it’s the starting point for understanding what digital construction truly means.
Delivery needs are about outcomes
Delivery needs are result-oriented.
They answer the question: “What do I need to deliver?” In a real project, they’re usually defined by contracts, regulations, or client expectations. For instance:
- The wall’s fire resistance rating must reach Level B
- Safety doors must have labels
- The model must include room energy classifications
- File names must follow a specific pattern
These describe the conditions of a compliant handover. They depend on the project environment, timing, and regional rules. Therefore, they often change with external conditions.
Change the country, the version, or the evaluation framework, and the delivery requirements will likely change too. In one place, fire ratings might be A/B/C; in another, 1/2/3; in yet another, expressed in minutes. Today it might be three levels, tomorrow five. Delivery needs always change, they’re the “surface order” shaped by context, regulation, and time.
They tell you what needs to be submitted at a certain point in a certain environment,
but they don’t tell you what information is necessary to produce that result.
Information requirements are about understanding
Information requirements, on the other hand, are knowledge-oriented.
They’re not just a list of fields on a template, but a definition of what we need to know in order to judge, verify, or decide something. Take fire performance again as an example. To assess a wall’s fire resistance, what we actually need to know is:
- the wall’s material
- its thickness
- whether it’s load-bearing
- which fire zone it belongs to
- the material’s thermal properties and fire endurance time
These pieces of information form the basis of evaluation. No matter whether the rating system uses A/B/C or 1/2/3, as long as we have these facts, we can always compute a new result under a different environment.
Information requirements answer the question: “What do I need to know to meet a need, make a judgment, or perform a calculation?”
In other words, information requirements define a stable semantic layer — one that allows data to remain meaningful even as external contexts shift.
When information requirements are clearly defined, you can reuse the same data to meet different delivery standards or compliance rules. That’s the essence of data reusability, you’re no longer bound to one single delivery scheme, but able to adapt across many.
That’s what gives information requirements their true power: they make data alive over time.
Deliveries Change. Information Endures.
Regulations can update. Formats can be replaced. Rating systems can be rewritten. But facts like a wall’s thickness, material, or thermal conductivity never “expire.” What you need to know today, you’ll still need ten years later.
Delivery needs belong to the language of compliance.
Information requirements belong to the structure of knowledge.
When you record “Level B,” that’s just a label. When you record “fire resistance = 120 minutes,” that’s a fact. Labels may change with new standards, but facts can always be reinterpreted — labels can only be reassigned.
That’s why information needs matter: they define the sustainability of data.
The real stability of a project doesn’t come from how strictly it follows every rule in a delivery template, but from how clearly it defines its information requirements — what needs to be known, not just what needs to be delivered.
A Simple Example
Let’s look again at “fire performance.” Delivery needs and information requirements may sound similar, but logically, they point to entirely different layers:
| Aspect | Delivery Needs | Information Requirements |
|---|---|---|
| Definition | A label describing a required result (e.g., “Fire rating = B”) | Factual information for reasoning (e.g., “Material, thickness, fire endurance = 120 min”) |
| Nature | Dependent on project, regulations, or region | Reflects intrinsic physical or semantic properties |
| Change over time | Frequently updated with new standards or rules | Relatively stable and reusable across regions and versions |
| Purpose | To meet short-term compliance goals | To support long-term validation, reuse, and reasoning |
Now that you see their difference. What should we do about it?
From Delivery to Understanding
The truth is, most project teams work around delivery templates, field lists, and regulatory checklists, all to pass an acceptance test once. They spend time updating forms, filling fields, renaming files, exporting models again and again, everything just to comply. Each time the standards change, the whole cycle restarts: deliver → revise → deliver again. The result is low efficiency and no long-term accumulation.
The same happens for owners, regulators, even governments. When “delivery” dominate the agenda, the entire system becomes driven by short-term compliance. Once a new regulation is issued, all past data risks becoming instantly “invalid.” All previous deliverables turn into “non-compliant data.” And no one can answer questions like: "Which data is still valid?", "What can be reused?", "Which projects remain compliant under the new rules?", "Which ones need revision?"
To fix this, we need a different mindset, from preparing data for delivery, to preparing data for understanding.
Define the information requirements first, and then generate delivery outputs based on them. When your data model is built upon clear guidence, delivery files become just one possible output format, not the ultimate goal.
For project teams, this means identifying what needs to be understood, validated, and reused. For example, rather than focusing only on wall types or names, define their material, thickness, insulation, and fire endurance. Then, based on different regulations, you can generate compliant outputs dynamically. When requirements change, you simply reconfigure rules, not rebuild data. The information remains stable — delivery becomes derivative.
For owners and regulators, this shift is even more meaningful. Instead of receiving one-time compliant files, they receive digital assets that can be reused and updated. As regulations evolve, these assets remain valid, because rules can be reinterpreted without rewriting all the data. This is how digital assets stay sustainable, and how information gains continuity over time.
It marks the evolution from delivery to understanding.
Information requirements guarantee the continuity of data
Information requirements matter not only because they make data reusable, but because they give it continuity and life.
When an organization builds its systems around information requirements, data stops being a project side-product, it becomes part of its knowledge base. It can be updated, verified, recombined, and continue to play a role in new contexts, decisions, and systems.
From a higher perspective, delivery needs represent the surface order, while information needs form the deeper order beneath. The former responds to today’s compliance; the latter sustains tomorrow’s reuse and evolution.
An organization that builds solely around delivery needs will always chase the next standard. But one that builds upon information needs can preserve semantic continuity even as languages, regulations, and standards change.
When we begin defining what to know instead of what to deliver, our digital practice transforms.
Delivery is no longer a pressure, it becomes a natural outcome. Information becomes understandable, verifiable, and reusable. And standards become not just rules to follow, but a shared way of understanding knowledge itself.
That is the true meaning of information requirements.
Perhaps, in the end, what really matters is not filling every required field, but answering a much deeper question: “To know what I want to know — what do I truly need to know?”