Integration from Module Schemas to Full Model: Difference between revisions

From Open Source Ecology
Jump to navigation Jump to search
 
(13 intermediate revisions by the same user not shown)
Line 1: Line 1:
=About=
=About=


This must be done not by gurus—by clerks following specs.
To automate full CAD of Seed Eco-Homes, we must translate the implicit knowledge of the Seed Eco-Home build system. This must be done not by gurus—bbut by clerks following specs.


Why? Because of this - [https://chatgpt.com/share/69745a2f-5cfc-8010-9b29-09fe48aa4c1a]. In short: The real risk is not skill level—it’s unconscious substitution. The danger is not incompetence. The danger is: “I know a better way to do this.”
Why? Because of this - [https://chatgpt.com/share/69745a2f-5cfc-8010-9b29-09fe48aa4c1a]. In short: The real risk is not skill level of [[EAC]] programmers —it’s unconscious substitution. The danger is not incompetence. The danger is: “I know a better way to do this.”


=Howto=
The core simplification: '''Assembly is not geometry. Assembly is topology.''' Geometry already exists at the module level. Assembly is simply how modules are connected.
If you accept that, everything downstream becomes tractable.
<nowiki>
= Induction-Grade House Compiler Process (Modules → Assembly → Post-Compilers) =
= Induction-Grade House Compiler Process (Modules → Assembly → Post-Compilers) =


Line 21: Line 15:
No manual CAD edits. Every output must be regenerable from schemas.
No manual CAD edits. Every output must be regenerable from schemas.


== 0. Inputs and Conventions (Lock These In) ==
==Canonical Principle 2==
=== 0.1 Coordinate and Reference Convention ===
#Schemas describe intent
* Each module has a local coordinate frame (CSYS) and published ports/faces.
#Assemblies describe relationships
* The assembly has a world CSYS and places modules via topology constraints.
#Compilers produce geometry
* Every placed object is referenced by:
 
= Assembly Canon: Topology, Not Geometry =
 
== Canonical Statement ==
'''Assembly is not geometry. Assembly is topology.'''
 
Assembly declares '''relationships'''.
Geometry is a '''derived consequence'''.
 
If geometry is specified at the assembly level, automation fails.
If topology is specified, geometry becomes compilable.
 
== Definitions ==
 
=== Module ===
A module is a self-contained, parametric unit with:
* Local coordinate system (CSYS)
* Known dimensions
* Named connection ports (left, right, top, bottom, etc.)
* Published metadata (stud map, faces, no-go zones)
 
Modules contain geometry.
Assemblies do not.
 
=== Assembly ===
An assembly is a '''connection graph''' consisting only of:
* Module instances
* Connections between module ports
 
An assembly answers:
* What exists?
* What connects to what?
* Through which ports?
 
Nothing else.
 
== What Assembly Explicitly Does NOT Contain ==
 
Assembly definitions must never include:
* Coordinates (X, Y, Z)
* Absolute positions
* Offsets or dimensions
* Angles or rotations (except implicit via port orientation)
* Solids or sketches
* Boolean operations
* Manual placement decisions
 
Any of the above indicates a broken abstraction.
 
== Topology Is Sufficient ==
 
Given:
* Modules with known geometry and ports
* A graph of connections between ports
 
The assembly compiler can:
# Place a root module at origin
# Traverse the adjacency graph
# Align ports and propagate transforms
# Generate full building geometry deterministically
 
No additional information is required.
 
== Assembly Schema (Minimum Viable) ==
 
An assembly schema contains only:
 
* '''modules[]'''
   * module_id
   * module_id
   * host reference (stud_id / bay_id / distance-along-wall s)
   * module_type
  * level (z) reference (finish floor, top plate, etc.)
  * parameters
  * orientation (discrete or implicit)
  * level (optional)
 
* '''connections[]'''
  * module_A.port_X → module_B.port_Y
  * (optional) connection type: L / T / splice
 
This schema is human-readable and human-authored.
 
== Why Assembly Must Be Topological ==
 
Topology is:
* Stable under change
* Regenerable
* Deterministic
* Auditable
* Suitable for rule-based automation
 
Geometry is:
* Fragile
* Context-dependent
* Hard to regenerate
* Prone to manual drift
 
Assemblies must survive change.
Geometry does not.
 
== Consequences for Automation ==
 
When topology is explicit:
 
* Corners are known (L-connections)
* T-walls are known (mid-span connections)
* Splices are known (collinear connections)
 
Therefore:
* Blocking rules trigger from connection types
* Electrical boxes place along wall sequences
* Plumbing and wiring become graph routing problems
* Feature injection becomes deterministic
 
No geometric inference hacks are required.
 
== Assembly vs Post-Compilers ==
 
Assembly compiler responsibilities:
* Place modules
* Record adjacency
* Emit connection events
 
Assembly compiler must:
* Make no design decisions
* Inject no features
* Modify no modules
 
All construction logic occurs in '''post-compilers'''.
 
== Invariants (Non-Negotiable) ==
 
* Assemblies are declarative, not procedural
* Assemblies contain no geometry
* Geometry is always regenerated
* Manual edits are forbidden
* Every downstream artifact must trace back to topology
 
Violating any invariant breaks induction.
 
== Canonical Takeaway ==
'''Assembly defines relationships.'''
'''Compilers derive geometry.'''
'''Rules inject features.'''
 
This separation is what makes houses, machines, and infrastructure compilable.


=== 0.2 Module Interface Contract (Minimum) ===
Lock this canon before writing code.
Each module generator must publish:
* Ports: left_end, right_end, top, bottom
* Faces: interior, exterior, centerline
* Stud map: stud centerlines + IDs (queryable by distance along wall)
* No-go zones: openings, headers, shear zones, MEP prohibited zones
* Feature lanes: permissible regions for blocking + services


== 1. Generate Base Modules (Module Compilers) ==
=Example: Minimum Viable Schemas: Module → Assembly → Post-Process =
This stage produces clean, reusable modules with metadata. No building-level logic.


=== 1.1 Wall Modules ===
This page defines the smallest complete, induction-grade pipeline for compiling a house from modules.
* Inputs: width (nominal 4'), height (8–10'+), thickness, stud spacing, sheathing side(s)
The goal is clarity, determinism, and zero interpretation.
* Outputs:
  * Framing geometry (studs/plates)
  * Sheathing geometry
  * Tags: studs, plates, sheathing, cavity volumes
  * Ports/faces + stud map + lanes


=== 1.2 Door Modules ===
The rule:
* Inputs: rough opening width/height, door type, header rule, king/jack rules
Modules define geometry.
* Outputs:
Assembly defines topology.
  * Framing + header + cripples + tags
Post-process passes inject features.
  * Door opening volume (clearance/RO solid)
  * Ports/faces + stud map


=== 1.3 Window Modules ===
== 0) File Set (Minimum) ==
* Inputs: rough opening width/height, sill height, header rule
* Outputs:
  * Framing + header + sill + cripples + tags
  * Window opening volume (RO solid)
  * Ports/faces + stud map


== 2. Generate House Assembly (Assembly Compiler) ==
wall_module.yaml
Assembly schema contains ONLY:
assembly.yaml
* module instances (id, type, parameters, orientation)
postprocess.yaml
* connections (what connects to what)
artifacts/ (compiler outputs: CAD, BOM, features)


The assembly compiler:
== 1) Wall Module Schema (Minimum) ==
# Picks a root module and places it at origin.
 
# Walks the adjacency graph and places all modules by port alignment.
The wall module schema defines one wall module instance with local geometry and interfaces.
# Emits connection events (L-corner / T-intersection / splice).
It contains no building-level logic.
# Outputs the full placed assembly + adjacency graph.
 
wall_module.yaml
 
<syntaxhighlight lang="yaml">
module_type: wall_v1
module_id: W1
 
params:
  length_in: 48
  height_in: 120
  thickness_in: 5.5
  stud_spacing_in: 24
  end_stud: true
  plates:
    top: 2
    bottom: 1
 
ports:
  left_end:  {plane: "x=0"}
  right_end: {plane: "x=length"}
  interior_face: {plane: "y=0"}
  exterior_face: {plane: "y=thickness"}
 
metadata:
  stud_map:
    origin: left_end
    axis: x
    studs_at_in: [0, 24, 48]


=== 2.1 Assembly Schema (Topology Truth) ===
  lanes:
* modules[]:
    blocking_lane:
  * module_id, module_type, params, orientation, level
      y_range_in: [1.0, 4.5]
* connections[]:
      z_range_in: [0, 120]
  * A.port → B.port (and connection type if explicit)
</syntaxhighlight>


== 3. Post-Compiler Passes (Feature Injection + Routing) ==
Notes:
Each pass is deterministic and idempotent:
Ports are symbolic references.
* Re-running a pass must not duplicate features.
Stud locations may be explicitly listed or generated by the compiler.
* Each pass outputs "feature objects" + materialized CAD + BOM deltas.
Lanes define where post-process features are allowed to exist.


== Pass Order (Recommended MVP → Full Build) ==
== 2) Wall Module Compiler (Responsibilities) ==


== 4. Pass A — Interior Blocking (Framing & Drywall Backing) ==
The wall module compiler:
Purpose: Ensure fastening surfaces and required blocking exist based on assembly joints and finish requirements.
Reads wall_module.yaml
Generates framing solids (studs and plates)
Creates a local coordinate system
Defines named port planes
Tags studs and plates
Exports stud IDs and centerlines
Exports lanes and no-go zones


=== 4.1 A1: Corner Blocking (L-Corners) ===
Outputs:
Input facts:
Module CAD file
* Connection events of type L-corner
module_metadata.json
Actions:
bom.csv
* Add ladder blocking / corner backing per OSE standard
* Tag as blocking; add to BOM


=== 4.2 A2: T-Wall Drywall Backing (Partitions into Walls) ===
The wall compiler does not know anything about the house.
Input facts:
* Connection events of type T-intersection
Actions:
* Add backing members to host wall at partition line
* Maintain no-go zones (openings, headers, shear zones)


=== 4.3 A3: Drywall Seam Backing (Optional) ===
== 3) Assembly Schema (Topology Only) ==
Input facts:
* Drywall layout rule set (sheet size, seam strategy)
Actions:
* Compute seam lines; add backing where seams fall off-stud


== 5. Pass B — Rough Plumbing + Water Lines ==
The assembly schema declares what connects to what.
Purpose: Place plumbing fixtures and route drain/vent/water within allowed zones.
It contains no geometry.


=== 5.1 B1: Fixture Placement (Schema-Driven) ===
assembly.yaml
Place fixtures as feature objects with anchor references:
* Showers
* Toilets
* Bath cabinets/vanities
* Kitchen island cabinet
* Kitchen cabinets (runs)
Fixtures are placed relative to rooms/walls and reference planes.


=== 5.2 B2: Rough Drain/Waste/Vent (DWV) Routing ===
<syntaxhighlight lang="yaml">
Actions:
assembly_id: house_demo_01
* Create DWV route graph:
units: inches
  * fixture drains → main stack(s) → building drain
  * vent paths → roof/termination
* Emit:
  * pipe segments with diameters
  * slopes
  * penetrations (top/bottom plates, floors)
  * hanger points (optional)
* Validate:
  * slope feasibility
  * collision checks
  * no-go zones


=== 5.3 B3: Rough Water Lines (Hot/Cold) ===
modules:
Actions:
  - module_id: W1
* Route hot/cold from water heater/manifold to fixtures
    module_type: wall_v1
* Emit:
    params_ref: wall_module_W1.yaml
  * pipe segments
    orientation:
  * penetrations
      rotation_deg: 0
  * insulation requirements (optional)
      level: 0


== 6. Pass C — Bath Vent Fans + Ducts (Bath + Kitchen + Washer) ==
  - module_id: W2
Purpose: Place fans/hoods and route ducts to exterior terminations.
    module_type: wall_v1
    params_ref: wall_module_W2.yaml
    orientation:
      rotation_deg: 90
      level: 0


=== 6.1 C1: Device Placement ===
connections:
* Bath vent fans (per bathroom)
  - a: {module_id: W1, port: right_end}
* Kitchen hood (or recirc decision explicitly)
    b: {module_id: W2, port: left_end}
* Washer vent (dryer vent if applicable)
    connection_type: L_CORNER
</syntaxhighlight>


=== 6.2 C2: Duct Routing ===
wall_module_W2.yaml is identical to W1 except for module_id.
Actions:
* Route ducts through predefined duct lanes (top plate, soffit zone, service cavity)
* Emit:
  * duct sizes
  * elbows/lengths
  * penetrations (walls/roof)
  * termination caps locations
* Validate:
  * max equivalent length constraints (as defined by OSE rules)
  * clearance zones


== 7. Pass D — Electrical Boxes ==
== 4) Assembly Compiler (Responsibilities) ==
Purpose: Place all device boxes deterministically based on rules.


=== 7.1 D1: Room/Perimeter Inference (Minimum Viable) ===
The assembly compiler:
* Infer exterior wall loops and interior partitions
Loads module metadata
* Identify room boundaries (coarse is OK for MVP)
Places the first module at world origin
Traverses the connection graph
Aligns ports and propagates transforms
Places all modules deterministically


=== 7.2 D2: Receptacle Placement ===
The assembly compiler emits:
Actions:
Placed transforms per module
* Along each interior wall run, place receptacles by spacing rule
An assembly graph with connection events
* Avoid openings and no-go zones
A complete assembled CAD model
* Attach each box to a host wall stud bay + height ref


=== 7.3 D3: Switch Placement ===
Each connection event records:
Actions:
Connection type (L_CORNER, T, SPLICE)
* Place switches at doors per rule set
Participating module IDs and ports
* Place 3-way/4-way only if explicitly specified
World-space joint reference


=== 7.4 D4: Special Loads ===
The assembly compiler makes no design decisions and injects no features.
Actions:
* Add dedicated circuits/boxes for:
  * fridge
  * dishwasher
  * oven/range
  * microwave (if any)
  * washer
  * dryer
  * water heater(s)
* Place per appliance schema anchors


== 8. Pass E — Wiring + Drilling Plan ==
== 5) Post-Process Schema (Minimum) ==
Purpose: Route wires and generate stud drilling/hole schedules.


Actions:
The post-process schema defines ordered feature injection passes.
* Build wiring graph:
Each pass is deterministic and idempotent.
  * panel → devices → lights → fans → appliances
* Route in permissible zones:
  * top plate runs, service cavities, chase zones
* Emit:
  * cable runs and lengths
  * drill points per stud ID
  * nail plate requirements per rule set
* Validate:
  * prohibited zones
  * spacing/derating rules as defined by OSE canon


== 9. Pass F — Drywall System ==
postprocess.yaml
Purpose: Generate drywall layout and penetrations.


=== 9.1 F1: Drywall Sheet Layout (Optional MVP+) ===
<syntaxhighlight lang="yaml">
Actions:
postprocess_id: pp_demo_01
* Compute sheet placement and seams per strategy
* Emit:
  * sheet count
  * cut list
  * seam map
* Inject backing (if Pass A3 enabled)


=== 9.2 F2: Drywall Penetrations (Derived) ===
passes:
Inputs:
  - pass_id: corner_blocking_v1
* Plumbing penetrations
    type: feature_injection
* Vent duct penetrations
* Electrical boxes
Actions:
* Generate drywall cutouts (with tolerances)
* Emit:
  * penetration schedule by wall module
  * cut templates (optional)


== 10. Pass G — Finish Fixtures, Devices, and Cabinets ==
    triggers:
Purpose: Place finish components and final electrical components.
      - connection_type: L_CORNER


=== 10.1 G1: Showers / Toilets / Bath Cabinets ===
    feature: ladder_blocking
Actions:
* Place fixture solids and clearances
* Emit:
  * anchor points
  * mounting heights
  * fastener/backing requirements


=== 10.2 G2: Kitchen Cabinets + Island ===
    params:
Actions:
      block_member:
* Place cabinet runs and island modules
        size: "2x4"
* Inject required backing bands in walls (if not present)
      vertical_spacing_in: 16
* Emit:
      z_start_in: 16
  * cabinet BOM
      z_end_in: 96
  * layout drawings


=== 10.3 G3: Final Electrical (Devices + Covers + Lights) ===
    host_selection:
Actions:
      apply_to: [a, b]
* Place:
      lane: blocking_lane
  * receptacles/switches/covers
</syntaxhighlight>
  * light fixtures (ceiling)
  * bath fan grilles
* Output:
  * device schedule
  * lighting plan


== 11. Pass H — Appliances ==
== 6) Post-Process Compiler (Responsibilities) ==
Purpose: Place appliances and confirm services align.


Appliances to place:
The post-process compiler:
* Fridge
Loads assembly graph and transforms
* Washer
Finds trigger events
* Dishwasher
Computes local placement references per host module
* Dryer
Selects studs or bays using stud_map
* Oven/range
Creates feature objects
* Water heater(s)
Materializes features into CAD geometry


Actions:
Each feature object includes:
* Place appliance solids + clearances
Host module ID
* Validate:
Feature type
  * electrical box locations
Local placement reference
  * water hookups
Source connection ID
  * drain hookups
  * vent hookups (dryer/hood if applicable)


== 12. Pass I — Flooring ==
Idempotence rule:
Purpose: Generate flooring layout, cuts, and transitions.
Feature IDs are derived from (pass_id + connection_id + host_module_id + z_index).
Re-running the pass must not duplicate geometry.


Actions:
Outputs:
* Compute floor areas per room
Updated CAD assembly
* Emit:
features.json (audit trail)
  * flooring quantities
bom_delta.csv
  * cut layout (optional)
  * transition strips + underlayment schedule


== 13. Outputs (Every Run) ==
== 7) Concrete Example: Right-Angle Corner with Blocking ==
Each full compile produces:
* 3D CAD assembly
* Per-module fabrication drawings (framing/sheathing)
* Feature schedules:
  * blocking schedule
  * electrical device schedule
  * plumbing schedule
  * duct schedule
  * drywall penetration schedule
  * cabinet/appliance placement schedule
* BOM (base + deltas by pass)
* QA checklist per pass (validation report)


== 14. Validation Rules (Fail Loudly) ==
Inputs:
The pipeline must fail when:
Wall W1 oriented along +X
* A required feature cannot be placed without violating no-go zones
Wall W2 oriented along +Y
* A route cannot be found within permissible lanes
Connection type L_CORNER
* Intersections are inconsistent with topology
Post-process rule corner_blocking_v1
* Regeneration produces non-identical topology-derived outputs


== 15. Minimum Viable Release (MVR) ==
Result:
MVR includes:
The post-process compiler injects ladder blocking into W1 and W2 at the corner.
* Modules: wall, door, window
Blocking is placed only inside the declared blocking_lane.
* Assembly: topology placement
Blocking members are attached near the corner end studs.
* Pass A: interior blocking (L + T)
The BOM is updated with blocking lumber.
* Pass D: electrical box placement (basic)
The feature audit log records every injected block.
* Pass E: basic wiring routes + drilling plan (basic)
* Output: CAD + BOM + schedules


Everything else is incremental passes.
This completes a full minimum viable compile:
Module → Assembly → Post-Process


</nowiki>
All geometry is derived.
All logic is explicit.
All outputs are regenerable.

Latest revision as of 06:45, 24 January 2026

About

To automate full CAD of Seed Eco-Homes, we must translate the implicit knowledge of the Seed Eco-Home build system. This must be done not by gurus—bbut by clerks following specs.

Why? Because of this - [1]. In short: The real risk is not skill level of EAC programmers —it’s unconscious substitution. The danger is not incompetence. The danger is: “I know a better way to do this.”

Induction-Grade House Compiler Process (Modules → Assembly → Post-Compilers)

Canonical Principle

All downstream artifacts are generated from:

  1. Module Schemas (single-module truth)
  2. Assembly Schema (topology truth: what connects to what)
  3. Post-Compiler Passes (feature injection + routing + schedules)

No manual CAD edits. Every output must be regenerable from schemas.

Canonical Principle 2

  1. Schemas describe intent
  2. Assemblies describe relationships
  3. Compilers produce geometry

Assembly Canon: Topology, Not Geometry

Canonical Statement

Assembly is not geometry. Assembly is topology.

Assembly declares relationships. Geometry is a derived consequence.

If geometry is specified at the assembly level, automation fails. If topology is specified, geometry becomes compilable.

Definitions

Module

A module is a self-contained, parametric unit with:

  • Local coordinate system (CSYS)
  • Known dimensions
  • Named connection ports (left, right, top, bottom, etc.)
  • Published metadata (stud map, faces, no-go zones)

Modules contain geometry. Assemblies do not.

Assembly

An assembly is a connection graph consisting only of:

  • Module instances
  • Connections between module ports

An assembly answers:

  • What exists?
  • What connects to what?
  • Through which ports?

Nothing else.

What Assembly Explicitly Does NOT Contain

Assembly definitions must never include:

  • Coordinates (X, Y, Z)
  • Absolute positions
  • Offsets or dimensions
  • Angles or rotations (except implicit via port orientation)
  • Solids or sketches
  • Boolean operations
  • Manual placement decisions

Any of the above indicates a broken abstraction.

Topology Is Sufficient

Given:

  • Modules with known geometry and ports
  • A graph of connections between ports

The assembly compiler can:

  1. Place a root module at origin
  2. Traverse the adjacency graph
  3. Align ports and propagate transforms
  4. Generate full building geometry deterministically

No additional information is required.

Assembly Schema (Minimum Viable)

An assembly schema contains only:

  • modules[]
 * module_id
 * module_type
 * parameters
 * orientation (discrete or implicit)
 * level (optional)
  • connections[]
 * module_A.port_X → module_B.port_Y
 * (optional) connection type: L / T / splice

This schema is human-readable and human-authored.

Why Assembly Must Be Topological

Topology is:

  • Stable under change
  • Regenerable
  • Deterministic
  • Auditable
  • Suitable for rule-based automation

Geometry is:

  • Fragile
  • Context-dependent
  • Hard to regenerate
  • Prone to manual drift

Assemblies must survive change. Geometry does not.

Consequences for Automation

When topology is explicit:

  • Corners are known (L-connections)
  • T-walls are known (mid-span connections)
  • Splices are known (collinear connections)

Therefore:

  • Blocking rules trigger from connection types
  • Electrical boxes place along wall sequences
  • Plumbing and wiring become graph routing problems
  • Feature injection becomes deterministic

No geometric inference hacks are required.

Assembly vs Post-Compilers

Assembly compiler responsibilities:

  • Place modules
  • Record adjacency
  • Emit connection events

Assembly compiler must:

  • Make no design decisions
  • Inject no features
  • Modify no modules

All construction logic occurs in post-compilers.

Invariants (Non-Negotiable)

  • Assemblies are declarative, not procedural
  • Assemblies contain no geometry
  • Geometry is always regenerated
  • Manual edits are forbidden
  • Every downstream artifact must trace back to topology

Violating any invariant breaks induction.

Canonical Takeaway

Assembly defines relationships. Compilers derive geometry. Rules inject features.

This separation is what makes houses, machines, and infrastructure compilable.

Lock this canon before writing code.

Example: Minimum Viable Schemas: Module → Assembly → Post-Process

This page defines the smallest complete, induction-grade pipeline for compiling a house from modules. The goal is clarity, determinism, and zero interpretation.

The rule: Modules define geometry. Assembly defines topology. Post-process passes inject features.

0) File Set (Minimum)

wall_module.yaml assembly.yaml postprocess.yaml artifacts/ (compiler outputs: CAD, BOM, features)

1) Wall Module Schema (Minimum)

The wall module schema defines one wall module instance with local geometry and interfaces. It contains no building-level logic.

wall_module.yaml

<syntaxhighlight lang="yaml"> module_type: wall_v1 module_id: W1

params:

 length_in: 48
 height_in: 120
 thickness_in: 5.5
 stud_spacing_in: 24
 end_stud: true
 plates:
   top: 2
   bottom: 1

ports:

 left_end:  {plane: "x=0"}
 right_end: {plane: "x=length"}
 interior_face: {plane: "y=0"}
 exterior_face: {plane: "y=thickness"}

metadata:

 stud_map:
   origin: left_end
   axis: x
   studs_at_in: [0, 24, 48]
 lanes:
   blocking_lane:
     y_range_in: [1.0, 4.5]
     z_range_in: [0, 120]

</syntaxhighlight>

Notes: Ports are symbolic references. Stud locations may be explicitly listed or generated by the compiler. Lanes define where post-process features are allowed to exist.

2) Wall Module Compiler (Responsibilities)

The wall module compiler: Reads wall_module.yaml Generates framing solids (studs and plates) Creates a local coordinate system Defines named port planes Tags studs and plates Exports stud IDs and centerlines Exports lanes and no-go zones

Outputs: Module CAD file module_metadata.json bom.csv

The wall compiler does not know anything about the house.

3) Assembly Schema (Topology Only)

The assembly schema declares what connects to what. It contains no geometry.

assembly.yaml

<syntaxhighlight lang="yaml"> assembly_id: house_demo_01 units: inches

modules:

 - module_id: W1
   module_type: wall_v1
   params_ref: wall_module_W1.yaml
   orientation:
     rotation_deg: 0
     level: 0
 - module_id: W2
   module_type: wall_v1
   params_ref: wall_module_W2.yaml
   orientation:
     rotation_deg: 90
     level: 0

connections:

 - a: {module_id: W1, port: right_end}
   b: {module_id: W2, port: left_end}
   connection_type: L_CORNER

</syntaxhighlight>

wall_module_W2.yaml is identical to W1 except for module_id.

4) Assembly Compiler (Responsibilities)

The assembly compiler: Loads module metadata Places the first module at world origin Traverses the connection graph Aligns ports and propagates transforms Places all modules deterministically

The assembly compiler emits: Placed transforms per module An assembly graph with connection events A complete assembled CAD model

Each connection event records: Connection type (L_CORNER, T, SPLICE) Participating module IDs and ports World-space joint reference

The assembly compiler makes no design decisions and injects no features.

5) Post-Process Schema (Minimum)

The post-process schema defines ordered feature injection passes. Each pass is deterministic and idempotent.

postprocess.yaml

<syntaxhighlight lang="yaml"> postprocess_id: pp_demo_01

passes:

 - pass_id: corner_blocking_v1
   type: feature_injection
   triggers:
     - connection_type: L_CORNER
   feature: ladder_blocking
   params:
     block_member:
       size: "2x4"
     vertical_spacing_in: 16
     z_start_in: 16
     z_end_in: 96
   host_selection:
     apply_to: [a, b]
     lane: blocking_lane

</syntaxhighlight>

6) Post-Process Compiler (Responsibilities)

The post-process compiler: Loads assembly graph and transforms Finds trigger events Computes local placement references per host module Selects studs or bays using stud_map Creates feature objects Materializes features into CAD geometry

Each feature object includes: Host module ID Feature type Local placement reference Source connection ID

Idempotence rule: Feature IDs are derived from (pass_id + connection_id + host_module_id + z_index). Re-running the pass must not duplicate geometry.

Outputs: Updated CAD assembly features.json (audit trail) bom_delta.csv

7) Concrete Example: Right-Angle Corner with Blocking

Inputs: Wall W1 oriented along +X Wall W2 oriented along +Y Connection type L_CORNER Post-process rule corner_blocking_v1

Result: The post-process compiler injects ladder blocking into W1 and W2 at the corner. Blocking is placed only inside the declared blocking_lane. Blocking members are attached near the corner end studs. The BOM is updated with blocking lumber. The feature audit log records every injected block.

This completes a full minimum viable compile: Module → Assembly → Post-Process

All geometry is derived. All logic is explicit. All outputs are regenerable.