The construction industry has long chased the promise of Building Information Modeling (BIM), envisioning a world where a single digital twin manages every detail of a structure from the first sketch to the final demolition. In theory, this integration reduces communication errors and slashes project timelines. In practice, however, BIM often devolves into little more than a sophisticated 3D drawing. The missing link is standardization. Without a rigorous definition of what data must be embedded within a model, the digital twin is a shell without a brain. This gap is governed by Information Delivery Specifications (IDS), an XML-based standard that defines and verifies the information attached to BIM models. For years, creating these specifications has been the exclusive domain of a tiny elite who possess a rare overlap of IT expertise and deep architectural knowledge. The barrier to entry is not just steep; it is a wall that has effectively stalled the adoption of BIM in small and medium-sized firms.
The Architecture of Domain-Specific Intelligence
General-purpose frontier models, despite their linguistic prowess, fail catastrophically when faced with the rigid requirements of IDS. Initial tests revealed a grim reality: general models achieved only about 25% compliance with IDS structural rules and nearly 0% consistency in content. They could mimic the look of XML, but they could not adhere to the strict logic of Industry Foundation Classes (IFC), the global standard for BIM data exchange. To solve this, the Ishigaki-IDS project moved away from general-purpose prompting toward a rigorous, three-stage domain-specialization pipeline built upon the Qwen3 family of models. Developers utilized Qwen3 8B, 14B, and 32B variants, using the smaller models to iterate on training directions before scaling to the 32B parameter version for final production.
The first phase involved Continued Pre-training (CPT). Because public datasets for BIM and IDS are virtually non-existent, the team relied on a combination of web-scraped corpora and high-fidelity synthetic data designed by domain experts. This stage was about building a foundational vocabulary, teaching the model the fundamental relationships between architectural elements and the IFC standards they must follow. Once the model understood the domain, the team implemented Supervised Fine-tuning (SFT). This process paired natural language instructions with correct IDS output pairs, training the model to translate a human's intent—such as defining the properties of a load-bearing wall—into a precise XML structure. However, SFT alone proved insufficient. The model frequently hallucinated XML tags or produced structures that looked correct but were logically invalid, a common failure mode when LLMs attempt to handle strictly nested, rule-based languages.
To bridge this final gap, the team deployed Reinforcement Learning with Verifiable Rewards (RLVR). Instead of relying on a human to grade the output, they integrated the IDS-Audit-Tool provided by buildingSMART directly into the reward function. The tool acted as an automated judge, providing a binary signal of success or failure based on whether the generated XML was valid and semantically consistent. The model then iterated on its own outputs, treating the audit tool's feedback as a reward signal to refine its internal weights. This created a closed-loop system where the model learned the exact boundaries of the IDS standard through trial and error, guided by a mathematical truth rather than probabilistic guessing.
Breaking the Expert Bottleneck with 120k Context
The result of this pipeline was a dramatic shift in performance. On the IDS-Bench—a specialized benchmark developed by internal experts covering architecture, structure, MEP (mechanical, electrical, and plumbing), and common construction fields—Ishigaki-IDS achieved approximately 100% compliance in XML and IDS structure. More importantly, it reached over 80% content consistency. This means the model is not just generating valid code; it is understanding the logical relationships inherent in construction data. While a general model might produce a valid XML tag, Ishigaki-IDS knows that a specific architectural requirement must map to a specific IFC entity to be useful in the real world.
One of the most significant technical hurdles in BIM is the sheer volume of input data. Architectural design guidelines can span thousands of pages, and IFC data structures are notoriously verbose. To handle this, the team implemented YaRN (Yet another RoPE extensioN), a technique that extends the context window of Transformer models without the typical degradation in performance. This allowed Ishigaki-IDS to support a context window of up to 120k tokens. In a practical workflow, this means a user can feed an entire set of project-specific design guidelines into the model and receive a comprehensive IDS file that remains consistent from the first line to the last. This capacity transforms the tool from a simple snippet generator into a system capable of managing large-scale project specifications.
This computational ambition required a massive infrastructure backbone. The training was conducted on Amazon EC2 P5en instances, specifically utilizing two `p5en.48xlarge` nodes equipped with NVIDIA H200 Tensor Core GPUs. The cluster was managed via AWS ParallelCluster, which streamlined the deployment of the high-performance computing (HPC) environment. To prevent data bottlenecks during distributed training, the team used Amazon FSx for Lustre, a managed file system capable of sub-millisecond latencies and massive throughput. This ensured that the GPUs were never idling while waiting for synthetic data or model checkpoints to load, maximizing the efficiency of the H200s.
The real-world utility of this system was validated through a joint Proof of Concept (PoC) with buildingSMART. The test involved both seasoned IDS experts and complete novices. The most striking finding was the model's ability to handle ambiguous, natural language prompts. Non-experts, who lacked the vocabulary to describe IFC entities precisely, were able to express their intent in plain language, and Ishigaki-IDS successfully translated those vague requests into valid, audit-passing IDS files. This effectively democratizes the standardization process, allowing the people who actually know the building's requirements to define the data standards, rather than relying on a handful of technical intermediaries.
For the broader AI community, the Ishigaki-IDS project serves as a blueprint for tackling data-poor, high-precision domains. It proves that when a domain has a mechanical way to verify correctness—like the IDS-Audit-Tool—RLVR is far more effective than simply scaling the size of the SFT dataset. By replacing human labeling with automated verification and expanding the context window to accommodate professional-grade documentation, the project has turned a specialized technical chore into a natural language conversation.
