Design automation is the disciplined application of computational logic to replace, accelerate, or augment repetitive and rule-governed design tasks across architecture, engineering, and construction. This skill covers the full spectrum from simple parametric rules through constraint-satisfaction engines to fully generative layout systems, drawing automation pipelines, and automated code-compliance verification.
1. Design Automation Spectrum
1.1 Levels of Automation in AEC
Design automation exists on a continuum. Understanding where a task falls on this spectrum determines the appropriate technology and the degree of human oversight required.
| Level | Label | Description | Example |
|-------|-------|-------------|---------|
| 0 | Manual | Designer makes every decision, draws every line | Hand-drafted floor plans |
| 2 | Rule-Based | IF-THEN logic encodes design knowledge; system applies rules automatically | Auto-sizing exit widths based on occupant load |
| 3 | Constraint-Based | System searches solution space satisfying stated constraints | CSP solver placing rooms to satisfy adjacency + area constraints |
| 4 | Generative | System produces many candidate designs autonomously; human selects | GA-based floor plan generator producing 500 layout options |
| 5 | AI-Assisted | Machine-learned models propose designs or predict performance | GAN generating floor plan from adjacency graph |
| 6 | Autonomous | Fully closed-loop: sense conditions, generate design, validate, output | Automated site grading from survey to construction docs (emerging) |
1.2 What Can vs. Should Be Automated
High automation potential:
Code compliance checking (deterministic rules)
Structural member sizing (engineering formulas)
Parking layout optimization (geometric + count)
Sheet creation and annotation (repetitive)
Clash detection (spatial intersection)
Area and quantity takeoffs (data extraction)
Medium automation potential:
Space planning and room layout (heuristic + constraint)
Facade design (performance + aesthetic rules)
MEP routing (complex constraints, many valid solutions)
Urban massing and placemaking (experiential quality)
Material palette selection (aesthetic, tactile)
Client presentation and persuasion (social)
1.3 Human-in-the-Loop Design Automation
The most effective AEC automation systems keep designers in the loop at critical decision points:
Define — Human sets objectives, constraints, preferences
Generate — System produces candidate solutions
Evaluate — System scores and ranks; human reviews
Select — Human chooses preferred direction
Refine — System develops selected option further
Validate — Automated compliance checking; human sign-off
This cycle can repeat at multiple scales: master plan level, building level, floor level, room level.
1.4 The Role of Design Rules and Heuristics
Design rules encode domain expertise in computable form:
Hard rules: Must be satisfied (building code, structural limits). Violation = invalid design.
Soft rules: Should be satisfied (rules of thumb, best practices). Violation = penalty score.
Heuristics: Rules of thumb that usually produce good results but are not guaranteed optimal. Examples:
Office floor plate depth should not exceed 15m from core to window
Residential corridor length should not exceed 30m without a window
Parking bay angle of 90 degrees maximizes density; 60 degrees improves maneuverability
Structure grid spacing of 7.5-9.0m suits most office programs
2. Rule-Based Design Systems
2.1 Production Rules (IF-THEN)
The simplest and most widely used automation pattern in AEC:
IF occupant_load > 500
THEN required_exits >= 3
AND exit_width_total >= occupant_load * 5.0mm
IF room_type == "bathroom" AND floor_area < 4.0
THEN min_dimension >= 1.5m
AND door_swing == "outward"
IF building_height > 23m
THEN fire_resistance_rating >= 120min
AND sprinkler_system == required
Production rules are stored in a rule base and executed by a rule engine that:
Matches rules against current facts (pattern matching)
Resolves conflicts when multiple rules fire (conflict resolution)
Executes the winning rule's action (assertion or modification)
Repeats until no more rules fire (quiescence)
2.2 Decision Trees
Hierarchical rule structures where each node tests a condition and branches lead to sub-decisions:
Building Classification Decision Tree:
├── Occupancy > 300?
│ ├── YES → Assembly (A)
│ │ ├── Fixed seating? → A-1
│ │ ├── No fixed seating? → A-2
│ │ └── Worship? → A-3
│ └── NO → Business (B)
│ ├── Office? → B
│ └── Educational? → E
│ ├── Students > 12 yrs? → E
│ └── Students ≤ 12 yrs? → E (daycare)
Decision trees are valuable because they are transparent, auditable, and can be validated against code text.
2.3 Rule Engines
Production rule engines for AEC applications:
Forward chaining: Start from known facts, derive conclusions. Used for compliance checking. "Given this building, what rules are violated?"
Backward chaining: Start from goal, find supporting facts. Used for design guidance. "What do I need to achieve fire compliance?"
Rete algorithm: Efficient pattern matching for large rule sets. Maintains a network of partial matches; only re-evaluates affected rules when facts change.
Shape grammars define a set of shape rules that transform geometric configurations. Formally:
SG = (S, L, R, I)
where:
S = finite set of shapes
L = finite set of labels (markers, reference points)
R = finite set of shape rules: α → β (replace shape α with shape β)
I = initial shape
Shape grammar applications in AEC:
Palladian villa grammar (Stiny & Mitchell, 1978): Generates villa plans following Palladio's compositional logic
Prairie house grammar (Koning & Eizenberg, 1981): Encodes Frank Lloyd Wright's Prairie style
Musgum grammar: Encodes traditional Musgum shell house typology
Islamic geometric pattern grammars: Tile-based generation of complex ornamental patterns
Facade grammar: Generates facade variations from a vocabulary of elements (window, panel, mullion, spandrel)
2.5 Graph Grammars
Extend shape grammars to operate on graph structures (nodes + edges) rather than geometric shapes:
Nodes represent rooms, spaces, or building elements
Edges represent adjacency, access, containment, or structural relationships
Rules transform subgraphs: match a pattern, replace with a new pattern
Graph grammars are powerful for:
Floor plan generation from room adjacency programs
Building massing from spatial relationship diagrams
Urban block subdivision from land-use programs
2.6 Rule Priority and Conflict Resolution
When multiple rules apply simultaneously, conflict resolution strategies include:
Priority ordering: Each rule has a numeric priority; highest fires first
Specificity: More specific rules override general rules (e.g., local code overrides IBC)
Recency: Rules matching recently modified facts fire first
Refraction: A rule does not fire twice on the same set of facts
Jurisdictional hierarchy: Federal > State > Local > Project-specific
D = {D1, D2, ..., Dn}: set of domains (possible values for each variable)
C = {C1, C2, ..., Cm}: set of constraints (relations restricting variable assignments)
A solution is an assignment of values to all variables such that every constraint is satisfied.
3.2 CSP for Floor Plan Layout
Formulating floor plan layout as a CSP:
Variables: Room positions and dimensions
X_i = (x_i, y_i, w_i, h_i) for each room i
Domains:
Position: within building boundary
Width/height: within acceptable range for room type
Constraints:
Non-overlap: No two rooms share interior area
Boundary containment: All rooms within building envelope
Adjacency: Specified room pairs must share a wall segment of minimum length (door width)
Non-adjacency: Certain rooms must not be adjacent (e.g., bedroom not adjacent to mechanical)
Area: Room area within specified range (e.g., living room 20-35 m2)
Aspect ratio: Room width-to-depth ratio within range (e.g., 1:1 to 1:2)
Window access: Rooms requiring daylight must touch an exterior wall
Structural grid alignment: Room boundaries align with structural grid lines
3.3 Arc Consistency
Arc consistency (AC-3) prunes variable domains before search begins:
For every pair of constrained variables (Xi, Xj), remove values from Di that have no supporting value in Dj. Repeat until no more pruning occurs.
This dramatically reduces the search space. For AEC problems with continuous domains, discretize positions to a grid (e.g., 300mm module) to make the domain finite.
3.4 Backtracking Search
The standard algorithm for solving CSPs:
function BACKTRACK(assignment, csp):
if assignment is complete: return assignment
var = SELECT-UNASSIGNED-VARIABLE(csp)
for value in ORDER-DOMAIN-VALUES(var, assignment, csp):
if value is consistent with assignment:
add {var = value} to assignment
inferences = INFERENCE(csp, var, value)
if inferences != failure:
add inferences to assignment
result = BACKTRACK(assignment, csp)
if result != failure: return result
remove inferences and {var = value}
return failure
Key heuristics for AEC CSPs:
MRV (Minimum Remaining Values): Assign the room with fewest valid placements first (fail-early)
Degree heuristic: Assign the room with most adjacency constraints first
Least Constraining Value: Try placements that leave the most options for unassigned rooms
Bubble diagram generation: Place rooms as circles/rectangles; connect required adjacencies with springs; use force-directed layout to minimize spring energy
Graph-based placement: Represent adjacency as a planar graph; find a planar embedding; assign rooms to faces of the graph
4.2 Grid-Based Placement
Discretize the floor plate into a grid and assign rooms to grid cells:
Grid resolution: Typically 300mm, 600mm, or 1200mm module
Bin packing: Treat rooms as rectangles, floor plate as a bin; use heuristics (bottom-left, best-fit, shelf algorithms)
Integer programming: Assign binary variables x_{i,j,k} = 1 if room i occupies grid cell (j,k); add constraints for contiguity, adjacency, area
Disadvantages: Grid resolution limits design freedom; large grids = many variables
4.3 Force-Directed Layout
Model rooms as particles in a physics simulation:
Attractive forces: Between rooms that should be adjacent (spring force, F = k * delta)
Repulsive forces: Between all room pairs to prevent overlap (Coulomb-like, F = q / r^2)
Boundary forces: Repel rooms from floor plate boundary (containment)
Gravity: Pull rooms toward building center (compactness)
Damping: Reduce velocity each step to reach equilibrium (damping factor 0.8-0.95)
Algorithm:
1. Initialize room positions randomly within boundary
2. For each timestep:
a. Calculate all forces on each room
b. Update velocities: v += F * dt / mass
c. Apply damping: v *= damping_factor
d. Update positions: p += v * dt
e. Resolve overlaps (push apart along shortest separating axis)
f. Enforce boundary containment
3. Stop when total kinetic energy < threshold
Force-directed layout produces organic, relationship-driven arrangements but rarely produces rectangular room boundaries without post-processing.
4.4 Evolutionary Layout (GA-Based Floor Plan Generation)
Genetic algorithm approach:
Genome encoding:
Sequence of room placements: [(room_id, x, y, w, h, rotation), ...]
Or: slicing floorplan tree (horizontal/vertical cuts + room assignment)
Automated residential layout follows a hierarchical process:
Unit boundary definition: From structural grid and building envelope
Zone identification: Public zone (living, dining, kitchen), private zone (bedrooms, bathrooms), service zone (laundry, storage), circulation (entry, corridors)
Room placement priority order:
Entry (fixed by corridor access point)
Kitchen (plumbing riser location)
Bathrooms (plumbing riser location)
Living room (largest contiguous window wall)
Bedrooms (remaining window walls)
Storage/utility (interior, no window needed)
Circulation routing: Entry to all rooms with minimum corridor
Window assignment: Each habitable room gets exterior wall contact
Door/window tags: Auto-tag with mark number, type, size
Keynoting: Auto-keynote materials by element type; generate keynote legend
Leader and callout placement: Avoid overlaps using collision detection; route leaders to clear space
Coordination: Ensure annotation does not overlap with drawing content
6.5 Sheet Layout Optimization
View-to-sheet assignment: Assign views to sheets based on drawing set organization (plans on A-series, sections on A-series, details on A-series sub-sheets)
View placement: Optimize view positions on sheets to minimize white space
Title block: Auto-populate project info, sheet number, revision history
Sheet numbering: Follow standard conventions (A1.01, A2.01, S1.01, etc.)
Total_exit_width = Occupant_load * width_factor
Stairways: 7.6 mm/person (sprinklered), 5.1 mm/person (unsprinklered) [IBC]
Other egress: 5.0 mm/person (sprinklered), 3.8 mm/person (unsprinklered) [IBC]
Minimum single exit width: 810 mm (door), 1120 mm (corridor)
Travel distance (IBC Table 1017.2):
Business, sprinklered: 90m (300 ft)
Residential, sprinklered: 75m (250 ft)
Assembly, sprinklered: 75m (250 ft)
High hazard: 23m (75 ft)
Common path of egress travel: Maximum distance before two separate paths to exits are available. Typically 23m (75 ft).
7.2 Fire Safety Automation
Compartmentation: Maximum compartment area by construction type (IBC Table 506.2). Auto-check that fire walls divide building into compliant compartments.
Fire resistance rating: By construction type and element (IBC Table 601). Auto-assign to wall, floor, and roof assemblies.
Sprinkler coverage: Maximum coverage area per sprinkler head (standard 12.1 m2, light hazard). Auto-generate sprinkler layout.
Fire separation distance: Distance from building face to property line or adjacent building. Determines allowable opening percentage.
Store Grasshopper definitions in Git (.gh files are binary; use .ghx XML format for diffing)
Dynamo graphs: .dyn files are JSON; store in Git with meaningful commit messages
Python scripts: Standard Git workflow with branching, code review
Rule libraries: Version rule sets independently from code; track code edition and amendment dates
Template libraries: Version parametric detail templates with semantic versioning
9. Design Automation Case Studies
9.1 Automated Facade Design
Pipeline: Solar analysis → shading device sizing → panel generation → fabrication data
Solar analysis: Run annual solar radiation simulation on facade surfaces (Ladybug/Honeybee or custom raytracing). Output: radiation map (kWh/m2/yr) per facade cell.
Shading device sizing: For each cell, calculate required shading depth based on radiation and orientation:
shade_depth = window_height * tan(critical_sun_angle) * shading_factor
critical_sun_angle = solar altitude at cooling design day peak
Panel generation: Generate facade panel geometry with sized shading devices. Apply panel types from a limited palette (e.g., 4-5 fin depths) for constructability.
Structural check: Verify fin depth/projection within structural capacity of facade framing.
Fabrication data: Export panel schedule with dimensions, material, finish. Generate CNC cutting files for custom panels. Output IFC model for coordination.
Result: 3000 unique panels documented in 2 hours instead of 2 weeks.
9.2 Automated Parking Garage
Pipeline: Site boundary → ramp placement → bay layout → structural grid → count verification
Pipeline: Unit type library → floor plate stacking → core placement → code checking
Unit type library: Pre-designed unit types with variants:
Studio (28-35 m2): 3 variants
1-bed (45-60 m2): 4 variants
2-bed (70-90 m2): 5 variants
3-bed (95-120 m2): 3 variants
Penthouse (150-250 m2): 2 variants
Floor plate definition: Building footprint from massing model; structural grid
Core placement: Position cores (elevator, stairs, shafts) considering structural, egress, and efficiency requirements
Unit arrangement: Pack unit types into floor plate around core; maximize units per floor; ensure all units have exterior windows; check corridor length
Stacking: Assign unit types to floors; align wet walls vertically; vary unit mix by floor level
Code checking: Run automated egress, fire safety, accessibility, and daylight compliance checks
Output: Typical floor plans, unit mix schedule, area tabulation, compliance report
Topographic input: Point cloud or contour data → TIN surface
Design constraints: Building pad elevation, access road grades (max 8%), parking areas (max 5%), ADA paths (max 5%), minimum drainage slope (1%)
Cut/fill optimization: Linear programming to balance cut and fill volumes (minimize import/export). Variables: finished grade elevations at grid points. Constraints: max/min grades, building pad, road connections.
Drainage design: Identify watersheds on finished grade; route overland flow to retention areas; size drainage infrastructure
Retaining walls: Where grade change between adjacent areas exceeds safe slope (typically 1:3 or 1:2), insert retaining wall. Size wall by height and soil conditions.
Output: Grading plan with spot elevations, cut/fill quantity table, drainage plan, retaining wall schedule
Route generation: A* pathfinding on 3D grid from AHU to terminal units. Cost function includes: path length, number of bends (fittings), vertical elevation changes, proximity to structure (hanger points).