Diff: reference/bim-design-philosophy
From 13b8caa to 13b8caa
+0 / −0 lines
| Before | After |
|---|---|
| --- | --- |
| schema: foundry-doc-v1 | schema: foundry-doc-v1 |
| type: topic | type: topic |
| slug: bim-design-philosophy | slug: bim-design-philosophy |
| short_description: "The Building Design System serves as the AEC-specific extension anchored to IFC 4.3, translating platform commitments of flat-file storage, open standards, and offline-first execution into a professional toolset that addresses structural weaknesses of legacy cloud-only BIM platforms." | short_description: "The Building Design System serves as the AEC-specific extension anchored to IFC 4.3, translating platform commitments of flat-file storage, open standards, and offline-first execution into a professional toolset that addresses structural weaknesses of legacy cloud-only BIM platforms." |
| title: "BIM design philosophy" | title: "BIM design philosophy" |
| audience: vendor-public | audience: vendor-public |
| bcsc_class: current-fact | bcsc_class: current-fact |
| language: en | language: en |
| paired_with: bim-design-philosophy.es.md | paired_with: bim-design-philosophy.es.md |
| cites: [ifc-4-3, uniclass-2015, bsdd-v1] | cites: [ifc-4-3, uniclass-2015, bsdd-v1] |
| category: reference | category: reference |
| --- | --- |
| 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-microkernel-substrate|seL4 security foundation]] provides the hardware-attested isolation that defence and healthcare clients require. | 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-microkernel-substrate|seL4 security foundation]] provides the hardware-attested isolation that defence and healthcare clients require. |
| ## Structural Differentiators | ## Structural Differentiators |
| The platform’s design philosophy is predicated on five capabilities that are structurally incompatible with multi-tenant SaaS models: | The platform’s design philosophy is predicated on five capabilities that are structurally incompatible with multi-tenant SaaS models: |
| 1. **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. | 1. **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. |
| 2. **Offline-Capable Operations:** Full BIM functionality is maintained in basements, air-gapped facilities, and remote sites where internet access is unavailable. | 2. **Offline-Capable Operations:** Full BIM functionality is maintained in basements, air-gapped facilities, and remote sites where internet access is unavailable. |
| 3. **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. | 3. **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. |
| 4. **Local IoT Integration:** Sensor data is ingested via local brokers into YAML sidecars, ensuring data residency and eliminating usage-based token charges. | 4. **Local IoT Integration:** Sensor data is ingested via local brokers into YAML sidecars, ensuring data residency and eliminating usage-based token charges. |
| 5. **Legal-Financial Convergence:** The [[totebox-archive|Totebox Archive]] unifies the building’s spatial, operational, and financial identities into a single portable artifact. | 5. **Legal-Financial Convergence:** The [[totebox-archive|Totebox Archive]] unifies the building’s spatial, operational, and financial identities into a single portable artifact. |
| ## Compositional-First Regulatory Compliance | ## 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. | 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. | This shift from "check-after-design" to "compliant-by-construction" represents a significant leapfrog in AEC technology. |
| ## Integration with the META-Substrate | ## Integration with the META-Substrate |
| The BIM-SEMANTIC layer sits atop project-design’s META-substrate. While project-design owns the baseline Carbon and DTCG vault standards, project-bim manages the BIM-specific extensions: | The BIM-SEMANTIC layer sits atop project-design’s META-substrate. While project-design owns the baseline Carbon and DTCG vault standards, project-bim manages the BIM-specific extensions: |
| * 8 BIM token categories anchored to IFC 4.3. | * 8 BIM token categories anchored to IFC 4.3. |
| * 18 specialized component recipes. | * 18 specialized component recipes. |
| * Uniclass 2015 as the universal classification floor. | * 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. | 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 | ## See also |
| - [[bim-aec-muscle-memory]] | - [[bim-aec-muscle-memory]] |
| - [[bim-token-taxonomy]] | - [[bim-token-taxonomy]] |
| - [[flat-file-bim-leapfrog]] | - [[flat-file-bim-leapfrog]] |