Why IDS Matters More Than Another PDF Requirement

Someone I interviewed on the podcast keeps a list of useless openBIM requirements in his OneNote. He coordinates BIM on infrastructure projects in Germany, ten years of them. I asked him for the worst requirements he has seen in contracts. He did not have to think long.

Clash free models. Sounds good, impossible to deliver.

Everyone works in one model. Also impossible.

Native files delivered next to the IFC. Then why openBIM at all.

And my personal favorite: custom property sets for information the IFC schema already has. Material name exists in the standard. They invent their own field for it anyway. Now everything is defined twice and nothing matches.

Every one of those requirements lived in a PDF. Somebody wrote it, somebody signed it, and then every company on the project paid for it, on every delivery, for years. That is the real cost of requirements as prose: one badly written sentence becomes a recurring tax on the whole project.

This is the problem IDS exists to solve. Let me explain why it matters more than most people think.

What a PDF requirement actually does

A requirement written in a document does not check anything. It gets read by a human, interpreted, and turned into work by another human. Every step is a place where meaning leaks.

"All walls shall have a fire rating." Which walls? In which property? In what format? Required at which project stage? The author knew what they meant. The modeler exporting the file six months later did not, so they guessed. Then the checker on the receiving side interpreted the sentence a third way, and now the delivery fails a check the modeler never knew existed.

Most bad IFC is not a modeling problem. It is a requirements problem. Nobody told the person exporting the file what good looked like, so they guessed. A PDF cannot fix that, because a PDF cannot be precise enough to remove the guessing, and it cannot be run.

What IDS actually is

IDS, Information Delivery Specification, is a buildingSMART standard for writing information requirements in a machine-readable form.

Instead of "all walls shall have a fire rating," an IDS file says: every IfcWall must carry Pset_WallCommon, the property FireRating must exist, and it must have a value from this list. Exact. No interpretation. No guessing.

And because it is machine-readable, the same rule runs everywhere. The modeler can validate the export against the IDS before sending it. The receiver runs the identical check on arrival. The requirement, the export, and the check finally agree, because they are literally the same file.

That is the difference in one sentence. A PDF requirement describes good. An IDS requirement defines good in a form that can be checked, automatically, the same way every time.

The detail that separates a working IDS from a decorative one

One lesson from real files: require values, not just property sets.

The most dangerous IFC file is not the one that fails to open. It is the one where the property sets exist but every value is blank. You see Pset_WallCommon on the walls and it looks like the data is there. A lazy check that only tests for the presence of the property set passes it. Then someone downstream reaches for the fire ratings and there is nothing inside.

Empty property sets create the illusion of data. So when you write IDS rules, write them against content. The property must exist and it must hold a valid value. Presence is not the test. Content is.

Why this changes your position, not just your files

There is a second effect of working with IDS, and I see it in coordinators all the time.

Without a standard behind you, you are checking by feel. You reject a file, the sender pushes back and asks which standard requires this, a project manager asks why a property set matters, and the honest answer is "I read it in a checklist." Checking by feel works until someone challenges it.

Checking by standard means you know what sits underneath: the IFC schema, ISO 19650, IDS. Your rejections become defensible. Your requirements carry weight. The conversation stops being your opinion against theirs and becomes the specification against the file.

The uncomfortable conclusion

On that podcast we ended up half joking that people who write information requirements should be certified practitioners before they are allowed to write them. The more I think about it, the less it is a joke.

The tools are not the bottleneck anymore. IDS is a solid standard and the software support is real. The bottleneck is the competence of the person writing the requirements. A bad requirement in IDS form is still a bad requirement, just faster at failing files. The skill that matters is knowing what to require, where it lives in the schema, and what the receiver actually needs.

That skill can be learned. Writing it into your project instead of another PDF is one of the highest-leverage moves available in openBIM right now.