## How Do Architects Discuss Design? Developed during an architecture hackathon, GIM is a prototype that supports early-stage architectural ideation. In GIM, each LLM-based architect persona reads project information—including the site, program, and design context—provided in natural language and develops an initial proposal. GIM uses a shared design representation to compare and revise proposals from multiple architect personas. Its units of representation were derived from the way architects explain early design ideas to one another.
## Spatial Relationships Conveyed by Massing Models Architects use massing models as shared references during the early stages of design. By pointing to individual volumes, they discuss program, spatial character, hierarchy, adjacency, voids, and connections, then review and revise the scheme together. The exchange centers on the characteristics of individual spaces and the relationships among them. Massing models present this information in three dimensions, while spatial diagrams present it schematically. Both communicate design intent by making spatial elements and their relationships legible.
## Spatial Relationships as a Graph A graph is a data structure that defines the characteristics of elements, connects them, and records the nature of each connection. Spaces can be represented as nodes, while their connections can be expressed as relations with direction, strength, and a rationale for placement. The information shared through massing models and spatial diagrams corresponds to this structure of nodes and relations. This correspondence shaped GIM into a system in which LLM-based architect personas discuss a design by composing and revising spatial graphs. The user reviews the graph through the corresponding massing model and spatial diagram.
## Three Principles of the Schema The spatial graph schema follows three principles that allow proposals from different personas to be compared on common terms and interpreted as 3D geometry. First, nodes are classified as Solid, Void, Core, or Connector. This type system provides consistent criteria for comparing proposals and applying modeling rules to each element. A Connector is a modeled element linking two spaces. A relation records the placement rule between nodes. Second, node scale and hierarchy, along with the strength of relations, are recorded as relative values. This preserves expressions commonly used during early design, such as “larger,” “a small space,” or “strongly connected,” before precise dimensions have been established. Personas revise these values as they adjust the spatial configuration during the discussion. Third, each node and relation records a narrative and the rationale behind the decision. These fields connect spatial decisions and design positions to the corresponding graph elements. They inform the design description and generated imagery. The structured node and relation data guide 3D mass resolution.
:::media-grid columns=1 - https://mecvnmjr5i5vmo1i.public.blob.vercel-storage.com/media/images/2026-08-10-ca014487-gim00.jpg :::
## Architect Forum Thirteen architect personas were defined using the design approaches and vocabularies of thirteen real architects as references. Each persona independently interprets the same project conditions, while the panel adjusts the spatial configuration and relations through three stages: proposal, cross-critique, and convergence. During convergence, each persona submits a complete design proposal, and Graph Builder integrates the responses into a single spatial graph. The results below present spatial graphs, 3D massing models, and generated images produced from different combinations of programs and personas.
:::media-grid columns=2 - https://mecvnmjr5i5vmo1i.public.blob.vercel-storage.com/media/images/2026-08-07-f4017519-11.jpg - https://mecvnmjr5i5vmo1i.public.blob.vercel-storage.com/media/images/2026-08-07-57d078d4-12.jpg ::: :::media-grid columns=2 - https://mecvnmjr5i5vmo1i.public.blob.vercel-storage.com/media/images/2026-08-07-ced22fe6-13.jpg - https://mecvnmjr5i5vmo1i.public.blob.vercel-storage.com/media/images/2026-08-07-3fcc5adf-14.jpg ::: :::media-grid columns=2 - https://mecvnmjr5i5vmo1i.public.blob.vercel-storage.com/media/images/2026-08-07-7f3ed115-15.jpg - https://mecvnmjr5i5vmo1i.public.blob.vercel-storage.com/media/images/2026-08-07-1566a654-16.jpg :::
--- (In the technical description below, “architect” refers to an LLM-based architect persona within GIM.)
## System Architecture The following workflow traces how a spatial graph is produced through a panel discussion and resolved into 3D massing.
### 1. From Architect Persona Responses to 3D Massing GIM structures the architect personas’ responses as a spatial graph, then resolves the graph through a fixed set of modeling rules. ```mermaid flowchart LR C["Project Conditions
Site · Program · Constraints"] F["Architect Persona Panel
Proposal · Critique · Convergence"] A["Structured Responses
ArchitectResponse[]"] G["Spatial Graph
SpatialMassGraph"] M["Resolved Mass
ResolvedMassModel"] V["3D Model
Visualization · Evaluation · Export"] C --> F F --> A A -->|"Graph Builder"| G G -->|"Mass Resolver"| M M --> V ``` The Forum Engine collects each architect persona’s judgment as a structured response. The Graph Builder integrates the spaces and relations from the converged responses into a single `SpatialMassGraph`. The Mass Resolver translates the graph’s relative scales and spatial relations into dimensions, positions, and geometric operations. The graph retains the design judgments, and the 3D geometry represents their resolved interpretation.
### 2. Proposal, Cross-Critique, and Convergence The same panel of architect personas develops a range of initial schemes into comparable final proposals over three rounds. ```mermaid flowchart LR P["Proposal
Independent Initial Design"] S1["Proposal Summary
Shared Context for the Panel"] C["Cross-Critique
Conflicts · Omissions · Relation Review"] S2["Revised Proposal Summary
Shared Context for Convergence"] V["Convergence
Consolidated Spaces and Relations"] R["Final Results
Converged Design Proposals"] P --> S1 S1 --> C C --> S2 S2 --> V V --> R ``` During Proposal, each architect persona interprets the same project conditions independently. During Cross-Critique, the complete set of proposals is shared with the panel to review redundant or missing spaces, ambiguous relations, and insufficient quantitative information. During Convergence, the panel identifies the spaces and relations to retain. Each round returns a revised, complete design proposal. Each round updates the design rationale and the complete candidate graph together.
### 2+. Structured Architect Persona Responses Each architect persona contributes an `ArchitectResponse` containing both its design rationale and a complete graph proposal. ```mermaid flowchart TB R["ArchitectResponse
One Structured Architect Persona Response"] I["Response Metadata
Architect Persona · Discussion Stage"] D["Design Rationale
Position · Reasoning · Critique · Revisions"] P["Design Proposal
Massing Concept · Spaces · Relations · Narrative"] F["Forum Engine
Response Collection and Round Coordination"] N["Context for the Next Round
Summary of Previous Responses"] B["Graph Builder
Integration of Converged Design Proposals"] G["Final Spatial Graph
SpatialMassGraph"] R --> I R --> D R --> P I --> F D --> F P --> F F -->|"Continue Discussion"| N F -->|"Discussion Complete"| B B --> G ``` The design rationale records the architect persona’s position and reasoning, its critique of other proposals, and the revisions it accepts. The design proposal contains the massing concept, structural strategy, complete set of spatial nodes and relations, and project narrative. The Forum Engine summarizes the design rationale and principal spatial relations for the next round. After Convergence, the Graph Builder compares the complete design proposals, integrates the agreed spaces and relations, and preserves the design rationale as the basis for those decisions. For example, the judgment that “the central atrium should serve as the focus of daylight and public circulation” is recorded in the design rationale. The design proposal in the same response contains an Atrium Void and its relation to the surrounding office mass. The architectural proposition and its modeling data remain connected within one response.
### 3. Spatial Graph: The Shared Source of Truth `SpatialMassGraph` is the structured source of truth shared by geometry generation, design descriptions, and evaluation. ```mermaid flowchart TB G["SpatialMassGraph
Shared Source of Truth"] P["Project Conditions
Site · Program · Goals · Constraints"] N["MassNode[]
Spatial Elements and Base Geometry"] R["MassRelation[]
Placement Rules between Spaces"] D["Narrative · Provenance
Design Intent and Decision Rationale"] M["Mass Resolver
Conditions · Nodes · Relations"] RM["ResolvedMassModel
Mass with Resolved Dimensions and Coordinates"] X["Design Description
Narrative and Image Direction"] E["Quantitative Evaluation
Project Goals and Resolved Results"] G --> P G --> N G --> R G --> D P --> M N --> M R --> M M --> RM D --> X P --> E RM --> E ``` Project conditions provide the external criteria that the graph must satisfy. Nodes and relations define which elements exist and how they should be arranged. Narrative and Provenance preserve the intent and discussion behind each decision. A change to the graph is reflected across the massing, design description, and evaluation. The geometry and its explanation refer to the same design state, making the graph the shared source of truth for both discussion and modeling.
### 3+. MassNode and MassRelation Schema `MassNode` and `MassRelation` form the core of the spatial graph. A node defines a spatial element, while a relation defines a rule that must be maintained between two spaces. ```mermaid flowchart TB N["MassNode
One Spatial Element"] NI["Identity and Role
id · kind · hierarchy · program"] NG["Base Geometry
primitive · scale · floors · area"] NV["Allowable Variation Range
proportion · size · height · angle"] NN["Design Intent and Provenance
narrative · architect_influences"] R["MassRelation
Rule between Two Spaces"] RI["Connection and Direction
source · target · rule · inverse_rule"] RP["Strength and Constraints
strength · weight · constraints"] RV["Allowable Distance Range
distance · lateral offset"] RE["Design Rationale
rationale · evidence"] N --> NI N --> NG N --> NV N --> NN R --> RI R --> RP R --> RV R --> RE R -->|"source · target"| N ``` The `kind` property of a `MassNode` classifies the element as Solid, Void, Core, or Connector. Its `geometry` contains quantitative information such as the base primitive, relative scale, number of floors, floor height, and target gross floor area. These values establish the mass’s base dimensions. `variant_space` defines the allowable adjustment ranges for proportion, size, height, distance, and angle. The Resolver prioritizes the base geometry and selects the values needed to satisfy the relations and project conditions within these ranges. The same graph and the same resolution rules produce the same values. The `source` and `target` properties of a `MassRelation` identify the two connected nodes and the direction of the relation. `rule` defines spatial meanings such as above, below, adjacent, contains, and connects. `inverse_rule` defines how the same relation is read from the opposite node. `strength` and `weight` determine the priority with which relations are applied. `constraints` carries required offsets and modeling effects such as connections and penetrations. `rationale` and `evidence` record why the relation was selected and which architect personas supported it. For example, when `office_mass` is defined as a Solid, `atrium_void` as a Void, and the two nodes are connected by a `contains` relation, the Resolver places the office mass around the atrium and subtracts the Void from the Solid. The relation retains the design judgment that the atrium organizes daylight and public circulation.
### 4. Deterministic Mass Resolution The Mass Resolver calculates dimensions from the quantitative information stored in each node, then determines positions and geometric operations through the relation rules. ```mermaid flowchart LR G["SpatialMassGraph
Spaces · Relations · Project Conditions"] D["Dimension Calculation
Floors · Floor Height · Area · Proportion"] L["Relational Placement
Reference Space · Direction · Offset"] O["Geometric Operations
Connector · Void"] C["Relation Check
Design Relations and Resolved Geometry"] M["ResolvedMassModel
Render-Ready Mass Data"] G --> D D --> L L --> O O --> C C --> M ``` During dimension calculation, the number of floors and floor height determine the overall height. The target gross floor area and number of floors determine the area per floor. The plan proportion distributes this area into width and depth. When quantitative information is incomplete, the Resolver uses the node’s relative scale and the default values assigned to each primitive. During placement, relations are interpreted relative to spaces that have already been positioned. The Resolver then assigns the length and rotation of each Connector, adds subtraction operations for Voids, and verifies that the final dimensions and positions satisfy the relations defined in the graph. `ResolvedMassModel` stores each mass’s primitive, dimensions, transform, envelope information, and Boolean operations. It also records the strategy applied to each relation and whether the resolved geometry satisfies it. > The same SpatialMassGraph + the same resolution rules = the same ResolvedMassModel
### 4+. Geometric Interpretation of Relation Rules The relation interpreter translates spatial language into coordinates, dimensions, and geometric operations. ```mermaid flowchart TB R["MassRelation
Directed Spatial Rule"] A["Placement Reference Selection
Reference Space for Relation Resolution"] I["Relation Direction Resolution
rule · inverse_rule"] F{"Relation Rule"} V["Above · Below · Sits On
Y Position and Vertical Offset"] P["Adjacent · Offset · Aligned
X/Z Distance and Rotation"] E["Contains · Encloses · Inside
Center and Extent Adjustment"] C["Connects · Bridge
Connector Length and Direction"] X["Penetrates · Void
Geometry Subtraction"] M["Mass Update
Dimensions · Transform · Boolean Operations"] Q["Relation Verification
Satisfaction Status and Resolution Record"] R --> A A --> I I --> F F --> V F --> P F --> E F --> C F --> X V --> M P --> M E --> M C --> M X --> M M --> Q ``` The Resolver first identifies an explicitly defined placement reference. When none is specified, it prioritizes relations with greater strength and weight. If the node being placed lies on the opposite side of the relation, the Resolver reads the direction through `inverse_rule`. Vertical relations calculate the Y position from the heights of the two masses and the required offset. Adjacent relations determine the plan distance from the mass widths and separation value. Containment relations adjust the centers and outer dimensions of both masses. A Connector is positioned at the midpoint between the two spaces; its length and rotation follow their distance and direction. For a `Podium contains Atrium Void` relation, the Atrium is placed inside the Podium, and the Podium is assigned dimensions that can contain it. Since the Atrium is a Void, a subtraction operation is added to the Podium. The Resolver then compares the dimensions and positions of the two spaces and records whether the resolved geometry satisfies the containment relation.
## Current Implementation and Scope of Evaluation The design approaches and vocabularies that inform the thirteen architect personas are defined in YAML. Using gpt-4.1 through the OpenAI Responses API, the Forum Engine runs the proposal, cross-critique, and convergence rounds. Resolved massing models are rendered in a Three.js viewer, variants are compared as snapshots, and models can be exported as OBJ and STL files. When a confirmed massing model is visualized with gpt-image-1.5, a Geometry Lock prompt instructs the model to preserve its geometry. Quantitative evaluation calculates the initial building coverage ratio and floor area ratio from the building footprint and gross floor area derived from the massing model. It also checks whether the required program areas have been met. The user assesses the architectural value of the design idea. GIM is currently being tested by a limited group of architecture students, with their use of and responses to the system under observation. GIM records spatial characteristics, relations, and decision rationales in a single graph, preserving early-stage design ideas in a form that can be reviewed and revised.