Integration from Module Schemas to Full Model
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:
- Module Schemas (single-module truth)
- Assembly Schema (topology truth: what connects to what)
- Post-Compiler Passes (feature injection + routing + schedules)
No manual CAD edits. Every output must be regenerable from schemas.
Canonical Principle 2
- Schemas describe intent
- Assemblies describe relationships
- 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:
- 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_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.