The physical world is now a layer you can add
The physical world is now a layer you can add
Behavioural-AI startup Godot Inc. is bringing infrared.city’s physical layer (the wind, heat, sun and shade of real streets) into its simulations, reachable through a single API call at interactive speed, instead of building and running climate simulation of its own.
Who this is for
Product and platform teams that need a real physical environment inside their software, without building or running a climate-simulation engine to get it:
- Digital twins and simulation platforms that want microclimate (wind, heat, sun and shade) as a ready data layer, not a research project.
- AI and agent products whose models need real conditions to reason about, not just a map.
- Design, planning, sport, events, safety and risk tools that need environmental realism on demand, per location and per hour.
A physical world for behavioural AI
Godot Inc., based near Kobe, builds behavioural AI: it simulates thousands of possible futures to show how a decision plays out across public health, communication and crisis management. Its work reaches the World Health Organization and the Government of Osaka. infrared.city runs the other side of the problem: the wind, sun, heat and shade of real streets, computed in seconds instead of the days a conventional study takes. Put the two together and a simulation stops describing a place. It starts describing an experience.
One layer was missing
A behavioural model can tell you how a crowd moves, where a runner tires, how a neighbourhood responds to a warning. What it cannot tell you, on its own, is what that crowd is actually feeling, because feeling is physical. A 32 °C afternoon in full sun on dark asphalt and the same afternoon under a row of trees are two different events to a human body, and only one of them is written on a thermometer.
That gap between air temperature and felt temperature is the whole of what infrared.city computes. Combine it with a model of how people behave, and each layer covers the other’s blind spot: the behavioural model gains a real environment to react to; the climate model gains the people it was always implicitly about.
A marathon you can feel before you run it
The first thing the two teams built together, with the sportswear company Asics, is a simulator for a marathon, with its first course a route through Kobe, Japan. A runner picks a pacing strategy; the model plays it back against that course, not just its distance and elevation, but its heat, its wind, its humidity and the moving line of shade the buildings throw across the road as the morning wears on.
The physical layer turns the route into a comfort profile, kilometre by kilometre. The exposed stretches (the wide boulevards with no canopy, the sun-facing embankments) read hot; the shaded, tree-lined segments read kind. Where a runner meets the hard part of the course stops being a guess and becomes something you can see on the map before the gun goes off.
Figure: One layer of the basis. The felt-temperature field the engine returns for a single scenario — computed once per condition, then looked up in place rather than re-solved on the day.
Read it the other way and it becomes an organiser’s tool. The same map that warns a runner also shows the race director which segments will need water, shade or a misting arch, and roughly how much relief each one buys. It puts the behavioural question (what will people do here) and the physical answer (what will it feel like here) on a single screen.
Figure: The sun layer of the same basis. How much of each kilometer runs in sun rather than shade, solved once and read off in place. Here, 91% of the route is in full sun.
What it takes to make a course queryable
For a behavioural model to try thousands of runner strategies, the physical answer has to come back at once, which rules out solving race-day weather on the spot. So Infrared City ran the simulations ahead of time and left behind something the behavioural layer could look up: a basis of physical conditions along the course, wide enough to cover whatever the morning turns out to be.
The Kobe course was broken into 136 points. At each one, the engine resolved three physical layers (thermal comfort, wind and shade) and swept each across the range a race morning can bring.
Thermal comfort · UTCI: 10 scenarios drawn from Kobe’s own weather in the 9–11h window: the three coldest mornings, the three hottest, and the 20th, 35th, 50th and 65th temperature percentiles. Each carries its own humidity, wind and solar radiation.
Wind speed · rose: 8 directions in 45° steps, north through north-west, at a unit reference speed, so any forecast wind can be matched to the nearest sector and scaled to strength.
Shadow · morning series: 15 min steps of the shadow mask across the race morning, capturing the moving shade the buildings throw over the road as the sun climbs.
| Bucket | Count | How it was chosen |
|---|---|---|
| Coldest | 3 | The three coldest mornings recorded in the race window |
| Hottest | 3 | The three hottest mornings |
| Mid-range | 4 | The 20th, 35th, 50th and 65th temperature percentiles |
Figure: The basis in motion. Playing back the course, the engine returns felt temperature (UTCI), wind and sun at each 100 m segment — every value looked up from the precomputed basis rather than solved on the day.
How a forecast becomes an answer. On race morning the live forecast (temperature, humidity, wind speed and direction) is matched to the nearest precomputed scenario: closest temperature first, then humidity, then wind for thermal comfort, and the nearest of the eight sectors for wind. The behavioural model then reads felt conditions at any of the 136 points, for any runner at any pace, with no new simulation to wait for. Every field is solved once, through the same engine, and served over the infrared.city API.
One engine, delivered as a layer
Figure: The route as a comfort profile. At pedestrian level the engine resolves felt temperature street by street — the exposed stretches read hot, the shaded ones read kind. The same read turns a course into a kilometre-by-kilometre comfort map, and a race day into a scenario a runner can rehearse.
The physical layer arrives as an API call. Infrared.city runs eleven microclimate models behind a single engine, and hands back the results other products build on: wind and pedestrian wind comfort, thermal comfort and its statistics, solar radiation, direct sun hours, daylight, sky view factor, and the ground materials that drive how a surface heats. Ask for a polygon; get back a grid.
Speed is what lets the physical layer sit inside an interactive product at all. A single conventional CFD solve takes hours to days to set up and run; here, a wind field returns in about a third of a second, pedestrian wind comfort in about four, and thermal comfort in under five. Fast enough that a behavioural model can call it in a loop, and a person can change the scene and watch the answer move.
That gap compounds across a project. The basis behind this marathon (ten thermal-comfort scenarios, an eight-direction wind rose and a morning of shadow steps, sampled along 136 points of the course) was stood up in weeks. Built the conventional way, where the wind rose alone is eight CFD runs at hours to days each, the same coverage would take months before the behavioural team had anything to query.
Weeks, not months. The whole physical basis was live and queryable in weeks, by calling an API rather than standing up and running a simulation pipeline. That is the difference between adding a layer and building one.
What it adds up to
A partnership that began with a hallway introduction in Osaka now ships a working product with a global sportswear brand: a marathon a runner can feel before the gun goes off. Neither company could have built it alone. The behavioural model needed a real world to act in, and the climate model needed the people it was always describing.
And the method travels. A course becomes a comfort profile the same way a district or a public space would: precompute the physical layer across the conditions that matter, then let the product that knows the people look it up. For any team already modelling how people behave, that is the smaller lesson: the physical world is now a layer you can add.
Add a climate intelligence layer to your product
Whether it starts as an idea or ships in a production platform, infrared.city gives whatever you build a real physical environment. One engine returns wind and pedestrian wind comfort, thermal comfort, solar radiation, direct sun hours, daylight, sky view factor, resolved at street scale and returned in seconds. It arrives as a single API and SDK you call, not a simulation stack you build and maintain.
- Start building: SDK and docs at infrared.city Platform — Urban Climate Analysis
- Talk to us about an integration: info@infrared.city
infrared.city: the climate intelligence layer for cities and buildings
