BIM design philosophy
The Building Design System serves as the AEC-specific extension of the platform's design substrate, analogous to the relationship between IBM Carbon and specialized industry modules. It is anchored to the IFC 4.3 entity hierarchy and prioritized for high-fidelity operational environments. The system translates the platform's core commitments — flat-file storage, open standards, and offline-first execution — into a professional toolset that addresses the structural weaknesses of legacy cloud-only BIM. The seL4 security foundation provides the hardware-attested isolation that defence and healthcare clients require.
Key Takeaways
- The design system is anchored to the IFC 4.3 entity hierarchy and uses a text-based open-standard stack (IFC-SPF, BCF 3.0, IDS 1.0, COBie). Data structured to these standards remains accessible for 50+ years and outlasts the specific software vendors that generate it.
- Asset-Anchored BIM is the structural differentiator: the digital twin is a legal artifact signed with the land title. It moves with the property deed rather than being held in a vendor's tenant model — the data survives platform changes or vendor failure without requiring a migration.
- Compositional-first regulatory compliance shifts from "check-after-design" to "compliant-by-construction". Cities publish codes as composable design tokens (bSDD dictionaries + IDS 1.0 constraints), and designers assemble models within pre-constrained envelopes where violations become geometrically impossible before they occur.
- Offline capability is structural, not a feature flag. Full BIM functionality is maintained in basements, air-gapped facilities, and remote sites. This structural property separates the platform from cloud-only BIM tools that require a persistent connection to function.
Structural Differentiators
The platform's design philosophy is predicated on five capabilities that are structurally incompatible with multi-tenant SaaS models:
- Asset-Anchored BIM: The digital twin is a legal artifact signed with the land title, moving with the property deed rather than being tied to a vendor's tenant model.
- Offline-Capable Operations: Full BIM functionality is maintained in basements, air-gapped facilities, and remote sites where internet access is unavailable.
- Vendor-Obsolescence Survival: By utilizing a text-based open-standard stack (IFC-SPF, BCF 3.0, IDS 1.0, COBie), data remains accessible for 50+ years, outlasting specific software vendors.
- Local IoT Integration: Sensor data is ingested via local brokers into YAML sidecars, ensuring data residency and eliminating usage-based token charges.
- Legal-Financial Convergence: The building archive unifies the building's spatial, operational, and financial identities into a single portable artifact.
Compositional-First Regulatory Compliance
The platform introduces a "compositional-first" approach to building codes and jurisdictional rules. Instead of post-design validation, cities are intended to publish codes as composable design tokens (bSDD dictionaries + IDS 1.0 constraints). Designers then assemble models within pre-constrained envelopes where violations become geometrically impossible by construction.
This shift from "check-after-design" to "compliant-by-construction" represents a significant leapfrog in AEC technology.
Integration with the Design Substrate
The BIM-SEMANTIC layer sits atop the platform's broader design-token substrate. While the baseline design-token and DTCG vault standards are shared across the platform, the Building Design System manages the BIM-specific extensions:
- 8 BIM token categories anchored to IFC 4.3.
- 18 specialized component recipes.
- Uniclass 2015 as the universal classification floor.
This architecture ensures that BIM components remain consistent with the broader platform design language while meeting the rigorous semantic requirements of ISO-standardized building data.
See also
- bim-aec-muscle-memory
- bim-token-taxonomy
- Flat-file BIM leapfrog