Design Automation

Design Automation for AEC

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 | | 1 | Parametric | Geometry driven by explicit parameters; designer controls inputs | Grasshopper slider controlling facade panel width | | 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)
• Site grading (optimization with soft constraints)

Low automation potential (human judgment critical):

• Architectural concept design (cultural, contextual)
• 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:

1. Define — Human sets objectives, constraints, preferences
2. Generate — System produces candidate solutions
3. Evaluate — System scores and ranks; human reviews
4. Select — Human chooses preferred direction
5. Refine — System develops selected option further
6. 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 = 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:

1. Matches rules against current facts (pattern matching)
2. Resolves conflicts when multiple rules fire (conflict resolution)
3. Executes the winning rule's action (assertion or modification)
4. 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.

Implementation options:

• Python: durable-rules, business-rules, custom engines
• Java/Kotlin: Drools (most mature open-source rule engine)
• .NET: NRules (for Revit add-in integration)
• Grasshopper: Conditional components, custom C# script nodes

2.4 Shape Grammars (Stiny)

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:

1. Priority ordering: Each rule has a numeric priority; highest fires first
2. Specificity: More specific rules override general rules (e.g., local code overrides IBC)
3. Recency: Rules matching recently modified facts fire first
4. Refraction: A rule does not fire twice on the same set of facts
5. Jurisdictional hierarchy: Federal > State > Local > Project-specific

2.7 Rule Libraries for AEC

| Domain | Rule Source | Key Rules | |--------|-----------|-----------| | Egress | IBC Chapter 10 | Occupant load factors, exit width, travel distance, common path | | Fire safety | IBC Chapter 7 | Fire resistance ratings, compartment sizes, opening protection | | Accessibility | ADA/ABA, EN 17210 | Clear widths, ramp grades, turning radii, reach ranges | | Structural | ASCE 7, Eurocode | Load combinations, deflection limits, drift limits | | Zoning | Local zoning code | Setbacks, height, FAR, lot coverage, parking ratios | | Energy | ASHRAE 90.1, IECC | Envelope U-values, WWR limits, HVAC efficiency | | Plumbing | IPC | Fixture counts by occupancy, pipe sizing |

---

3. Constraint Satisfaction Problems (CSP)

3.1 CSP Formalism

A CSP is defined by the triple (X, D, C):

• X = {X1, X2, ..., Xn}: set of variables
• 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

• Xi = (xi, yi, wi, 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

3.5 Constraint Propagation

Beyond arc consistency, stronger propagation techniques:

• Path consistency: Ensures consistency for triples of variables
• MAC (Maintaining Arc Consistency): Run AC-3 after each assignment
• Forward checking: Remove inconsistent values from neighbors of just-assigned variable

3.6 Soft vs. Hard Constraints

In real AEC problems, not all constraints are absolute:

Hard constraints (must satisfy):

• Building code requirements
• Structural limits
• Site boundary
• Non-overlap of rooms

Soft constraints (prefer to satisfy, with penalty for violation):

• Preferred adjacency (e.g., kitchen near dining)
• View orientation (e.g., living room faces south)
• Preferred aspect ratio
• Acoustic separation preferences

Soft constraints are handled by:

1. Weighted CSP: Each soft constraint has a weight; minimize total penalty
2. Optimization over feasible set: Find all hard-constraint-satisfying solutions, then rank by soft constraint satisfaction
3. Pareto frontier: When soft constraints conflict, find non-dominated solutions

3.7 CSP for Structural Grid

Variables: Grid line positions along X and Y axes Domains: Continuous within building boundary, discretized to module (e.g., 100mm) Constraints:

• Minimum span: 5.0m (functional space between columns)
• Maximum span: 12.0m (without transfer structures for typical concrete)
• Column-free zones: No columns in specified areas (auditorium, lobby)
• Edge alignment: Grid aligns with building perimeter
• Core alignment: Grid lines pass through core walls
• Regularity: Prefer uniform bay sizes (soft constraint)

---

4. Space Planning Algorithms

4.1 Adjacency-Based Layout

The classic space planning approach:

1. Adjacency matrix: Define required and desired adjacencies between rooms

         LIV  DIN  KIT  BED1 BED2 BATH ENT
Living    -    2    1    0    0    0    2
Dining    2    -    2    0    0    0    0
Kitchen   1    2    -    0    0    0    0
Bed 1     0    0    0    -    0    2    0
Bed 2     0    0    0    0    -    1    0
Bath      0    0    0    2    1    -    0
Entry     2    0    0    0    0    0    -

(0 = no relation, 1 = preferred, 2 = required)

1. Bubble diagram generation: Place rooms as circles/rectangles; connect required adjacencies with springs; use force-directed layout to minimize spring energy

1. 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
• Advantages: Naturally handles structural grid alignment
• 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  23m THEN high-rise structural system ELSE conventional framing.

**Iterative loop**: Repeat steps until convergence or max iterations.
Example: Adjust facade WWR → run energy simulation → check EUI target → if not met, adjust again.

**Fan-out/fan-in**: Generate N variants (fan-out) → evaluate all → select best (fan-in).
Example: Generate 100 floor plan options → score each → present top 10.

### 8.2 Workflow Engines for AEC

| Engine | Language | Strengths | AEC Use |
|--------|----------|-----------|---------|
| Grasshopper | Visual/C# | Visual, real-time preview, huge plugin ecosystem | Parametric geometry, environme

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [Amanbh997](https://github.com/Amanbh997)
- **Source:** [Amanbh997/Claude-skills-for-Computational-Designers](https://github.com/Amanbh997/Claude-skills-for-Computational-Designers)
- **License:** MIT

Install and usage instructions live in the source repository linked above.