Before changing the skyline, keep the assumptions
Move a building. Change a source. Can you still explain the result? Urban Air Studio keeps site-design experiments traceable, using Cedar for source permissions and Strands Agents for a local assistant that must show its evidence.
Data Science @ DTU | Learning & Building
Before changing the skyline, keep the assumptions
Imagine moving one building on a site plan. The wind still has to go somewhere, people still have to walk past the site, and the air study still depends on the same sources and assumptions. Yet a quick design experiment can quietly turn into a different question if nobody remembers what changed.
That bookkeeping is where Urban Air Studio starts. We built it for campus and site planners exploring design choices while keeping the reasoning attached. The goal is to ask, “What if we changed this?” and see which inputs and permissions shaped the answer.
One change, one traceable comparison
Here is a representative workflow. A planner selects a site, reviews its building geometry and any missing heights, then freezes a baseline. They make a separate alternative—perhaps shifting a building or adjusting a source—and run a bounded local research preview. The app compares compatible runs and can export a draft report that carries the source permissions and input history along with it.
That example describes a workflow, not a measured result: the demo uses a fictional site, and we do not claim a layout reduced pollution. A reviewer can follow what changed and what stayed fixed before interpreting a comparison. Outputs are research diagnostics, not validated Delhi air-quality forecasts or proof of environmental improvement.
The product is a map-first workbench with a React and TypeScript client, FastAPI backend, scoped records, and local workers. See the live site and public source . The map can show OpenStreetMap and GFS context, though hosted provider availability can vary. The workflow preserves assumptions when outside context is incomplete.
Cedar makes permission part of the workflow
The AWS connection in this build is Cedar, AWS’s open-source policy language and engine. We run it locally through the community-maintained
cedarpy binding. Before the backend derives, solves, or exports scoped source records and their frozen dependencies, Cedar evaluates whether that action is allowed.This is a working control, not a diagram in a slide deck: a permitted request receives an Allow decision and HTTP 200; an attempt to export a restricted source receives a Deny decision and HTTP 403, with policy evidence. The application fails closed when required authorization details are missing or inconsistent. That gives the team a concrete way to inspect why a source can be used in a study and why it cannot be carried into a report.
Cedar answers an authorization question. It does not decide whether a plume model is sound, source data are representative, or a design is safe. A valid permission check is necessary for responsible data use, but it cannot replace scientific validation.
A local agent that has to show its work
We also integrated Strands Agents SDK with a local Ollama model. The model can select from scoped application tools for tasks such as geometry inspection, reviewed proposals, and retrieving exact comparison evidence. It does not get an unrestricted shell, arbitrary web access, or a free hand in the database.
In the measured task set, the tool-selection run completed 12 tasks: eight were accepted and four were blocked. That is useful evidence about the current boundaries, not a claim that every request works. A selected tool is only the start; the application still has to check the returned evidence, its type, and its scope before presenting it. We want a blocked or unsupported request to be visible, rather than dressed up as a confident answer.
What we learned building it
Cedar’s explicit actions made source-use rules easier to review and test. The rough edge was Python integration: the community binding means we had to pay attention to compatible runtime versions, schema assembly, and provenance. Strands made it practical to expose a few useful capabilities to a local model, while also reminding us that tool use does not establish factual or scientific correctness. We still need strong evidence checks and clear handling when an answer cannot be supported.
The current public app runs on Render’s free tier. Supabase persistence has not been verified, so the current SQLite setup should not be treated as durable storage with a guaranteed 24/7 service level. We did not deploy AWS-managed infrastructure or use Bedrock, S3, Cognito, or Amazon Verified Permissions. Cedar is the AWS-origin open-source component we actually run. Gemini REST support was added as an optional cloud assistant path, but successful Gemini inference has not yet been verified; it is separate from the local Strands path.
AI tools assisted development, including OpenAI Codex/ChatGPT and Gemini through Antigravity. The implementation and tests remain subject to human review, and we credit the libraries and licenses in the public repository. Urban Air Studio is a PhoenixFires project for the Air track; the site fixture and workflow example here are illustrative, and no individual contribution or user quote is implied.
The question is practical: if a site changes, what exactly changed in the study? Keeping that answer traceable is a useful first step toward better environmental decisions—and more honest than claiming a dashboard fixed the skyline.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article