Building a Wildfire and Landslide Digital Twin by Conversation

Detailed edition · Overview edition

Sushil J. Louis, Director, Evolutionary Computing Systems Lab; Professor, Department of Computer Science and Engineering, University of Nevada, Reno, working with Claude (Anthropic), an AI coding agent, in Claude Code.

This playbook, like the software it describes, was written by an AI agent under the direction of the author. Nothing in it has been reviewed by fire scientists, hydrologists or geotechnical engineers. It describes a research prototype, not a tool for operational decisions.

Contents

1. Abstract

RenoTwin is an interactive 3D digital twin of a 51 × 113 km region around Reno, Nevada, for studying wildfire spread and post-fire debris flows on a desktop or a Meta Quest 3 headset. The first version, which simulated the 2026 Hawk Fire on Peavine Peak, took about one day. It went from a single prompt to real terrain from USGS elevation data, the fire's mapped perimeter, burn severity from satellite imagery, and a Rothermel surface fire spread model over LANDFIRE fuels. After calibrating one spread factor, the simulated fire fills the mapped perimeter in the real 106 hours. The rest was added intermittently over the following three weeks, as time allowed:

The human wrote 51 prompts and no code. The agent wrote the Python data pipeline, the Unity 6 application, the shaders, and the tools for testing without opening Unity. This playbook records how the conversation steered the work: what the human had to know, what the agent could and could not do, where it was wrong, and how those errors were caught. It also lists the parts that fire scientists, hydrologists and geotechnical engineers would need to verify before anyone relied on the results. No domain expert has reviewed this work.

2. How to read this

Section 3 is the whole conversation, in order, grouped by topic. Each prompt appears with a heading and a line of metadata:

Then come the prompt, verbatim, including its typos; a condensed account of what the agent did, quoting it where the wording matters; and, where it helps, how this steered the work: which of the human's knowledge, the agent's capabilities, scripting or software-engineering practice the step depended on. Boxes marked Needs expert review flag results a domain scientist would have to check. Screenshots are the agent's own renders, taken to check its work.

A few terms recur:

3. The conversation

3.1 Scoping, the plan and the project skeleton (prompts 1–4)

Prompt 1 · Sat 5 Sep 2026, 18:10 PDT

Model: Fable 5.1 · agent time: 1 min · 1 tool call

I want a 3D simulation of the city of Reno and the surrounding area. From the California border in the west on I80, to Lockwood in the east and from Cold Springs in the North to Gardnerville in the south. My purpose is to create a 3D model that can model the spread of fires and after a fire is handled, model the probabilities of landslides and other phenomena due to snow and rain. I want an interactive digital twin of the area where I can control precipitation and other parameters, the change in surface properties caused by the fire, and then actually "see" a landslide occur when I do what-if scenario analysis. I want to produce a showcase that has good underlying science and is also very highly visually impactful, especially if I am using a VR headset like the quest, and am standing in the middle of an area about to be overrun by flames or am going to be impacted by a landslide. I am most familiar with Unity. First, ask enough to scope the project. Then, let's build a simple playable prototype where I can fly around the world and look around the area. Then I'd like to simulate the recent Hawk and Bug fires on Peavine mountain, so I can get before and after (burnt) mountain surfaces, and then change model parameters so I can get a landslide to ascertain which areas will be most affected. Be terse. Plan first, get plan approved, then go step by step to build features. I plan to hand off features to Opus or Sonnet, so for each step of the plan, tell me which I should use.

What the agent did. It read its saved notes from an earlier Unity project on the same machine (graphics card, installed Unity versions, its own tools for testing Unity without a window) and replied with eight scoping questions, each with a recommendation so the human could answer in one word. The full reply is in the overview edition.

How this steered the work. The prompt fixed everything that mattered for the next three weeks: the study area, the purpose, the audience, the platform, and a way of working (plan first, get approval, build step by step). The human's familiarity with Unity chose the engine. The request to name a model for each step came from the human's plan to hand the work between models.

Prompt 2 · Sat 5 Sep 2026, 18:15 PDT

Model: Fable 5.1 · agent time: 2 min · 5 tool calls

defaults on all, pull perimeters from NIFC, use 6000.5.9f1

What the agent did. It searched the web for both fires, confirmed Unity 6000.5.9f1 was installed and that Python lacked the geospatial libraries it would need, and wrote PLAN.md: eight phases (0 to 7), each with a "done when" test and a recommended model. It chose NAD83 / UTM zone 11N coordinates with one Unity unit per metre, and extended the study area north so the Bug Fire would not be cut off. It reported what it found: the Hawk Fire, ignited 22 August 2026, about 15,000 acres on Peavine; the Bug Fire, ignited 8 August, merged with the Fred Mountain Fire, about 94,000 acres; and that official burn-severity maps would not exist yet, so it would compute its own from Sentinel-2 imagery.

Prompt 3 · Sat 5 Sep 2026, 18:18 PDT

No reply: the human interrupted six seconds later.

Approved.

The interruption was to add a requirement:

Prompt 4 · Sat 5 Sep 2026, 18:20 PDT

Model: Fable 5.1 · agent time: 15 min · 37 tool calls

Wait, can we have a toggle to flip between a 3 monitor desktop and a meta quest 3?

What the agent did. It explained how a runtime toggle would work (one camera per monitor with the side cameras turned to match the monitor angle, or the Quest over Link), including a Unity limitation: it can switch a monitor on but never off. It added the toggle to the plan and then, since the plan was approved, built Phase 0: a Unity 6 project using the Universal Render Pipeline and OpenXR, the display toggle on F12, and three shell scripts to compile-check the code in two seconds, run editor functions without a window, and render screenshots headlessly. It verified the three-camera layout by rendering the three views side by side and checking that the horizon ran straight across the seams. It stated what it could not verify: an actual Quest session.

The first headless render of the three-monitor rig: three camera views side by side over a placeholder ground plane

Phase 0: the three-monitor rig, checked without three monitors.

How this steered the work. The testing tools built here were used for the rest of the project, and much of what follows is about where they fell short.

3.2 Terrain and the playable prototype (prompts 5–8)

Prompt 5 · Sat 5 Sep 2026, 23:41 PDT

Model: Opus 5 · agent time: 33 min · 57 tool calls

go, I am using Opus

What the agent did. Phase 1, the data pipeline: Python that pulls USGS 3DEP elevation and NAIP aerial imagery and writes 71 Unity terrain tiles (768 MB). It checked the result against an independent fact: the 1 m lidar puts Peavine's summit at 2520.8 m, against a published 8,266 ft (2,519 m). That check also caught that its own coordinate for the peak was 686 m off.

Two problems it found and fixed are typical of working with real services. Tiles fetched separately disagreed at their seams by up to 10.4 m, because 3DEP stitches several lidar surveys and picks between them per request; it now fetches overlapping blocks and cuts tiles from them, which makes the seams agree by construction. And the service advertises an 8,000-pixel request limit but fails above about 2,048.

Shaded relief of the whole study area reassembled from the tiles on disk

The quality-check image: every tile reassembled from disk.

How this steered the work. "Go, I am using Opus" was the human switching models by hand, as the plan had suggested. From here most of the work is Opus 5.

Prompt 6 · Sun 6 Sep 2026, 07:36 PDT

Model: Opus 5 · agent time: 47 min · 106 tool calls

Go with phase 2. I want to run it in developer mode on one display in the unity editor. Then make an executable and run on three displays

What the agent did. Phase 2: 67 terrain tiles covering 51 × 113 km, a sky, a sun, and a fly camera whose speed scales with height above the ground. It built the player and launched it on the human's three monitors. It changed one decision on the way: having pulled the real Hawk perimeter, it found a peak-centred 1 m inset would cut off the north and east of the burn, so it covered the whole burn at 2.5 m instead. It fixed three bugs that compile cleanly and only fail when run, including Unity's overloaded null check, which the C# ?? operator bypasses. It also found that Windows numbers monitors in an order that has nothing to do with where they sit (on this desk left, centre and right were displays 1, 0 and 3), so it made the player print a table of displays and accept a mapping at launch.

The first flight over the Reno basin

The playable prototype, about 14 hours after the first prompt.

Prompt 7 · Sun 6 Sep 2026, 11:01 PDT

Model: Opus 5 · agent time: under a minute · 0 tool calls

Claude rc

What the agent did. Asked what "rc" meant rather than guessing.

Prompt 8 · Sun 6 Sep 2026, 11:06 PDT

Model: Opus 5 · agent time: 2 min · 2 tool calls

how do I connect this session to my claude app on my phone

What the agent did. Consulted Claude Code's documentation through a helper agent and explained Remote Control: how to start it, what it requires, and that everything keeps running on the desktop while the phone becomes a second screen.

How this steered the work. A housekeeping exchange, kept because it is typical: the human was about to leave the desk and wanted to keep steering from a phone.

3.3 Real fires and burn severity (prompt 9)

Prompt 9 · Sun 6 Sep 2026, 11:24 PDT

Model: Opus 5 · agent time: 60 min · 151 tool calls

Add a quit button on the canvas and bind the esc key to it as well. The center display is not full screen and occupies about a quarter of the display. When fixed, proceed with phase 3

What the agent did. Fixed both problems: a real canvas button and Esc to quit, verified by injecting a keypress into the running player; and a primary window that had opened at 1920 × 1080 on a 4K monitor while the side monitors went fullscreen. Then Phase 3: the Hawk and Bug perimeters from NIFC's WFIGS service, and burn severity (dNBR) from cloud-free Sentinel-2 scenes either side of each fire, written only inside the perimeter.

The burn scar came out mirrored north to south within every tile. Unity returns pixel rows bottom-up, so a row flip that looks obviously right was actually a second flip. Agreement with the real perimeter went from 30 % to 85 % once fixed. Two of the agent's own checks had passed while the bug was live, because they shared the same compensating flip. What found it was placing markers at the real perimeter's vertices as objects in the scene, so they went through the same camera as the terrain. The agent's own verdict: it had spent a long time on reprojection comparisons before doing that, "which was the wrong order."

Top-down view of the Peavine area with the real Hawk perimeter drawn as magenta markers over the painted burn scar

The check that found the flip: the real perimeter (magenta) over the painted scar.

The Hawk Fire burn scar on Peavine Peak, seen from the air

Phase 3: the historical Hawk scar on the terrain.

Needs expert review: remote sensing. Both fires score "low" severity on the standard dNBR classes because the index measures change in infrared, and a sagebrush fire can remove nearly all the fuel while still scoring low. The agent rendered the ash darker than a literal reading of severity would give. The dNBR here is the agent's own computation from Sentinel-2, not a BAER or MTBS product; its scene selection, cloud masking and thresholds (after Key and Benson, 2006) should be checked by a remote-sensing specialist.

3.4 Fire spread (prompt 10)

Prompt 10 · Sun 6 Sep 2026, 15:20 PDT

Model: Opus 5 · agent time: 34 min · 74 tool calls

Go with phase 4

What the agent did. Phase 4: Rothermel surface fire spread on a 10 m grid over LANDFIRE FBFM40 fuel models, with slope and aspect from the same elevation data the terrain is drawn from. Spread is solved as an arrival-time problem with a priority queue (Finney's minimum-travel-time method), so work follows the fire front instead of stepping 4.2 million cells, and a finished run records when every cell burned.

It validated the model against the real Hawk perimeter: a Sørensen similarity of 0.866, igniting at the recorded origin. It swept wind speed and direction rather than assuming them, and the score peaked at 4 m/s from 210°. It pointed to independent support for that wind: the recorded ignition sits at the southern edge of the burn, so the fire ran north, which needs a southerly wind. It also reported what it could not do: particle effects do not run in its headless captures, so it could not photograph the live flames, and Windows would not let it send keystrokes to the running player, which is why it added launch flags such as -rtIgniteHawk.

Map comparing the simulated and real Hawk burn: yellow where both burned, red where only the real fire burned, green where only the simulation burned

Validation: yellow is both, red is real fire only, green is simulation only.

The simulated Hawk Fire spreading across Peavine

The simulated fire running.

Needs expert review: fire behaviour science. The wind was chosen by sweeping for the best match to the final perimeter, which is a calibration, not a forecast. The Rothermel implementation was not compared with a reference such as BehavePlus. The grid uses eight neighbours per cell, which is known to distort fire shapes. Fuel moisture is a fixed default. There is no spotting and no crown fire. Prompt 22 later replaced this validation with a calibrated spread factor (see section 3.9).

3.5 Compass, debris flows and the timeline (prompts 11–13)

Prompt 11 · Sun 6 Sep 2026, 16:39 PDT

Model: Opus 5 · agent time: 28 min · 101 tool calls

First, let's have a compass heading across the top of the display so I know which direction the camera is facing. Second, yes, the fire and flames suck pretty bad and look very bad but if we can go back to fix it later, let's proceed with phase 5 after you have the compass.

What the agent did. Added the compass strip, then built Phase 5: the Staley et al. (2017) M1 debris-flow likelihood model, and alongside it an infinite-slope factor-of-safety model with SHALSTAB wetness and root strength that decays in the months after a fire, plus debris runout routed downhill. Over the Hawk scar six months after the fire, the two models disagree by about a hundred times: at 24 mm/h of 15-minute rainfall, Staley gives 385 ha above 50 % likelihood while only 5 ha of slope fails mechanically. The agent's explanation was that Great Basin post-fire debris flows are driven by runoff rather than by slopes failing, and that few burned slopes are steep enough to slide, so the disagreement is itself the finding. While checking it fixed a runout count that overstated deposits twentyfold (774 ha against a true 37 ha).

It also flagged a problem the human had not raised: standing on the ground in the burn, as the VR showcase would, there was no texture at all within 50 m of the eye.

Debris-flow runout released at 40 mm/h over the Hawk scar

Phase 5: hazard colouring and released debris flows at 40 mm/h.

Ground-level view in a burned channel: smooth, featureless colour

What the agent reported as "featureless mush": the ground-level view before any detail textures.

Needs expert review: post-fire hydrology and geotechnical engineering. The Staley M1 model is applied here to every 10 m cell's upslope area, whereas USGS hazard assessments apply it to drainage basins and stream segments. Soil erodibility (KF-factor) is a uniform 0.25, so the soil term carries no spatial information. The slope-stability parameters are uniform too: soil 1 m deep, unit weight 17 kN/m³, friction angle 33°, cohesion 2 kPa plus 3.5 kPa from roots, transmissivity 6 m²/h. Runout stops at a fixed angle of reach (drop over distance of 0.24). All of these need site-specific values and review.

Prompt 12 · Sun 6 Sep 2026, 17:42 PDT

Model: Opus 5 · agent time: 23 min · 79 tool calls

There is something wrong with compass text and how the text looks. Even the quit button text seems warped. Fix first. Then proceed to phase 6.

What the agent did. Took responsibility ("The cause was mine."). It had drawn the interface in a Unity mode chosen only so that headless screenshots would show it, and on a desk mixing 4K, 1080p and portrait monitors that mode stretched the interface unevenly. It switched to a mode drawn at exact pixel positions and made the capture tool adapt instead. It could not confirm the fix itself: every way it tried of screenshotting the running player returned an empty image on this machine. So it asked the human to look.

How this steered the work. The agent had traded product quality for the convenience of its own tests. Only the human, looking at the real screen, could catch it.

Prompt 13 · Sun 6 Sep 2026, 18:35 PDT

Model: Opus 5 · agent time: 21 min · 60 tool calls

Text looks clean.

What the agent did. Took "Text looks clean" as confirmation and built Phase 6: a scrubbable fire timeline and a scenario panel with live sliders, and saving every parameter of a run to a file. The timeline was nearly free, because the fire solver already records when every cell burned. Stopped at the real containment time of 106 hours, the unsuppressed model had burned 6,079 ha against the real fire's 6,111 ha. The agent also found that beyond 5 km Unity draws terrain from a baked image that the fire's painting never refreshed, so from any altitude worth watching from, the scar had never appeared. What exposed another bug was that three captures at different times came out byte-for-byte identical.

How this steered the work. The agent's recommendation at the end — do the ground detail before the showcase presets — is one the human later took.

3.6 Seeing the fire spread, and rain (prompt 14)

Prompt 14 · Sun 6 Sep 2026, 19:06 PDT

Model: Opus 5 · agent time: 27 min · 72 tool calls

Before we do phase 7, I notice that I cannot see the fire start or spread. Even if the fire looks bad, I do want to see it spread. Second, let's add some rain visualization and see the landslide map change as the rain totals add up. Does that seem compatible?

What the agent did. Found four separate reasons the fire could not be seen. The main one: the historical Hawk scar was switched on by default and covers exactly the ground a Peavine ignition burns, so the simulation was painting dark ash onto ground that was already black. Ignition now switches to the pre-fire surface. It added a glowing ember layer for the active front, and fixed two ways the terrain systems were overwriting each other. It then fixed the terrain's layer channels once, as constants (base, ash, hazard, ember), since three separate systems were writing to them.

For rain it built a storm that runs forward in time and re-solves the hazard as water accumulates. This showed the two models answering different questions: in a two-hour storm, the Staley likelihood stops rising after 75 minutes, because it depends on the peak 15-minute rainfall, while the area failing mechanically grows by half again as the soil keeps wetting.

The simulated fire with a visible glowing front on Peavine

The ember front, finally visible.

How this steered the work. "Even if the fire looks bad, I do want to see it spread" is a scientist's priority: legibility of the process before polish. The agent's numbers had been right all along; the picture was not.

Needs expert review: hydrology. The storm is a single idealised peak; rainfall is uniform in space; and the soil-wetting model is a steady-state approximation driven through time.

3.7 Ground detail, buildings and flames (prompts 15–18)

Prompt 15 · Sun 6 Sep 2026, 19:45 PDT

Model: Opus 5 · agent time: 5 min · 16 tool calls

Now do the ground-level texture detail and the buildings. Then wait for my inspection.

The human stopped the agent in the middle of a tool call, then told it to carry on:

Prompt 16 · Sun 6 Sep 2026, 19:50 PDT

Model: Opus 5 · agent time: 41 min · 92 tool calls

continue

What the agent did. Added a tiling gravel texture with a normal map to every terrain, matched in colour to the median of bare ground measured from the real aerial tiles, so the ground gains grain up close without changing colour from the air. That measurement went wrong twice first (it read the burn masks as imagery, and Lake Tahoe's conifers pushed the colour blue). It then extruded 237,529 OpenStreetMap building footprints into 6.9 million triangles, fetching them in 50 small queries because the Overpass service times out on one large one. Python supplied footprints and heights; Unity placed each building on the ground it owns. It flagged what it had not measured — frame rate — and asked the human to watch it.

Ground-level view of plain grey building blocks

The first buildings: honest, untextured blocks. The human later called them "made of mud."

Prompt 17 · Sun 6 Sep 2026, 20:40 PDT

Model: Opus 5 · agent time: 1 min · 1 tool call

What's next?

What the agent did. Pointed out that VR, the project's stated purpose, had never been run, and recommended that the human put the headset on before anything else was built. It laid out a ranked list of next steps with a model for each.

Prompt 18 · Sun 6 Sep 2026, 20:42 PDT

Model: Opus 5 · agent time: 39 min · 112 tool calls

We will do the VR later. The framerate is at 60 right now.

What the agent did. Took the 60 fps as closing the performance question and worked on the flames the human had complained about: a generated flipbook of flame tongues instead of round blobs, embers blowing downwind, a flickering light, and a glow effect. On the way it found a serious bug: layers created at runtime and stored inside terrain assets were being saved as empty, which made the aerial photography vanish. It admitted it had misreported this as a colour problem in its previous message, and that it had been wrong three times about some dark wedges in its screenshots, which turned out to be its camera placed 290 m underground.

Flame sprites along the fire front, seen from the air

The reworked flames.

How this steered the work. The human deferred VR, which the agent had flagged as the largest untested risk. That was a reasonable trade, and it stayed deferred to the end: VR is still untested.

3.8 Two simulation modes and the Hawk start (prompts 19–20)

Prompt 19 · Sun 6 Sep 2026, 21:52 PDT

Model: Opus 5 · agent time: 19 min · 54 tool calls

Things are rather mixed up in the UI. Want to two major simulation modes. First: Fire spread. Second: Rain and landslide probability. In desktop mode, let's use a canvas and let the controls run across the bottom of the screen. In the UI, in Fire Spread mode, we will want to select the bug fire or the hawk fire and starting with no burn scars and camera positioned and pointing at the starting location, start the fire and simulate the fire's spread. If we are in Rain and landslide mode, then assume the fires have already occurred and simulate rainfall over the selected bug or hawk fire areas. As rain falls we would like to see the landslide probabilities change and then if there is enough rainfall, landslides start to occur. Later on we will want to compare against the what-if scenario that presumes there were not fires. Furthermore, the hawk and bug fires should stop at their real-world containment boundaries and the simulation should pause, and wait for use input to continue. There's more, but let's implement this first.

What the agent did. Replaced the corner panel with a bar across the bottom: mode, fire, the sliders that matter in that mode, and one button whose label is always the next action (Ignite, Pause, Continue past containment, Reset). A new scenario director became the only component allowed to decide whether the terrain shows burned or unburned ground. Containment works by forbidding the fire to enter any cell outside the mapped perimeter, so "nothing left to burn" means "perimeter full." Held there, the Hawk Fire fills 5,929 ha of the 6,109 ha polygon (97 %).

It reported two data problems. The official ignition point is 65 m outside the mapped perimeter, so the contained fire first burned nothing; ignition now moves to the nearest burnable cell inside, 798 m away. And held inside the polygon, the fire takes 252 hours to fill it rather than the real 106. For the Bug Fire it reported that the fire lies almost entirely outside both simulation grids and has no recorded ignition point, so the Bug button is shown but disabled, labelled "no grid".

The two-mode control bar, with the fire held at the containment line

The two-mode control bar.

How this steered the work. This prompt is a product specification written by a domain expert: what the user sees, in what order, and when the simulation should stop. It also set up a scientific comparison for later — the landslide hazard with and without the fire.

Needs expert review: fire behaviour science. Moving the ignition 798 m, and holding the fire inside a perimeter that was mapped after the fact, both shape the result. They make the replay faithful to the record; they do not make the model predictive.

Prompt 20 · Sun 6 Sep 2026, 22:31 PDT

Model: Fable 5.1 · agent time: 12 min · 21 tool calls

Leave the bug fire for later. Now, when I run the player with no options, The sim should start before the hawk fire with a pristine peavine mountain. Also the hawk fire mode seems to indicate there is no start location for the hawk fire, when in fact -rtIgniteHawk starts from what appears to the the correct start location which means you know where the hawk fire started. Explain the issue first before you fix issues

What the agent did. Explained the cause before fixing it, as asked: the director read the ignition point before the fire controller had loaded it. Every screenshot had passed because the capture tool loaded the fire first. The agent fixed the order and removed the capture tool's special loading, so its tests would take the same path as the real program. It verified from the real player's log this time.

How this steered the work. "Explain the issue first before you fix issues" is a software-engineering discipline the human imposed. The lesson — the test harness took a different path from the product — recurs three more times.

3.9 Displays and the containment line (prompts 21–24)

Prompt 21 · Sun 6 Sep 2026, 23:05 PDT

Model: Fable 5.1 · agent time: 5 min · 10 tool calls

Can we set our resolution to 3 HD monitors? If so. do so.

What the agent did. Rendered each monitor at 1920 × 1080 and let Windows scale it to the panel. It gave the portrait monitor the same pixel budget turned round (1080 × 1920) rather than stretching a landscape image, and said so as a judgement call.

Prompt 22 · Sun 6 Sep 2026, 23:12 PDT

Model: Fable 5.1 · agent time: 5 min · 8 tool calls

There is now a discrepancy with the time of containment in the real world and in the simulation. Please fix.

What the agent did. Explained that raw Rothermel, held inside the perimeter, took 252 hours to fill it; the real fire was contained at 106. It added a rate-of-spread adjustment factor, the calibration FARSITE and FlamMap provide, and set it to 252 / 106 = 2.38. The contained fire now fills its perimeter in 105.7 hours. It was plain about the cost: the earlier Sørensen validation is superseded, and with the fire held at the mapped line, the only remaining independent check is the time to fill it, which this calibration uses up.

Needs expert review: fire behaviour science. One multiplier fitted to one fire is not validation. A fire behaviour analyst should judge whether 2.38 stands in for missing processes (spotting, crown fire, wind that varies over terrain and time, suppression effects) or hides an error in fuels or moisture. Prompt 35 shows the same factor running about twice too hot on a different fire.

Prompt 23 · Sun 6 Sep 2026, 23:23 PDT

Model: Fable 5.1 · agent time: 8 min · 12 tool calls

The containment perimeter is not right. The hawk fire spread a lot more before it was contained as the burned peavine texture should tell you. It needs to spread and stop at the real-world containment boundary. Perhaps going down from the higher resolution of the monitors to HD had something to do with it?

What the agent did. Ruled out the suggested cause first: the simulation runs on a 10 m grid and reads nothing about the screen. Then it measured rather than guessed. The containment mask and the historical scar textures matched almost exactly (intersection over union 0.995; 6,109 against 6,138 ha), and the player's own log reported 5,929 ha at the hold. The simulation was right and the picture was wrong: distant terrain is drawn from a baked image refreshed two tiles per frame from an unordered set, and because that set's order never changes, the same two tiles were refreshed every frame while the rest never were. When the fire stopped, refreshing stopped too. The agent replaced the set with a first-in, first-out queue, kept refreshing after the fire stopped, and flushed every tile once the front burned out.

It was candid about the gaps: "My captures never showed this because the capture path flushes every tile," and it had not seen the fix itself, so it asked the human to check.

Top: the simulated Hawk Fire held at containment, 5,929 ha. Bottom: the historical scar from the WFIGS perimeter and Sentinel-2 dNBR, from the same viewpoint.

Same viewpoint: the simulated fire at the containment hold (top) against the historical scar (bottom).

How this steered the work. The human's guess at the cause was wrong, and the agent said so, but the observation was right, and only the human's eye had caught it. The fix came from software-engineering knowledge about unordered collections, not from fire science. This was the end of the first day.

Prompt 24 · Mon 7 Sep 2026, 10:25 PDT

Model: Opus 5 · agent time: 1 min · 1 tool call

what's next?

What the agent did. Reminded the human that its last fix was still unseen, then proposed a ranked list: the no-fire comparison in rain mode first, then animating the debris flows, the showcase viewpoints, the Bug Fire, VR, and the remaining polish.

3.10 Roads, water, snow, videos and model references (prompts 25–29)

Prompt 25 · Mon 7 Sep 2026, 10:31 PDT

Model: Fable 5.1 · agent time: 44 min · 75 tool calls

First. Reduce to one HD display for now. Then do item 6.

What the agent did. Made one HD display the default, with a launch flag to bring back three. Then item 6 of its list: 69,357 OpenStreetMap roads (17,082 km) draped on the terrain; 390 lakes and reservoirs, including Tahoe, levelled because a digitised shoreline is not level and a lake is; the colour step along the California border in the aerial imagery, which is flown per state in different years, histogram-matched away; and snow, with degree-day melt joining the water that reaches the ground in a storm. It admitted repeating a Unity null-check mistake it had already recorded in its own notes, and found that the Overpass service returns multipolygon lakes with no geometry unless asked in a particular way.

Snow on the Carson Range painted from the snowpack model

Snow as a sixth terrain layer.

OpenStreetMap roads draped on the terrain over Reno

69,357 roads.

Needs expert review: snow hydrology. Melt uses a simple degree-day factor (after Hock, 2003) with an air temperature set by the user, and the snowline drops 3 m per mm of water equivalent. Melt water is added to the soil wetting but not to the Staley 15-minute rainfall term, which is a modelling choice a snow hydrologist should check.

Prompt 26 · Mon 7 Sep 2026, 11:29 PDT

Model: Opus 5 · agent time: 1 min · 2 tool calls

run the simulation and take a video of the running simulation. First, the hawk fire, then the rain. Hide the help panels.

What the agent did. Confirmed a video encoder was available and started writing a tool to step the simulation and render each frame.

The human interrupted, then asked a different question:

Prompt 27 · Mon 7 Sep 2026, 11:32 PDT

Model: Opus 5 · agent time: under a minute · 0 tool calls

can you run the windows game bar (windows+g) to take a video of the running simulation? Answer yes or no first before taking action.

What the agent did. Answered "No." first, as asked, then explained: it cannot send keystrokes to the running player or see what a screen recorder captured. It recommended the human record with Game Bar and offered to render a video offline instead.

Prompt 28 · Mon 7 Sep 2026, 11:34 PDT

Model: Opus 5 · agent time: 1 min · 0 tool calls

If you go with the offline render, how long will it take to make a great video?

What the agent did. Estimated about 40 minutes to a rough cut and 1 to 1.5 hours to something good, and explained why the iterations, not the rendering, would take the time: it cannot see the result until it is encoded.

How this steered the work. The human asked for yes or no before any action and for a time estimate before committing. Both are ways of managing an agent whose actions are cheap to start and expensive to review.

Prompt 29 · Mon 7 Sep 2026, 15:13 PDT

Model: Opus 5 · agent time: 6 min · 18 tool calls

What fire model are you using and what landslide model. Link me to refences for both.

What the agent did. Listed the models with references (the full list is in section 8). While checking its implementation against the USGS publication rather than its memory, it found it had swapped two coefficients in the Staley M1 model since Phase 5: 0.67 belongs on the burn-severity term and 0.70 on the soil term. It fixed both the C# and the Python. It noted the error was nearly inert while soil is uniform but would have become real as soon as mapped soil data arrived. It also listed the places the implementation departs from the literature: the 2.38 spread factor, uniform soil, and a rainfall variable it had once overstated fourfold by treating an accumulation as an intensity.

How this steered the work. A simple request for references led to a code review against the primary source, which found a real bug. Asking an agent to cite its methods is also a way of getting it to check them.

Needs expert review: post-fire hydrology. The corrected coefficients should be checked against the tables in USGS Open-File Report 2016-1106 by someone who uses the model operationally, along with the definitions of each input.

3.11 Buildings, road labels and downtown (prompts 30–34)

Prompt 30 · Tue 8 Sep 2026, 08:43 PDT

Model: Opus 5 · agent time: 187 min · 170 tool calls

The 3D buildings look like they are made of mud and are unattractive. Find and use good textures, or find another way to make them look good and realistic. Can we also put mark major roads with text? Once done make a video of a flythrough of the area, noting improvements.

What the agent did. Found that every one of the 237,529 buildings was a single flat colour with no texture coordinates, so roofs and walls merged. It split roofs from walls, gave each building a stable colour from its position, added parapets and rooftop equipment on commercial roofs, and used four public-domain (CC0) facade photographs from ambientCG on towers only. Building type is inferred from area and height, because nearly every footprint in the county is tagged only building=yes. It added 432 road-name labels for 158 roads, sized to stay the same height on screen at any altitude, and rendered a 30-second fly-through video.

It admitted being wrong twice about why the ground looked pale before measuring it (the real cause was low colour saturation), and found on the way that every terrain layer had been reading its smoothness from the wrong channel.

Downtown towers with photographic facades

Towers with CC0 facades.

Interstate and street name labels lying flat along the roads

Road labels.

Prompt 31 · Tue 8 Sep 2026, 17:18 PDT

Model: Opus 5 · agent time: 17 min · 38 tool calls

Hmm, now the downtown buildings look comparatively bad. Can you find some textures from google maps or bing maps and use them for downtown and even for the houses? If so, let's just test on downtown and you can show me another flythrough when done.

What the agent did. Declined the Google and Bing part: "No — their aerial and 3D imagery is licensed, and their terms don't permit pulling tiles or the photogrammetric mesh out to texture something else." It used public-domain USGS NAIP imagery at 0.63 m over downtown instead, draped on the roofs. It then found two things it had got wrong by measuring them: the photograph was being lit twice (a photo already contains its lighting), and the dark look downtown came from the facade textures, which were two and a half stops darker than their neighbours.

How this steered the work. The agent refused part of a request on licensing grounds and offered a lawful alternative that met the same need. It also asked before extending the imagery to houses, because covering the suburbs was a real cost-and-quality trade-off.

Prompt 32 · Tue 8 Sep 2026, 22:28 PDT

Model: Opus 5 · agent time: 3 min · 4 tool calls

the fly through of downtown still looks bad since we get below roof level. I did not see the silver legacy's globe or the bowling stadiums ball. can you do a better job of downtown and just downtown. the. do a slow flythroughbof downtown past the big hotels. the hotel facades are distinctive and should appear so

What the agent did. Found both landmarks already in OpenStreetMap, tagged as domes, and found that its own pipeline was throwing those tags away. It laid out a six-step plan for downtown, with a model for each step, and then stopped before asking the question it had set up.

Prompt 33 · Wed 9 Sep 2026, 09:27 PDT

Model: Opus 5 · agent time: 1 min · 1 tool call

What was the question again?

What the agent did. Apologised for cutting off, and started to ask.

The human interrupted, then:

Prompt 34 · Wed 9 Sep 2026, 09:30 PDT

Model: Opus 5 · agent time: 43 min · 38 tool calls

Ask the questions again please

What the agent did. Asked two multiple-choice questions. The human chose authored colours now with photographs for the four biggest hotels later, and domes, the Circus Circus big top, the Reno Arch and skyways. The agent then rebuilt downtown from a fresh OpenStreetMap query that kept the tags that matter: 715 buildings, 86 building parts, 2 domes and 8 structures. It authored wall colours for about two dozen named hotels, since OpenStreetMap has none, and draped the same aerial photograph on the downtown streets. It listed five bugs caught by looking at renders, including nine buildings turned into domes because it had matched landmarks by position, and a 45-second slow flight down Virginia Street.

The Silver Legacy dome above Virginia Street

The Silver Legacy dome.

The National Bowling Stadium's ball on its roof

The bowling stadium's ball.

The Reno Arch across Virginia Street between hotel towers

The Reno Arch.

How this steered the work. The human's local knowledge — which landmarks matter and what the hotels actually look like — set the standard. The agent's contribution was to find that the data already held most of it.

3.12 The Floriston Fire (prompts 35–40)

Prompt 35 · Thu 17 Sep 2026, 14:34 PDT

Model: Opus 5 · agent time: 51 min · 88 tool calls

Ok, getting back to fire modeling. Can you look up the Floriston fire that is still burning, model it, add a button for it in the interface to start it at its real-world start location, get wind data, and model the fire burning? Go step by step.

What the agent did. Found the fire in NIFC's WFIGS: discovered 16 September 2026 at 17:00 UTC in Nevada County, California, with an infrared perimeter of 248 ha flown 11.6 hours later, 4 % contained. It built a second 15 × 15 km simulation grid, fetched LANDFIRE fuels (a timber and shrub complex quite unlike Peavine's grass and sage), and pulled hourly weather from the National Weather Service: 31 observed hours from nearby stations plus 24 forecast hours, with fine fuel moisture computed from temperature and humidity. It added a Floriston button with no containment hold, since at 4 % contained the perimeter is where the fire had got to, not a line anyone had held.

Four things went wrong. The recorded origin is 1,706 m outside the mapped burn. It sits in the town of Floriston, which the fuel map marks as non-burnable, walled off by I-80 and the Truckee River, so the model burned 5 ha and stopped; ignition now moves 108 m into the nearest large fuel patch, and records why. The agent fed fuel moisture in per cent where the model expects a fraction, so nothing spread, and chased it for two rounds as a data problem. And Hawk's 2.38 spread factor ran about twice too hot on Sierra timber, so it now belongs to the Hawk Fire only.

Uncalibrated, the model burned 69 ha in 12 hours against the real 248 ha. The agent attributed the shortfall to missing spotting and crown fire (the real perimeter is in five parts, with spot fires ahead of the head) and to weather stations 9 to 14 km away over ridges, and chose not to fit a factor to one perimeter of a fire under active suppression. It re-checked the Hawk result after every step: 5,929 ha at 105.7 hours throughout.

Needs expert review: fire weather meteorology and fire behaviour science. Fuel moisture comes from a simple equilibrium-moisture formula (after Simard, 1968) applied to station temperature and humidity; the choice of stations, their distance from the fire, the absence of terrain-channelled wind, and the fixed live fuel moisture all need a fire weather meteorologist. The 3.6-fold under-prediction is a real finding about the model's limits and should be treated as one.

Prompt 36 · Thu 17 Sep 2026, 15:47 PDT

Model: Opus 5 · agent time: 20 min · 49 tool calls

fix the burn scar painting on the Floriston grid, then modify the control of wind direction to be circular rather than a horizontal slider, and ensure the wind speed slider is in miles per hour which gets converted into the m/s that the simulation actually uses.

What the agent did. Found two faults behind the missing scar: the list of tiles the fire could paint had been taken from the historical burn, so it only covered Peavine; and once fixed, the new tiles' painting resolution was 640 m per pixel, so one 10 m cell painted nearly 4 km². It replaced the wind-direction slider with a compass dial, because a bearing wraps round and a slider does not, and put wind speed in miles per hour, converted by 0.44704 to the metres per second the model uses, with both shown.

The fire control bar with the new compass dial for wind direction

The compass dial and the miles-per-hour wind readout.

Prompt 37 · Thu 17 Sep 2026, 16:16 PDT

Model: Opus 5 · agent time: 43 min · 41 tool calls

The floriston area seems to be preburned as the textures are already blackened before I press ignite. The pause button does pause but I don't seem to be able unpause and continue simulating the fire burn. Fix first, then make an HD video of the floriston fire spreading, keep the entire fire in camera view and let's make it interesting by starting over Reno and moving to the fire origin before igniting the fire.

What the agent did. Found that its own change from the previous prompt had caused the pre-burned look: it had modified the list of terrain layers in place, which leaves a tile drawn in flat brown with no aerial photograph. It confirmed this by comparing mean colours across builds. The pause bug: pausing had set the state back to "ready", so the next press tried to light the fire again on a cell that had already burned, failed, and did nothing. It added a real paused state and a headless test that presses the button through the whole cycle. It then rendered the video: from over Reno, down the Truckee canyon, and a camera that frames the growing burn once it is lit.

The Floriston canyon before ignition, with slopes drawn in flat brown as if already burned

The bug the human reported: the canyon looks burned before ignition.

Prompt 38 · Thu 17 Sep 2026, 17:09 PDT

Model: Opus 5 · agent time: 9 min · 12 tool calls

There is a definite problem with the initial burn spreading in an area that already looks burnt. It should look pristine before the ignition with no ash. The pause button works well now. No need for a video after you fix the problem.

What the agent did. Found a much older bug. Unity stores terrain as asset files, the fire writes into them, and the agent's headless captures run the fire in editor mode and save on exit, so every screenshot of a burning fire had been baking that fire permanently into the terrain files. It proved this from file times: the world build finished at 16:28:24 and two Floriston tiles were rewritten at 16:58:00 by the video render. The first cleanup found baked scars on 20 tiles, 16 of them on Peavine, where they had passed for the historical scar. The world build now resets them, and the capture tool cleans up after itself. It verified across two separate editor runs, the only way a bug about state surviving between runs can be verified.

How this steered the work. The human reported the same symptom twice. The second report, stated flatly ("There is a definite problem"), made the agent look past its first explanation.

Prompt 39 · Thu 17 Sep 2026, 17:22 PDT

Model: Opus 5 · agent time: under a minute · 2 tool calls

rebuild the world

What the agent did. Found the Unity editor still open, so the build could not run, and said so rather than presenting the old log.

Prompt 40 · Thu 17 Sep 2026, 17:23 PDT

Model: Opus 5 · agent time: 3 min · 3 tool calls

go

What the agent did. Rebuilt the world: 67 terrains, 236,812 generic buildings, 715 downtown buildings, 69,357 roads, 390 lakes and both fire grids, with the Floriston ground confirmed clean.

3.13 Publishing, and this playbook (prompts 41–51)

Ten days later the human returned, now running Opus 5.5.

Prompt 41 · Sun 27 Sep 2026, 15:33 PDT

Model: Opus 5.5 · agent time: 1 min · 4 tool calls

Is this checked in on github?

What the agent did. Reported that the repository had no remote and nothing had been committed since 6 September, and that the uncommitted files included 1.7 GB of generated meshes, one of them larger than GitHub's 100 MB limit. It proposed ignoring the generated files, committing, and pushing to a private repository, and asked before publishing anything.

Prompt 42 · Sun 27 Sep 2026, 15:35 PDT

Model: Opus 5.5 · agent time: 1 min · 5 tool calls

do all three, private repo

What the agent did. Did all three and confirmed the repository was private.

Prompt 43 · Sun 27 Sep 2026, 15:39 PDT

Model: Opus 5.5 · agent time: 3 min · 10 tool calls

Can we add a nice screenshot of the simulation for the hawk fire to the github repo with a link to the ecsllab movie of the fire at : https://youtu.be/imduuDxpxXA?si=n2MS7ncdh7cCOIOo

What the agent did. Rendered two views of the fire, then began a third facing the active front.

The human stopped it mid-render:

Prompt 44 · Sun 27 Sep 2026, 15:43 PDT

Model: Opus 5.5 · agent time: under a minute · 3 tool calls

hawk_hero1.png is fine. Use it.

What the agent did. Added the screenshot and the link to the README, and removed the tracking parameter from the YouTube address.

Prompt 45 · Sun 27 Sep 2026, 15:45 PDT

Model: Opus 5.5 · agent time: under a minute · 1 tool call

Sent with a screenshot attached (shown below).

Use this screenshot, remove the other.

What the agent did. Replaced its render with the human's own screenshot of the running program.

The Hawk Fire simulation running in the player: the fire front on Peavine above the suburbs, with the control bar across the bottom

The human's screenshot of the running simulation.

Prompt 46 · Sun 27 Sep 2026, 15:48 PDT

Model: Opus 5.5 · agent time: 2 min · 14 tool calls

Make the default a one display configuration and the three display configuration as an option. Update the README to reflect this. Push

What the agent did. Made one display the default in code as well as in the scene, added a -rtThreeDisplays launch flag, and rewrote the README's section on running the program.

Prompt 47 · Sun 27 Sep 2026, 16:03 PDT

Model: Opus 5.5 · agent time: 18 min · 9 tool calls

Update the README, to point out that it was written by an AI. Push. Then create a playbook for public consumption based on this conversation. We need two versions in two documents, each with the same abstract. Get approval of the abstract before you create the docs. The first version should be an overview of what we did with the first prompt verbatim, and your response. Then summarize what we did. The second version needs to be much more detailed and format and list our entire conversation along with any relevant screenshots that you find in the repository. Add explanations of what we are doing and how the conversation steers development and depends on my knowledge of computing, your capabilities, scripting, and software engineering. Also point out which parts would need verification by fire modelers, their discipline, and the disciplines that would need to be involved for the fire and landslide analysis. Ask me any questions and ensure that I approve the overall structure and formatting of the playbook. In fact, show my a very short well formatted version of the playbook. You can use .md, if possible, with a table of contents and links to citations for code, models, publications for the models and code, if any, and for every data source that you accessed. You can also put this list of references and citations at the very end with link.

What the agent did. Added the note to the README and pushed it, then asked four questions (where the playbook should live, how closely to reproduce its own replies, whether to keep housekeeping prompts, and how to credit the author) and showed a short mock-up of both documents and a draft abstract.

Prompt 48 · Sun 27 Sep 2026, 16:31 PDT

Model: Opus 5.5 · agent time: under a minute · 0 tool calls

rewrite the abstract to point out that it was just one day or so for the hawk fire, then some more intermittent work as I found time for the rest. Also credit me as Sushil J. Louis, Director, Evolutionary Computing Systems Lab; Professor, Department of Computer Science and Engineering, University of Nevada, Reno.

What the agent did. Rewrote the abstract and the byline.

Prompt 49 · Sun 27 Sep 2026, 16:33 PDT

Model: Opus 5.5 · agent time: under a minute · 0 tool calls

In the abstract rewrite to point out that the Floriston fire is no longer burning. Give me a minute to review the structuring in the mockup

What the agent did. Rewrote the Floriston line of the abstract.

Prompt 50 · Sun 27 Sep 2026, 16:34 PDT

Model: Opus 5.5 · agent time: 3 min · 12 tool calls

Approved the abstract. Now push the abstract and the two mockups to github so I can look at them rendered.

What the agent did. Pushed the abstract and both mock-ups for review.

Prompt 51 · Sun 27 Sep 2026, 16:41 PDT

Model: Opus 5.5 · in progress when these documents were generated

Structure approved. Use dates and times for prompts when available. Also, point out which model (opus, sonnet, fable) did the work, if the information is available. Write the full playbooks and push

What the agent did. Wrote these two documents. It regenerated every prompt quote, time and model name from the session transcript with a script, so the quotes are exact, and chose the screenshots from the 209 images in the repository's shots/ folder.

4. Division of labour

Decision or contribution Who What it drew on
Study area, purpose, fires, audience, platform Human Local knowledge; research goals
"Plan first, get approval, step by step" Human Software-engineering practice
Choice of models (Rothermel, minimum travel time, Staley M1, infinite slope) Agent, approved by the human Knowledge of the published literature
Choice of data services (3DEP, NAIP, WFIGS, LANDFIRE, Sentinel-2, OSM, NWS) Agent Knowledge of public geospatial services
Every line of code, shader and script Agent Programming; Unity and Python
Tools for testing without the editor Agent Scripting; knowledge of Unity's command line
Checks against real records (summit height, perimeter overlap, containment time) Agent Scientific method; measurement
"I can't see the fire spread"; "the scar stops short"; "it looks pre-burned" Human Looking at the running program
One display in the editor, three in the player; HD rendering; defer VR Human Hardware and performance judgement
Refusing Google and Bing imagery Agent Licensing
Not calibrating Floriston to one perimeter Agent Modelling judgement
Private repository; what to publish Human Release judgement

The human's knowledge of computing mattered in specific ways. Knowing Unity let the human choose it and judge what the agent built. Knowing the hardware (three monitors of different sizes and orientations, an 8 GB graphics card, a Quest 3) shaped the display work. Recognising a stale display, a state machine that could not resume, and a test that could not see the product's bugs are all the judgement of someone who writes software, even though the human wrote none here.

The agent's capabilities included reading and writing code across Python, C# and HLSL shaders; querying public data services; running Unity and inspecting its output without a screen; measuring its results; and keeping notes between sessions. Its limits were that it could not see the running program's screen, send it keystrokes, record it, or put on the headset. Every serious bug in section 5 lived in that gap.

Scripting carried the project: a Python pipeline for the data, shell scripts to compile-check, build, and render screenshots or whole flight paths from the command line, environment variables to set up a scenario for a single render, and ffmpeg to turn frames into video.

Software-engineering practice showed up as phases with a "done when" test, commits at each phase, one component owning each shared resource (for example the terrain's layer channels, and the director owning burned or unburned ground), headless tests for state machines, re-running the Hawk result as a control after every change, and keeping generated files out of version control.

5. How the agent checked its own work

The agent could not watch the program run, so it built other ways to see.

Where these missed. Five serious bugs passed every check and were found by the human, because the test harness took a different path through the code from the running program:

Prompt What the human saw Why the agent's checks missed it
12 Warped text The interface mode was chosen to suit headless renders
20 No start location for the Hawk Fire The capture tool loaded the fire before the director asked for it
23 Scar stopping short of containment The capture tool refreshed every tile; the player refreshed two per frame
37 Pause could not resume Every capture photographed a finished fire and never pressed the button twice
38 Ground burned before ignition Captures ran the fire in the editor and saved it into the terrain files

The pattern is the main practical lesson of this playbook: an agent's test harness should take the same path as the product, and when it cannot, a human looking at the product is not optional.

6. What needs expert verification, by discipline

Nothing here has been reviewed by a domain expert. The table lists what each part assumes and what is missing.

Component What the implementation assumes What was checked What is missing Discipline
Fuels LANDFIRE FBFM40 (2025), 30 m resampled to 10 m Fuel mix differs sensibly between Peavine and Floriston Field check of fuel models; canopy fuels Fire ecology
Surface spread Rothermel (1972) with Albini live moisture of extinction, Anderson ellipse Sørensen 0.866 against Hawk (superseded) Comparison with BehavePlus; spotting; crown fire Fire behaviour science
Propagation Minimum travel time on an eight-neighbour grid Arrival times scale as expected with the spread factor Shape distortion from the grid Fire behaviour modelling
Calibration One rate-of-spread factor, 2.38, fitted to Hawk Hawk fills its perimeter in 105.7 h Independent validation on other fires Fire behaviour science
Wind Uniform over the grid; Hawk 4 m/s from 210° by sweep; Floriston hourly station data Consistent with the ignition at the burn's southern edge Terrain-adjusted wind; conversion to midflame wind Fire weather meteorology
Fuel moisture Hawk fixed; Floriston dead fine moisture from temperature and humidity (Simard, 1968) Units bug found and fixed Live fuel moisture; station representativeness Fire weather meteorology
Containment Fire held inside the mapped final perimeter Mask matches the scar (IoU 0.995) Suppression is not modelled, only its outcome Fire operations
Burn severity dNBR from Sentinel-2 L2A, thresholds after Key and Benson (2006) Written only inside the perimeter Scene selection, cloud masking, comparison with BAER or MTBS Remote sensing
Debris-flow likelihood Staley et al. (2017) M1, per cell's upslope area Coefficients checked against OFR 2016-1106 Basin and segment scale; mapped soil KF-factor (uniform 0.25 here) Post-fire hydrology and geomorphology
Slope stability Infinite slope with SHALSTAB wetness; uniform soil 1 m deep, φ 33°, c 2 kPa + 3.5 kPa roots Two models compared, and the disagreement explained Site soil and root data; lab strength values Geotechnical engineering; soil science
Runout D8 routing, fixed angle of reach 0.24 Double counting fixed (774 → 37 ha) Calibration against mapped debris-flow deposits Geomorphology
Storms Single-peaked storm, uniform in space Behaviour of the two models over time Design storms from NOAA Atlas 14; radar rainfall Hydrometeorology
Rain on snow Degree-day melt; snowline from the pack Snow paints and melts as designed Energy-balance melt; observed snowpack Snow hydrology
Use of results Research prototype None Communication of uncertainty; decision support Emergency management; risk communication

A credible fire and landslide analysis of this kind would need a team: a fire behaviour analyst and a fire ecologist for fuels and spread; a fire weather meteorologist; a remote-sensing scientist for burn severity; a post-fire hydrologist or geomorphologist, ideally with USGS debris-flow experience; a geotechnical engineer and a soil scientist for slope stability and soils; a snow hydrologist for rain on snow; and emergency managers if the results were ever used for planning. The computer scientist's and the agent's contribution is the platform that lets those specialists see and question the models together.

7. Data sources accessed

Every data source the agent downloaded or queried.

Data Provider Used for Access
Elevation, 1 m lidar and 10 m USGS 3D Elevation Program Terrain, slope, aspect, flow routing 3DEPElevation ImageServer
Aerial imagery (NAIP), 0.6 m to 5 m USDA, via USGS Terrain colour; downtown roofs and streets USGSNAIPPlus ImageServer
Fire perimeters and incident attributes, including ignition points NIFC WFIGS Hawk, Bug and Floriston perimeters, origins and dates WFIGS Interagency Perimeters · NIFC Open Data
Sentinel-2 Level-2A imagery ESA Copernicus, via Microsoft Planetary Computer Burn severity (dNBR) Planetary Computer: sentinel-2-l2a
Fuel models, FBFM40 (LF2023–LF2025) LANDFIRE, via the LANDFIRE Product Service Fire spread LANDFIRE FBFM40 · LFPS services
Buildings, roads, water, downtown building parts OpenStreetMap, via the Overpass API City model Overpass API · data © OpenStreetMap contributors, ODbL
Hourly observations and forecasts (stations KTRK, SMDC1, NV009, DOGC1) National Weather Service Floriston wind, temperature, humidity api.weather.gov
Facade photographs (Facade001, Facade006, Facade018A, Facade020A) ambientCG, CC0 Tower facades ambientCG
Soil survey (queried, not used) USDA NRCS Soil Data Access Explored for KF-factor; the model still uses a uniform value Soil Data Access
News and encyclopedia pages on the Hawk and Bug fires Wikipedia, KUNR, 8 News Now, KOLO Dates, sizes and locations while planning Hawk Fire · KUNR · Bug Fire · 8 News Now · KOLO

The ash, gravel, flame and smoke textures were generated procedurally by the pipeline, not downloaded. Google Maps and Bing Maps imagery was not used (see prompt 31).

8. References

Fire

  1. Rothermel, R. C. (1972). A mathematical model for predicting fire spread in wildland fuels. Research Paper INT-115. USDA Forest Service. https://doi.org/10.2737/INT-RP-115
  2. Albini, F. A. (1976). Estimating wildfire behavior and effects. General Technical Report INT-30. USDA Forest Service. https://www.fs.usda.gov/rm/pubs_int/int_gtr030.pdf
  3. Anderson, H. E. (1983). Predicting wind-driven wild land fire size and shape. Research Paper INT-305. USDA Forest Service. https://doi.org/10.5962/bhl.title.69035
  4. Byram, G. M. (1959). Combustion of forest fuels. In K. P. Davis (Ed.), Forest Fire: Control and Use (pp. 61–89). McGraw-Hill. (No online copy found.)
  5. Scott, J. H., & Burgan, R. E. (2005). Standard fire behavior fuel models: a comprehensive set for use with Rothermel's surface fire spread model. General Technical Report RMRS-GTR-153. USDA Forest Service. https://doi.org/10.2737/RMRS-GTR-153
  6. Finney, M. A. (1998). FARSITE: Fire Area Simulator — model development and evaluation. Research Paper RMRS-RP-4. USDA Forest Service. https://doi.org/10.2737/RMRS-RP-4
  7. Finney, M. A. (2002). Fire growth using minimum travel time methods. Canadian Journal of Forest Research, 32(8), 1420–1424. https://doi.org/10.1139/x02-068
  8. Simard, A. J. (1968). The moisture content of forest fuels. Forest Fire Research Institute, Canada Department of Forestry and Rural Development. (No online copy found.)
  9. Key, C. H., & Benson, N. C. (2006). Landscape assessment: ground measure of severity, the Composite Burn Index; and remote sensing of severity, the Normalized Burn Ratio. In FIREMON: Fire effects monitoring and inventory system. General Technical Report RMRS-GTR-164-CD. USDA Forest Service. https://doi.org/10.2737/RMRS-GTR-164

Debris flows, slope stability and snow

  1. Staley, D. M., Negri, J. A., Kean, J. W., Laber, J. L., Tillery, A. C., & Youberg, A. M. (2017). Prediction of spatially explicit rainfall intensity–duration thresholds for post-fire debris-flow generation in the western United States. Geomorphology, 278, 149–162. https://doi.org/10.1016/j.geomorph.2016.10.019
  2. Staley, D. M., Negri, J. A., Kean, J. W., Laber, J. L., Tillery, A. C., & Youberg, A. M. (2016). Updated logistic regression equations for the calculation of post-fire debris-flow likelihood in the western United States. Open-File Report 2016-1106. U.S. Geological Survey. https://doi.org/10.3133/ofr20161106
  3. U.S. Geological Survey. Emergency assessment of post-fire debris-flow hazards: scientific background. https://www.usgs.gov/programs/landslide-hazards/science/scientific-background
  4. Montgomery, D. R., & Dietrich, W. E. (1994). A physically based model for the topographic control on shallow landsliding. Water Resources Research, 30(4), 1153–1171. https://doi.org/10.1029/93WR02979
  5. Sidle, R. C., & Ochiai, H. (2006). Landslides: Processes, Prediction, and Land Use. Water Resources Monograph 18. American Geophysical Union. https://doi.org/10.1029/WM018
  6. Heim, A. (1932). Bergsturz und Menschenleben. Fretz und Wasmuth. (No online copy found.)
  7. Corominas, J. (1996). The angle of reach as a mobility index for small and large landslides. Canadian Geotechnical Journal, 33(2), 260–271. https://doi.org/10.1139/t96-005
  8. O'Callaghan, J. F., & Mark, D. M. (1984). The extraction of drainage networks from digital elevation data. Computer Vision, Graphics, and Image Processing, 28(3), 323–344. https://doi.org/10.1016/S0734-189X(84)80011-0
  9. Barnes, R., Lehman, C., & Mulla, D. (2014). Priority-flood: an optimal depression-filling and watershed-labeling algorithm for digital elevation models. Computers & Geosciences, 62, 117–127. https://doi.org/10.1016/j.cageo.2013.04.024
  10. Hock, R. (2003). Temperature index melt modelling in mountain areas. Journal of Hydrology, 282(1–4), 104–115. https://doi.org/10.1016/S0022-1694(03)00257-9

Software

  1. Unity 6 (6000.5.9f1), Universal Render Pipeline 17.5, OpenXR plug-in. https://unity.com/ · https://docs.unity3d.com/Packages/com.unity.render-pipelines.universal@17.0/manual/index.html · https://docs.unity3d.com/Packages/com.unity.xr.openxr@latest
  2. Python libraries: NumPy https://numpy.org/ · rasterio https://rasterio.readthedocs.io/ · pyproj https://pyproj4.github.io/pyproj/ · Shapely https://shapely.readthedocs.io/ · Pillow https://python-pillow.org/ · Requests https://requests.readthedocs.io/ · pystac-client https://pystac-client.readthedocs.io/ · Planetary Computer SDK https://github.com/microsoft/planetary-computer-sdk-for-python
  3. FFmpeg, via imageio-ffmpeg. https://ffmpeg.org/ · https://github.com/imageio/imageio-ffmpeg
  4. GitHub CLI. https://cli.github.com/
  5. Claude Code, Anthropic. https://claude.com/claude-code

The code itself is in this repository. The fire model is in Assets/RenoTwin/Scripts/Fire/ (Rothermel.cs, FireSim.cs, DebrisFlow.cs), and the data pipeline in Tools/pipeline/.