Diff: architecture/city-code-as-composable-geometry

From eb4cee1 to eb4cee1

+0 / −0 lines

Before	After
---	---
schema: foundry-doc-v1	schema: foundry-doc-v1
title: "City code as composable geometry"	title: "City code as composable geometry"
slug: city-code-as-composable-geometry	slug: city-code-as-composable-geometry
short_description: "An architectural model that encodes regulatory requirements directly into element specifications as geometric and numeric constraints rather than applying them post-design, making non-compliant configurations structurally impossible by construction."	short_description: "An architectural model that encodes regulatory requirements directly into element specifications as geometric and numeric constraints rather than applying them post-design, making non-compliant configurations structurally impossible by construction."
category: architecture	category: architecture
type: topic	type: topic
quality: complete	quality: complete
status: active	status: active
bcsc_class: public-disclosure-safe	bcsc_class: public-disclosure-safe
last_edited: 2026-05-17	last_edited: 2026-05-17
editor: pointsav-engineering	editor: pointsav-engineering
cites: [ifc-4-3, ids-1-0, bsdd-v1]	cites: [ifc-4-3, ids-1-0, bsdd-v1]
paired_with: city-code-as-composable-geometry.es.md	paired_with: city-code-as-composable-geometry.es.md
---	---

Every building code compliance tool in production follows the same architecture: a completed design model is submitted to a rules engine, which generates a violation report, which a human must review and remediate before resubmission. This post-design validation model has been the industry standard for twenty years. It produces a structural tension between design iteration speed and compliance verification. The more thorough the rules engine, the longer each review cycle. A different architecture is possible: if regulatory requirements are encoded directly into the elements available to a designer — not as rules applied to a finished model but as geometric and numeric constraints embedded in the element specification — then non-compliant configurations cannot be placed. This is the City Code as Composable Geometry model, and it is the architectural claim underlying the [[bim-objects-what-they-are\|BIM Object]] platform.	Every building code compliance tool in production follows the same architecture: a completed design model is submitted to a rules engine, which generates a violation report, which a human must review and remediate before resubmission. This post-design validation model has been the industry standard for twenty years. It produces a structural tension between design iteration speed and compliance verification. The more thorough the rules engine, the longer each review cycle. A different architecture is possible: if regulatory requirements are encoded directly into the elements available to a designer — not as rules applied to a finished model but as geometric and numeric constraints embedded in the element specification — then non-compliant configurations cannot be placed. This is the City Code as Composable Geometry model, and it is the architectural claim underlying the [[bim-objects-what-they-are\|BIM Object]] platform.

## The Validation-First Paradigm	## The Validation-First Paradigm

Post-design validation tools operate on a common pattern:	Post-design validation tools operate on a common pattern:

1. A designer authors a model in an IFC-capable authoring tool.	1. A designer authors a model in an IFC-capable authoring tool.
2. The model is exported to IFC format and submitted to a validation service.	2. The model is exported to IFC format and submitted to a validation service.
3. The validation service applies a ruleset — encoded in proprietary rule languages, IDS 1.0 constraint files, or platform-specific scripting — and produces a report listing violations.	3. The validation service applies a ruleset — encoded in proprietary rule languages, IDS 1.0 constraint files, or platform-specific scripting — and produces a report listing violations.
4. A human reviews the report, returns to the authoring tool, makes corrections, and resubmits.	4. A human reviews the report, returns to the authoring tool, makes corrections, and resubmits.

This cycle repeats until the model passes. Most authoring tools enforce nothing at placement time: any element may be placed anywhere until the external validator objects.	This cycle repeats until the model passes. Most authoring tools enforce nothing at placement time: any element may be placed anywhere until the external validator objects.

The consequences are operational. Design teams budget iteration time for compliance review. On complex projects, regulatory review cycles add weeks to design phases. The validator is a gating function that sits outside the design environment and communicates asynchronously with it.	The consequences are operational. Design teams budget iteration time for compliance review. On complex projects, regulatory review cycles add weeks to design phases. The validator is a gating function that sits outside the design environment and communicates asynchronously with it.

## Prior Art Survey	## Prior Art Survey

Research conducted in April 2026 identified four categories of prior art, all in the validation-first quadrant.	Research conducted in April 2026 identified four categories of prior art, all in the validation-first quadrant.

IDS 1.0 (Information Delivery Specification). buildingSMART's IDS standard encodes property constraints in XML. An IDS file declares what a valid model contains — it is a validation language, not a constraint on element palettes. IDS files are inputs to validators, not constraints applied during design.	IDS 1.0 (Information Delivery Specification). buildingSMART's IDS standard encodes property constraints in XML. An IDS file declares what a valid model contains — it is a validation language, not a constraint on element palettes. IDS files are inputs to validators, not constraints applied during design.

bSDD (buildingSMART Data Dictionary). The bSDD provides semantic identity for element types across jurisdictions and tools. It does not encode regulatory constraints or climate zone performance requirements. A bSDD URI is an identity anchor, not a constraint specification.	bSDD (buildingSMART Data Dictionary). The bSDD provides semantic identity for element types across jurisdictions and tools. It does not encode regulatory constraints or climate zone performance requirements. A bSDD URI is an identity anchor, not a constraint specification.

Post-design validation platforms. Commercial BIM validation platforms operate post-design. Their rules engines can check geometry, topology, property values, and spatial relationships — but they operate as audit tools on submitted models. Non-compliant models pass through authoring environments without objection until submission.	Post-design validation platforms. Commercial BIM validation platforms operate post-design. Their rules engines can check geometry, topology, property values, and spatial relationships — but they operate as audit tools on submitted models. Non-compliant models pass through authoring environments without objection until submission.