Before The Model: Aurora As AI-Grounded Climate Intelligence For Early-Stage Design
Interview with Damola Michael + Elliot Glassman – CannonDesign
For those who don’t know CannonDesign or the work behind Aurora, how would you describe the practice and what the two of you will be presenting at CDFAM DC?
Elliot:
CannonDesign is a global design firm that regards sustainability as a moral, ethical, and professional imperative, considering it a standard of care owed to clients, colleagues, and future generations. The firm focuses on delivering design solutions that advance innovation within the industry, operate at peak efficiency, and minimize environmental impact.
Cannon has a long history of engagement with sustainability. The Occidental Building completed in 1980 was an early example of an energy conscious design produced by the firm, featuring a double skinned facade. Since then, we have delivered 379 LEED certified buildings with another 50 on the way. We are amongst the first signatories to the AIA 2030 Commitment which targets a net-zero emissions portfolio by 2030.
Aurora was created through a collaboration between our Sustainability and Technology groups to provide a framework for shaping each project’s design approach through a climate responsive lens from its very inception. It automates much of the initial climate and site analysis to align the project team around the passive and active design priorities for environmental responsiveness early in the process.
We work on projects in so many different places around the world, and the best design approaches will vary based on the context. Aurora is meant to help teams quickly understand that context in terms of climate, utilities, and resiliency risks.
Aurora aims to move the environmental conversation to day one, before massing or geometry exists. What was happening in your projects that made the absence of that early climate picture a problem worth building a platform to solve?
Elliot:
Before joining CannonDesign, I spent nearly eleven years as a high-performance design consultant. That experience gave me the opportunity to collaborate with a wide range of design firms across the AEC industry and develop a broad perspective on how sustainability is or is not integrated into the design process.
Across the industry, there remains a persistent challenge in reconciling the scale of action needed to decarbonize the built environment with entrenched design and project management practices. Energy modeling and other building performance analyses are too often used to confirm performance after key decisions have been made, rather than as investigative tools that inform design with data from the outset.
As a result, by the time internal or external sustainability consultants are engaged, a project may already be substantially defined by other priorities. Consultants are then asked to improve the performance of a design that may already carry constraints or decisions working against energy efficiency, often introducing additional cost and complexity to rectify.
Rather than greening a building design, we want to empower teams in our firm to design a green building. This subtle shift in language carries significant implications: it moves the process from reactive triage to proactive design intent, positioning building performance as a driving concept rather than a downstream adjustment.
Aurora helps teams understand the climate and site conditions of a given location, along with the passive and active design strategies most likely to succeed there. By establishing this shared foundation at the beginning of a project, we aim to ensure that the first design concept is already informed by the environmental parameters that matter most.
The platform pulls together EPW files, CMIP6 projections, ASHRAE conditions, NOAA records, and seismic data into one environment. How do those sources get reconciled when they arrive in different formats and resolutions, and what does that pipeline look like behind the scenes?
Damola:
The reconciliation mechanism is simpler than the question implies. All five sources share a single common denominator: the WGS84 latitude/longitude coordinate set when a user pins their location. Every API call and file lookup receives that same coordinate pair. There is no cross-source join, no unified schema, and no resolution normalisation step. Each source is fetched and parsed independently in its own React context.
When you set a location, Aurora finds the nearest OneBuilding weather station, downloads a bundle containing the EPW, a .stat file, and a .ddy file, and extracts them into the browser’s local file system. The ASHRAE design conditions come out of that same bundle, pre-packaged by OneBuilding, so EPW and ASHRAE are already harmonised at source. CMIP6 projections come from the Open-Meteo API, returned as daily arrays and aggregated client-side to yearly summaries. NOAA monthly precipitation normals, USGS seismic data, and Electricity Maps carbon intensity are each fetched independently against the same coordinate.
The resolution gap between CMIP6’s roughly 100 km global grid and a point EPW observation is real and is not bridged. There is no interpolation. That is a known limitation and for early-stage design decisions it is rarely material, but it is worth naming honestly.
The backend is a thin proxy layer for CORS-blocked endpoints. All parsing and assembly happen in the browser.
The conversational layer is grounded in the actual EPW and CMIP6 data for the active site. How did you constrain Gemini to the site data, and how do you keep its explanations and generated charts faithful to what the files actually contain?
Damola:
The mechanism is prompt engineering, not a formal grounding architecture, and it is worth saying that clearly because the question deserves an honest answer.
When a user sends a message to the assistant, the app assembles a fullAppData object containing every computed value already displayed in the UI: the parsed EPW aggregations, the CMIP6 yearly deltas, the ASHRAE design conditions, the monthly rain totals, the wind rose data, the thermal comfort distribution. That object is serialised as JSON and appended to the user’s message before it is sent to Gemini. So the model does not go out and fetch anything, it receives a snapshot of the processed data that Aurora already has in memory for that session.
The system instruction does two things. First, it maps every field in that JSON to its physical meaning and unit, it tells Gemini that airProperties.monthlyMetrics[0].meanTemp is the mean dry bulb temperature for January in whichever unit the user has selected, and that if the unit is Imperial it needs to convert values that arrived as metric. Second, it defines a chart rendering protocol. When Gemini wants to show a chart, it emits a tag, [[RENDER_CHART:chart_id]] and Aurora’s frontend intercepts that tag and renders the corresponding chart from the live data. Gemini does not generate chart data; it references charts that already exist in the app.
The honest limitation: there is no programmatic verification step. If Gemini produces a number that contradicts the JSON it was given, the app does not catch that. The faithfulness constraint is entirely in the system prompt. In practice Gemini 2.5-Flash is reliable at staying within provided data when the JSON is well-structured and the instructions are explicit, but it is not architecturally guaranteed. What is guaranteed is that the charts it references are always rendered from the real data, so the visual outputs are always faithful even if an in-text number were ever wrong.
You have drawn a firm line that Aurora does not generate or evaluate geometry, positioning it ahead of tools like Forma rather than against them. How does that boundary hold up in practice, and what gets handed off when a team moves from Aurora into a geometry tool?
Damola:
The boundary holds because Aurora never takes geometry as an input and never produces it as an output. Every analysis module works purely from a coordinate and the data tied to it.
There is no surface, no room volume, no model file anywhere in the pipeline. That is not a product decision so much as an architectural one, the data sources Aurora aggregates do not require geometry, so geometry never enters the system.
The handoff in practice is a set of parameters, not a file. A team leaves an Aurora session knowing the peak solar months, the dominant wind direction and speed distribution, the ASHRAE climate zone and degree days, the comfortable outdoor hours, and the projected shifts in those conditions by 2050. They carry those into Forma or Rhino or Grasshopper as constraints. The massing they then create is already oriented correctly, already informed by which facade will carry the peak solar load, already aware of whether natural ventilation is viable and in which months.
The honest place where the boundary gets tested is passive solar geometry. If someone asks the assistant what overhang depth they need to shade a south-facing window in July, Aurora can give them the solar altitude angle, the peak irradiance hours, and the seasonal variation.
What it cannot do is evaluate whether a specific depth works against a specific geometry. That evaluation lives in Ladybug or Forma. Aurora supplies the parameters; the geometry tool tests them against a model. That division is clean and it is intentional.
The goal is not to replace the simulation step, it is to make sure the geometry that enters that simulation step was never designed blind.
What do you want this audience to take from your presentation, and what are you hoping to learn from the other work presented at CDFAM DC?
Elliot:
AI has tremendous potential as a tool for addressing real challenges in the built environment. One of those challenges is understanding the context of a project’s location in order to establish priorities and identify opportunities to advance building performance.
By automating climate and site analysis, Aurora frees designers to focus less on gathering and interpreting information from multiple sources and more on applying that insight to shape the building concept.
We are already pursuing, and planning, a wide range of initiatives to advance design and sustainability. At CDFAM DC, we are especially looking forward to seeing how others are approaching similar challenges, particularly from outside the AEC industry.
Exposure to that work may broaden our perspective, challenge our assumptions, and open new directions for how we think about AI, design, and environmental performance.
