Skip to content

DemoHouse Analysis — 3-OrderLine Compilation

Foundation: GENERATIVE_HOUSE_SRS.md §10 · BBC §3.4-3.6 · TestArchitecture §Traceability · DISC_VALIDATION_DB_SRS §10.4.2 (FP discipline profile) Session: S59. Building: DemoHouse (SH base + FK roof + FP discipline).

Generative proof — SH base + FK roof swap + FP discipline add. Three OrderLines exercise BOM Drop, component swap, and discipline addition in a single compilation.

1. Scenario Summary

The DemoHouse 3-OrderLine compilation exercises TC-4 (swap) + TC-5 (add discipline):

# OrderLine Product Elements
1 BOM Drop BUILDING_SH_STD 55 (SH base)
2 Swap roof SH_ROOF_STR → FK_DG_STR −2 flat + 42 pitched
3 Add FP sprinklers from ad_space_type_mep_bom TBD (per-room)

Expected total: 55 − 2 + 42 + FP = ~95 + FP elements.

2. Dimensional Analysis — FK Roof on SH Base

2.1 AABB Comparison

Component Width (mm) Depth (mm) Height (mm)
SH building 16,868 8,668 3,945
SH flat roof (SH_ROOF_STR) 14,841 7,285 1,734
FK pitched roof (FK_DG_STR) 13,000 11,000 3,818
DM building 11,000 7,000 2,800
DM flat roof (ROOF_DEMO) 11,000 7,000 500

2.2 Fit Assessment

FK roof on SH base: - Width: FK 13,000 < SH 16,868 → short by 3,868mm (23%). Roof undersized in X. - Depth: FK 11,000 > SH 8,668 → overhangs by 2,332mm (27%). Roof oversized in Y. - Height: FK 3,818 vs SH roof 1,734 → pitched roof is 2.2× taller. Expected.

Risk: FK_DG_STR was designed for a 13×11m footprint; SH base is ~17×9m. The pitched roof won't cover the full SH footprint. Two options: 1. Accept misfit — G2-VOLUME validates replacement fits within building envelope (§10.2). The pitched roof is smaller than the building AABB, so it passes G2 (no protrusion). Coverage gaps are an FP/design concern, not a gate blocker. 2. Scale FK roof to SH footprint — requires SET AABB verb or parametric resize. Per feedback_no_parametric.md, pipeline uses library LODs only, no parametric mesh. Scaling is out of scope.

Decision: Accept misfit for S59. The BOM Drop → swap → compile flow is the test target, not geometric perfection. Add a note in W-DM-TC4-1 that FK roof does not fully cover SH base.

3. Pipeline Walk — 12 Stages for 3-OrderLine Scenario

Source: CompilationPipeline.java (DAGCompiler)

Stage Class Fires? What it does for DemoHouse
1. MetadataValidator MetadataValidator YES Validates referential integrity of BOM + OrderLine data
2. ParseStage ParseStage YES Parses DSL → BuildingDefinition (dsl_sh.bim)
3. CompileStage CompileStage YES BuildingCompiler resolves OrderLine tree → BuildingSpec. BOM explosion uses swapped FK_DG_STR for roof node.
4. TemplateStage TemplateStage NO Only fires in template mode (ST). SH is not ST.
5. WriteStage WriteStage YES Writes compiled spec to output.db. FLAT path emits un-consumed elements. Registers C_Order via REGISTER BUILDING verb.
6. VerbStage VerbStage YES (if .bimcobol exists) Executes BIM COBOL verbs: TRIM WALLS TO ROOF fires here.
7. DigestStage DigestStage YES SpatialDigest hashes spatial structure, COMPLETE BUILDING verb.
8. GeometryStage GeometryStage YES GeometryIntegrityChecker verifies BBox/mesh integrity.
9. ProveStage ProveStage YES PlacementProver runs mathematical proofs.

3.1 Key Interactions

CompileStage (3): BOM explosion walks the C_OrderLine tree. After swapProduct(roof_node, FK_DG_STR), the roof OrderLine points to FK_DG_STR instead of SH_ROOF_STR. The BOM walker resolves FK_DG_STR's 42 child lines (rafters, purlins, slabs) instead of SH's 2 flat roof slabs. The walker uses the same parent-relative offset logic — FK roof elements are placed relative to the roof node's position in the SH tree.

WriteStage (5): FLAT path emits elements not consumed by compiled path. After swap, SH flat roof elements are consumed (replaced), FK pitched roof elements are emitted. FP sprinkler elements from OrderLine 3 are emitted as additional elements.

VerbStage (6): TRIM WALLS TO ROOF verb reads elements_meta/elements_rtree from output.db. For each wall overlapping the FK pitched roof footprint in XY, estimates roof surface Z via tent model. Walls exceeding roof surface are flagged for trim. With FK's pitched roof (ridge along longer axis), the tent model calculates: ridge Z = maxZ, eave Z = minZ, linear slope between.

4. TRIM Verb — Cross-Building Roof Swap Analysis

Source: TrimWallsToRoofVerb.java (BIM_COBOL)

4.1 How It Works

  1. Loads all IfcRoof elements → roofs list (from elements_meta)
  2. Loads all IfcWall/IfcCurtainWall elements → walls list
  3. For each wall, checks XY overlap with each roof via overlapsXY()
  4. Estimates roof surface Z at wall centroid via estimateRoofZ():
  5. Flat roof (dz < 0.1m): surface = maxZ
  6. Pitched roof: tent model — ridge along longer dimension, linear slope
  7. If wall top Z > roofSurfaceZ + 50mm tolerance → flag for trim

4.2 Cross-Building Compatibility

The TRIM verb is geometry-agnostic — it reads AABB from output.db, not from source BOM. After compilation: - FK roof elements are in output.db with their resolved positions - SH wall elements are in output.db with their positions - The verb sees both and computes XY overlaps + tent model Z

No cross-building issue. The verb doesn't care where elements originated.

4.3 FK Pitched Roof Tent Model

FK_DG_STR AABB: 13000 × 11000 × 3818mm. - Longer axis: width (13000mm) → ridge runs along X - Eave Z: placed at ~2800mm (SH wall height, if roof node z-offset maps correctly) - Ridge Z: eave + roof height = 2800 + 3818 = 6618mm (or lower if roof origin is offset) - Slope: linear from ridge to eave across 5500mm (half-depth)

Walls below the slope line are safe. SH curtain walls at 3945mm may exceed the eave line on one side → TRIM fires correctly.

Existing test coverage: W-TRIM-1..6 in TrimWallsToRoofVerbTest.java cover: - Flat roof (surface = maxZ, no trim needed) - Synthetic pitched roof with known slope - Missing: FK-specific roof on SH base (new for S59)

5. swapProduct() API Verification

Source: DesignerAPIImpl.java:1634

5.1 What It Does

swapProduct(orderLineId, buildingId, newProductId)
  → WorkOutputDAO.swapProduct(orderLineId, newProductId)
  → UPDATE C_OrderLine SET family_ref = ?, M_Product_ID = ? WHERE id = ?
  • Updates product pointer only (family_ref + M_Product_ID)
  • Does NOT modify qty, position (dx/dy/dz), or parent relationship
  • The next compilation resolves the new product's BOM tree

5.2 Existing Test Coverage

BomDropConfigureTest.java already tests the full TC-4 flow: - W-TC4-1: bomDrop(BUILDING_SH_STD) → 55 leaves - W-TC4-2: Find SH_ROOF_STR node (category=RF) - W-TC4-3: swapProduct(roof, FK_DG_STR) → success - W-TC4-4: FK_DG_STR has >30 leaf lines

Gap: No test compiles after the swap. W-TC4-1..4 verify the OrderLine/BOM state but don't run the 12-stage pipeline on the swapped tree.

6. FP Discipline — Readiness Assessment

Full spec: BIM_Designer_SRS.md §30.7.4 (FP trial via DocEvent). 5-table chain: DISC_VALIDATE_SRS.md §9.1 (ad_space_type_mep_bom → ad_element_mep → ad_fp_coverage → M_Product → component_definitions). Product categories: BIM_Designer_SRS.md §30.7 (M_Product_Category hierarchy, AD_Org pattern).

Key principle (S61): The BOM records abstract ingredients (SPRINKLER, RISER), not every length variant. The 5-table chain infers quantity from room area, picks the product from the library, and the compiler determines actual dimensions from the containing space. User can swap the placed product for an alternative within the same category (FP_HEAD → other FP_HEAD).

6.1 Data Layer (READY)

  • ad_space_type_mep_bom: 186 rules seeded (DV001 migration)
  • ad_fp_coverage: hazard class → max_coverage_m2, max_spacing_m
  • ad_element_mep: discipline='FP' products catalogued

6.2 Query Layer (READY)

  • MEPBomAD.getBOM(spaceType): queries ad_space_type_mep_bom for room type
  • MEPBomAD.getQuantity(): calculates qty per profile (BUDGET/STANDARD/PREMIUM)

6.3 Product Catalog Layer (GAP — S61 finding)

  • component_library.db has zero IfcFlowTerminal products (100 products, all ARC/STR)
  • TE_BOM.db has 22 FP products but they are not onboarded to the library
  • M_Product_Category table does not exist yet — schema spec'd in §30.7.1
  • Fix: Onboard 2-3 FP products (sprinkler + alarm) with geometry from TE extraction. See BIM_Designer_SRS.md §30.7.4 for steps.

6.4 Validation Layer (PARTIAL)

  • PlacementValidatorImpl.validateBatch(): exists, handles spatial rules
  • PlacementValidatorImpl.checkClearance(): FP-STR clearance check exists
  • Gap: validateBatch() not wired into auto-populate flow. FP sprinklers are placed but not validated against NFPA 13 spacing.

6.5 Test Layer (MISSING)

  • FPValidationTest.java: does not exist — documented as NEEDED in §10.3
  • DemoHouseTest has room geometry fixtures but no FP placement tests
  • ~~DemoHouseCompileTest~~ removed (S67). DM compiles via standard Rosetta Stone pipeline (run_RosettaStones.sh classify_dm.yaml). MEP products onboarded via DocEvent path with real products (S67: 2 ELEC products from TE extraction)

7. Pre-Requisite Status (§10.3)

Task Status Notes
A: Specs DONE §7 TC-4+TC-5 specified. This analysis doc created.
B: Pipeline DONE §3 above documents all 12 stages for 3-OrderLine.
C: TRIM verb READY Code exists (S53). Cross-building trim is geometry-agnostic. FK-on-SH test needed.
D: BOM Drop cascade READY bomDrop() + swapProduct() GREEN. BomDropConfigureTest covers TC-4 swap.
E: FP rules PARTIAL Data + query ready. validateBatch() wiring NOT DONE.
F: Mock tests PARTIAL BomDropTest + BomDropConfigureTest exist. TrimVerbTest exists (synthetic). FPValidationTest NEEDED.

8. Session 1 Findings → Session 2 Plan

What's Proven

  1. bomDrop(BUILDING_SH_STD) produces 55-element tree — GREEN (W-TC4-1)
  2. swapProduct() changes roof OrderLine to FK_DG_STR — GREEN (W-TC4-3)
  3. TRIM verb handles any roof shape via tent model — GREEN (W-TRIM-1..6)
  4. Pipeline's 12 stages all fire for SH-based compilation — GREEN

What's Needed (Session 2)

  1. Post-swap compilation test: Run 12-stage pipeline on swapped tree, verify element count = 55 − 2 + 42 = 95
  2. TRIM on FK roof: Add test case in TrimVerbTest with FK roof dimensions on SH walls
  3. FP OrderLine insertion: API to add discipline=FP OrderLine to existing Order
  4. FPValidationTest: New test class for sprinkler placement + NFPA 13 spacing

Session 2 Results

  1. W-DM-TC4-1 GREEN: Post-swap compile produces 95 elements (55 − 2 + 42)
  2. G1-COUNT: 95 elements. G8-GEOMETRY: 95/95 OK. G5-PROVENANCE: 0 GEO_ fallback.
  3. Element breakdown: 51 IfcMember (FK rafters/purlins), 14 IfcFurnishingElement, 8 IfcWall, 6 IfcWindow, 6 IfcPlate, 3 IfcSlab, 3 IfcDoor, 2 IfcRailing, 2 IfcBeam
  4. Mechanism: BOM swap applied to m_bom_line (child_product_id SH_ROOF_STR→FK_DG_STR). Pipeline BOMWalker naturally resolves FK_DG_STR's 42 children. No pipeline code changes needed.
  5. VERB stage: PLACE BOM verb hits UNIQUE constraint (pre-existing, non-blocking). TRIM verb deferred to Session 4.

Lifecycle Correction (S59, updated S61)

BomDropConfigureTest currently copies SH_BOM.db as compile DB — incorrect. ~~Correct lifecycle: work_output.db is the design workspace.~~ Updated S61: work_output.db removed from architecture (DocAction_SRS.md §1.10). Correct lifecycle: BOM is read-only. Save = Blender save. CompleteIt compiles BOM → output.db (path editable by user). Approve promotes as new BOM with parent category, qualified name, and author/version metadata.

What's Needed (Session 2+)

  1. Geometric fingerprint test: BOM-predicted vs compiled verification (§11)
  2. TRIM verification: CW panels bounded by FK pitched roof (P27 proof)
  3. FP discipline (Session 3): Sprinkler placement + NFPA 13 spacing

Risks

  • FK roof AABB (13×11m) doesn't cover SH footprint (17×9m) — accepted, not a gate blocker
  • FP validateBatch() wiring is the largest remaining gap — Session 3 scope

Recompilation (S100-p85 Fleet Audit, 2026-03-28)

FAIL — MetadataValidator error: no such table: M_Product

DM is a GENERATIVE building — it has no IFC extraction source. The compile DB (copied from SH_BOM.db) lacks the M_Product table that MetadataValidator.checkPositiveDimensions() queries. This is a pre-existing issue: DM works via the BomDropConfigureTest path (which seeds M_Product from the swap scenario) but not via the standard Rosetta Stone pipeline.

Metric Value
Elements 60 (from BomDropConfigureTest path, not pipeline)
Pipeline result FAIL (MetadataValidator pre-condition)
C_Order 0 rows in output.db

Fix needed: Either (a) seed M_Product in the DM compile DB preparation step, or (b) make MetadataValidator skip M_Product checks for GENERATIVE entries.