pragmaticBIM
How to Define True Data Requirements in the AI Age: Beyond the IDS Artifact
From static validation files to open, machine-readable data contracts
Published
The Illusion of the Information Delivery Specification (IDS)
The AECO industry has embraced buildingSMART's Information Delivery Specification (IDS) as the silver bullet for data validation. But there is a glaring industry truth we need to address: IDS is not a data requirement standard; it is just an exchange artifact.
An IDS file can tell you if a property exists or if a text string is formatted correctly, but it cannot define the underlying meaning, logic, and commercial purpose of your data contract. If you rely solely on generating static validation files, you are simply checking boxes instead of ensuring downstream utility.
To bridge this gap, pragmaticBIM has open-sourced the elementplan-data-schema. We chose to open-source this standard because true data requirements shouldn't be locked inside proprietary software or static PDF manuals—they must exist as a fluid, machine-readable foundational layer for the entire industry.
The Shift: Moving Away from Project-Specific "Models" to Domain Logic
Traditionally, data requirements were tied strictly to specific models (e.g., "The HVAC Model," "The Structural Model"). But this approach breaks down instantly in the early stages of a project.
At the kickoff, you rarely know how the actual trade or model split will look. Will the timber prefabricator handle the exterior wall finish, or will it fall under a separate facade planner?
The elementplan-data-schema solves this by abstracting requirements away from volatile, project-specific models and anchoring them into Domains and Elements:
- Traditional model-centric data → Fragile (breaks if the trade/model split changes)
- Open elementplan schema → Resilient (tied to universal core Domains & Elements)
By defining data contracts at the core Domain level, your requirements remain entirely unbothered by who models what. You map out universal Elements, their precise Attributes/Properties, and their expected Values based on what the building needs, not who is clicking the mouse.
Actionable Workflows: What to Use the Schema For
Once you decouple your data requirements from project-specific models, you unlock three powerful open-source workflows:
Workflow 1 — Dynamic Data Contracts
Instead of writing 300-page BIM Execution Plans, use the schema to push live, machine-readable data requirements straight to planners based on active project phases.
Workflow 2 — Unbreakable Validation Templates
Generate exchange artifacts (like IDS) automatically from your core schema definition. If your organizational standard evolves, update the schema once, and all downstream validation files update instantly.
Workflow 3 — Seamless Trade Handovers
Because elements are structured by domain logic, you can easily map quantities and qualities directly into ERP, estimation, or procurement systems, regardless of how the raw CAD file was partitioned.
Data Management in the AI Age: "Close Enough" is the New Perfect
The way we enforce BIM quality is changing radically. In the AI era, forcing human planners to manually input text parameters in a hyper-exact, flawless layout is a massive waste of billable hours.
Large Language Models and spatial graph engines don't need absolute text perfection at the point of ingestion. The focus is shifting away from handing in data in a flawless format, to handing it in "close enough" so that automated pipelines can easily structure it.
As long as the human planner provides the core spatial intent and basic elements, AI engines can interpret, clean, and map the incoming data—provided they have a strict target standard to map it to. The open-source elementplan data schema acts as that exact target dictionary, giving AI agents the perfect semantic blueprint to structure messy real-world files for downstream processes like automated quantity takeoffs or thermal simulations.