CODEX: Climate-Responsive Design, Back at the Front of the Process

The book that projects itself

If you've seen Disney's Treasure Planet, you might remember how it opens. We're dropped into a sweeping scene of ships crossing an ocean of stars — and then the camera pulls back, and it turns out we weren't watching the world at all. We were watching a holographic projection rising off the pages of a storybook, read by a small boy in bed. The book is still the medium. The information still lives on the page. But the delivery has changed completely: the flat illustration has lifted into something dimensional, alive, and explorable.

That image is the whole idea behind CODEX, so I want to start there, before I say a word about climate.

The methods CODEX automates already exist, and they already live in a book — G.Z. Brown and Mark DeKay's Sun, Wind & Light: Architectural Design Strategies. They are not lost. They sit on the page, every bit as rigorous as they ever were, in the form of diagrams an architect is meant to draw by hand. CODEX invents none of them. It does to those diagrams what that opening shot does to the storybook: it lifts them off the page and makes them move.

How CODEX got its name

A codex is, literally, a book — a bound manuscript, the oldest format we have for carrying knowledge forward. That's the first layer: the suite is built on a book and treats that book as its source of truth. The second layer is the Treasure Planet image — the book whose contents project, alive, into the room. And the third is that the letters had to earn their keep: CODEX is the Climate-Oriented Design EXplorer. It explains the book, exploration, and climate all at once. 

How I actually use AI — and how I don't

I should be precise about what I mean by "AI," because the word does a lot of unhelpful work. I don't treat it as artificial intelligence in the Jarvis sense — an oracle you hand a problem and trust to hand back an answer. I treat it as augmented intelligence. It's a pair of glasses, not a replacement set of eyes; a crafting table and a very fast index, not a substitute for knowing what you're making. The expertise still has to be in the room. The model magnifies my domain knowledge; it does not supply it.

That distinction matters because of how these tools actually fail. Garbage in, garbage out isn't a slogan here, it's the operating principle: a vague instruction produces a confident, wrong result, and only someone who already understands solar geometry or psychrometrics can catch it. So the human's job doesn't disappear — it moves. It moves from writing every line to directing clearly and validating ruthlessly. The skill that matters is no longer syntax. It's clarity of thought.

It also matters where the resulting tools live. Everything in CODEX runs locally, in a browser, with no account, no subscription, and no cloud service deciding whether you're allowed to use it today. The model I have in mind is the kind of software we had before the cloud — tools you own, that run offline, that are simply there when you need them. That's a deliberate stance, not an accident of the build.

And one more thing I keep in front of me: automation never begins as a one-to-one replacement; it builds toward one over time, and its first dividend is always efficiency — recovered time. Which raises the question of where that recovered time should go. I'll come back to it at the end.

The context window, explained in floppy disks

It helps to understand what the model is actually holding while it works, because that shapes how you have to feed it. A model takes information in two ways: you can inject it directly into the conversation — paste it, upload it, type it — or it can reach into a larger store and pull back only the relevant pieces on demand, a method called retrieval-augmented generation, or RAG.

If you're old enough to remember floppy disks, the whole thing falls into place.

Memory versus storage. Big games used to ship on a stack of floppies, loaded one at a time, because the whole thing couldn't fit in the machine's memory at once. The model's context window is that memory — the RAM the entire performance runs inside — and RAG is the act of swapping floppies in and out, pulling in the disk it needs for the scene at hand. Everything the model is thinking with right now has to fit on the table; anything else has to be fetched.

Order and formatting matter. Feed those old floppies out of order — disk 3 before disk 2 — and the software couldn't find the sequential code it expected, so it crashed. The modern failure is quieter and more dangerous. Hand a model disjointed, out-of-order chunks and it doesn't crash; it loses the thread of the argument or the structure of the math and hallucinates instead. A confident wrong answer is worse than an error message, because nothing flashes red. This is the other half of why I direct so deliberately: the order and shape of what I hand it matter as much as the content.

Nothing is written to the permanent drive. Those games booted from a read-only disk; if you wanted to keep your progress you needed a separate save disk before powering down, or the memory was wiped clean. The model works the same way. Upload a document, it reads it, reasons over it, does real work with it — but close the browser or start a new chat and that working memory is flushed. It didn't learn your file; it held it in RAM for the length of the session and then let it go. "It forgot" isn't forgetfulness. It's a machine that never wrote anything to disk in the first place.

That last point is freeing once you internalize it. The model isn't quietly accumulating your project in a vault you can't see. Each session is a fresh stage that you set — which is exactly why setting the stage well, every time, is the skill that matters.

Directing, not coding: the theatrical script

Here's the mental model I used to build the whole suite, and it comes from theater, not software.

For most of computing history, a script meant the deterministic kind — a machine recipe. You tell the machine precisely which drawer to open, where to move, what to do in every if-then case. It's exact and it's powerful, but it's brittle: if anything shifts that the script didn't anticipate, it breaks, because the machine has no context with which to adapt.

A theatrical script is the opposite kind of instruction. A playwright and a director don't tell an actor how to move each finger. They set a scene, define a character, establish the constraints, imply the subtext — and the actor performs, improvising the specifics in real time while staying inside the bounds of the script. You don't tell the actor how to move their hands; you tell them the emotion to convey, and they find the motion.

Working with a capable AI model is directing the second kind of script. Strip the jargon off "prompt engineering" and it maps almost exactly onto a stage production:

• The character sheet — the dramatis personae. You begin by defining who the AI is for this task ("you are a building-science engineer fluent in solar geometry and the conventions of Sun, Wind & Light"). Naming the character shifts the model's internal weights toward the right expertise before it does anything else.
• The stage directions — the system prompt. You set the rules of the scene: the lighting and tone, the props that are available (the methodology, the source spreadsheet, the branding), and the places the actor may not go (no external libraries, no cloud calls, no invented data).
• The dialogue — your turn-by-turn input. You step onto the stage as the counter-actor. The AI isn't reading from a rigid teleprompter; it improvises its lines against the cues you give, scene by scene, while staying within the director's script.

That's the paradigm shift in one line: you are coding via intent, not commands. Traditional programming asked the developer to be the smartest entity in the room, mapping every logical edge case in advance. Directing asks something different, and something more recognizably architectural — the clarity to say what you want, and the judgment to know whether you got it.

One tool, directed into being

This isn't abstract, so let me show it on a single tool: the Sun Path Diagram, the first thing CODEX shipped. It's a four-beat production, and the beats are exactly the ones above.

Cast the character. The AI is set up as a building-science engineer who knows solar geometry and the stereographic sun-path convention from Sun, Wind & Light (Technique A2) — not a generalist, a specialist for this scene.

Set the stage. The rules: produce a single self-contained HTML file, zero external dependencies, University of Idaho branding, mobile-responsive — and the hand-built Excel sun-path workbook waiting in the wings as the source of truth. Those are the stage directions, and the actor doesn't get to leave them.

Run the scene. I directed by intent, not by code. I never wrote the trigonometry that turns a date and a latitude into altitude and azimuth, or the SVG path math that curves the hour lines across the chart. I gave cues — this curve reads wrong; the hour lines should splay like the textbook plate; group the Idaho cities by region — and let it perform the implementation, scene after scene, against those cues.

Strike and validate. Then the part that is non-negotiable: the performance gets checked against the source. The finished tool computes more than a thousand solar positions per diagram and validated to within 0.1° of the hand-built Excel prototype. Directing got it built fast; validation is what made it trustworthy. I told it the emotion to convey — a correct, readable sun path for any latitude — and it performed. My job was to direct and to QA, never to move its hands.

That's the method, and it's repeatable. Every tool in the suite was directed into being the same way.

The problem isn't the tools. It's when we reach for them.

Every energy modeler knows the feeling of being handed a building whose form is already locked. The orientation is set, the glazing ratio is fixed, the massing is final — and the model's job has quietly shrunk from shaping the building to rescuing it with mechanical systems. By the time the simulation runs, the decisions that mattered most for energy use have already been made. Sometimes they were made before the climate was looked at all.

That's not a software problem, and it isn't a failure of the model. It's a sequencing problem. The most consequential, cheapest-to-change moves — which way the building faces, where the glass wants to be, what the shading has to do, whether the site can be cooled by its own wind — all happen in schematic design, days or weeks before anyone opens an energy model. If climate doesn't get a vote at that table, no amount of downstream simulation can fully buy back what was lost.

Climate analysis used to happen at the front

There was a time when it did. Architects drew sun-path diagrams, plotted bioclimatic charts, laid out shading masks, and read wind roses by hand. The methods are collected and codified in Brown & DeKay's Sun, Wind & Light: Architectural Design Strategies — a rigorous, graphic body of technique for reading a site's climate and translating it directly into form. The bioclimatic chart traces back to the Olgyays; the sun-path and shading work to a century of solar geometry. These aren't soft heuristics. They're quantitative methods with a graphic output, designed to live in the same sketch-and-trace medium architects were already working in.

They didn't disappear because they were wrong. They disappeared because they were slow. Drafting a single stereographic sun path or a year's shading calendar by hand could eat an afternoon, and an afternoon per question is a luxury no schematic-design budget has ever had. There's a second, quieter reason too, and it's worth being honest about: the work underneath the graphics is trigonometry, and most architects would rather do almost anything than spreadsheet solar angles. The bottleneck was never just the hours — it was the hours and the math. Both have to be acknowledged, because a tool that solves only one of them doesn't actually change anyone's behavior.

So the graphic methods got shelved. Not refuted — abandoned, for being expensive in the one currency design never has enough of: time.

What CODEX is

CODEX — the Climate-Oriented Design Explorer — is an attempt to bring them back by removing the cost that buried them. It's a suite of climate-analysis tools that run entirely in a browser: no install, no license, no cloud account, no subscription. Each one just runs, locally, the moment you need it, without standing between you and your own work. CODEX applies that same posture to the front end of design, and builds the whole suite directly on the methods in Sun, Wind & Light.

Point it at an EPW file and it walks the same arc a designer would have walked by hand:

• Read the climate. Parse the weather file, then see the whole year at a glance — a climate carpet that maps temperature across every hour of every day, sky-cover patterns, and the raw shape of the site's conditions before any strategy is on the table.
• Understand the sun. Sun-path diagrams, a sundial/shadow simulator, solar-radiation analysis, a full-year shading calendar, daylight-availability studies, and daylight-obstruction analysis — the geometry that decides orientation, glazing, and shading, generated in seconds instead of an afternoon.
• Understand the wind. Wind roses and wind-square plots that show where the air comes from and when, so natural ventilation and site planning start from data rather than assumption.
• Test strategies against comfort. The bioclimatic chart plots the climate against the comfort zone and shows, hour by hour, which passive strategies the climate actually rewards — and how far each one gets you.
• Put numbers on it. A second layer carries the analysis into early quantitative territory: integrated energy analysis, CBECS-based load benchmarks, a thermal energy savings tabulator, a construction insulation-value calculator, and an infiltration-rate converter — the back-of-envelope checks that turn a strategy into a defensible early-design decision.

That's seventeen tools today, organized as a coherent early-design workflow rather than a pile of calculators, with two more — air movement and site microclimates — left as future work to round out the suite. The quantitative tools are validated against the published Sun, Wind & Light companion spreadsheets before they ship, so the numbers a tool returns match the source method, not an approximation of it. And because the lab is in Idaho, the suite ships with weather data for 21 Idaho locations across the state's five geographical regions — Treasure Valley, North Idaho, Southeast, Magic Valley, and the central mountains — so a practitioner here can start reading a real site immediately rather than hunting for a weather file first.

The CODEX suite, run against Boise — scroll to browse

The point of all this is not to automate judgment. CODEX doesn't decide anything. What it compacts is the gathering — the data wrangling and the trigonometry — that a designer would have to grind through regardless before they could even begin to reason about a site. The reasoning still belongs to the architect. The tool just hands them back the afternoon.

Where it sits next to the energy model

This matters for a room full of people who model buildings for a living, so let me be direct about it: CODEX is not an energy model, and it is not trying to be one. Simulation answers questions about performance — loads, comfort, consumption — with a precision graphic methods can't touch, and nothing here replaces that. The two tools answer different questions at different moments.

Simulation is at its most powerful when it's confirming and tuning a building that already responds to its climate. It's at its weakest when it's brought in late to compensate for one that doesn't — when the model becomes a search for the mechanical system that can rescue a form that was never going to perform. Every modeler has lived the second version of that job. CODEX lives upstream of it. It's the schematic-stage reading of sun, wind, and light that produces a climate-responsive form in the first place — which is exactly the thing that gives the energy model something worth optimizing instead of something to salvage.

Put plainly: graphic analysis shapes the building; simulation verifies and refines it. Neither is a substitute for the designer's judgment, and CODEX is no more a replacement for thinking than the model is. It's a way to get the climate into the conversation while the conversation can still change the building.

The afternoon we never got back

There's a longer arc worth naming, because it's the reason this is worth doing now and not just a nostalgia trip. Decades ago, simulation arrived with a promise: it would give designers their time back. Tasks that took weeks would take hours. In practice, the hours it saved were quietly reabsorbed — not into design, but into ever-rising performance standards. We didn't get the afternoon back. We spent it meeting the next code cycle, and the one after that. The efficiency went to the requirement, never to the architect.

CODEX is a small bet that some of that time can be returned to where it does the most good: the early decisions that are cheapest to get right and most expensive to fix. The methods were always sound. What changed is that browser automation can now do the rote drafting and the solar geometry that made them impractical — not by replacing the analyst, but by collapsing the cost that drove the analyst away. The graphic methods have been correct for forty years and impractical for thirty-nine of them. The thing that finally makes them practical isn't a new theory. It's the disappearance of the afternoon they used to demand.

Try it — or let's make a session of it

If you're a BSUG regular, you've already seen pieces of this lineage; the lab has shown climate design tools and weather-normalization work here before. CODEX pulls that thread as far as it goes: a full early-design climate workflow, free, browser-based, and grounded in published methods.

Try CODEX here. Bring a real project's EPW file and a site you're actually working on — that's when it earns its keep. And if there's appetite, this would make a good BSUG session: a live walkthrough of the suite against a real Idaho site, with plenty of room to argue about exactly where graphic analysis ends and the model should take over. That argument is the interesting part, and it's one this group is uniquely equipped to have.

This post is the short version. The full talk — the four-act arc, the history behind the methods, and the live demo — is available as a slide deck:

Download the talk — There and Back Again: A Tale of Energy Efficiency (PDF)