How an offhand question about an old gold mine turned into a 3D reconstruction of its underground workings — built entirely through conversation with an AI coding agent, over three days in July 2026.
Evolution Mining's Cochenour Complex, in the Red Lake district of Ontario, has been mined, flooded, dewatered, and re-explored on and off since the 1930s. A page in the mine's own public technical report showed unlabeled black lines running out from the shaft toward a neighbouring mine complex — and that small mystery is what started this project: could the underground workings actually be reconstructed in 3D from public records?
This site is the result. It came together prompt by prompt, across about twenty separate Claude Code sessions, using historic exploration reports, government geological archives, LiDAR elevation data, and satellite imagery. Below is the real, unedited record of how that happened — a handful of the most interesting prompts along the way, and exactly where the underlying data came from.
The first real question was whether any of the underground geometry — shafts, drifts, stopes — was recoverable from public sources at all, beyond the schematic lines in the mine's own investor report.
I'd also like you to research whether there are any possible 3D data sources for the shafts and drifts (or any other tunnels / slopes / etc) that might allow us to create a 3D map. Pg 45 of Red Lake Operations Ontario, Canada NI 43-101 Technical Report (Evolution Mining investor relations host) […] show black lines emenating from the mine and to the right (labelled Cochenour Heritage Drill) going over to the Campbell Complex. I suspect these are the drifts and if we could somehow obtain the data for them I'd love to recreate a 3D model. Be smart about token usage, do the high judgement things yourself but delegate simple web searches and reading docs / grepping etc to Haiku or Sonnet etc.
That last line became a running theme: nearly every session that followed asked Claude to reserve its own judgment for the hard calls — georeferencing a scanned map, deciding what's trustworthy — and hand routine web searches and file reads off to cheaper subagents. The answer to the question turned out to be yes: century-old exploration reports, government mineral-inventory records, and a province-wide drill hole database all existed, just scattered across different archives and never assembled.
Digitizing the historic mine-plan sheets meant georeferencing century-old scanned drawings against modern satellite imagery by hand — slow, judgment-heavy work that kept running single sessions out of context before finishing.
Could you have a look at a session that got 90% of the way through finishing earlier today. It ended with this: ``` ◫ Cogitated for 9m 11s ⏺ Agent "Inventory AFRI 0002 map sheets" finished · 10m 42s […] ⏺ Agent(Digitize Wilmar level plans) Sonnet 5 Backgrounded agent (↓ to manage · ctrl+o to expand) ☐ 3 tasks (0 done, 2 in progress, 1 open) ◻ Phase 1: compile raw data into data/raw/ ◻ Phase 2: georeference level plans and digitize workings ◻ Phase 3: assemble 3D outputs and viewer ``` Can you look deeply into what that plan was and tell me exactly what part of that plan has not yet completed yet?
[…] I think it's using too much context window and not breaking down the problem enough. It was busy doing the @PROMPT_wilmar_digitization.md but seems to have stalled. I'd like a .md document that breaks down the problem step by step and then have the overall prompt kick off context efficient subagents that do most of the work in code and separate context windows from the main one.
The fix was to stop doing the georeferencing inline and instead write a step-by-step plan document that dispatched most of the digitizing work to disposable subagent sessions, each with its own context window, while the main session just verified the results. That pattern — a written plan handed off to a fresh session — ended up repeating for almost every phase after this one.
With the underground geometry in place, the surface needed work too: satellite-derived terrain got grainy up close, and entire residential streets weren't rendering as buildings at all.
we just completed ~/.claude/plans/cosmic-imagining-panda.md and it mostly works. the streets look good and a couple of streets of buildings appeared. however, the buildings on […] are what I care about most. They are at the bottom of this image. generally every place there is a little white square on the terrain beside a road, there should be a building. [screenshot attached] What could we do to add in the missing buildings?
The diagnosis: OpenStreetMap, the first data source used for building footprints, simply hadn't been traced by anyone along that street — the standard query returned almost nothing there. The fix merged in Microsoft's Global ML Building Footprints dataset (machine-detected from aerial imagery) wherever OSM had a gap, while still preferring OSM's real, community-verified data wherever it existed.
do you have instructions for how I might create the data and volunteer it to open street map (I'd do this as a separate project later if that's feasible)
Every line in the 3D viewer traces back to a specific document or dataset. Full citations,
confidence ratings, and caveats for each one are kept in the project's research_log.md
and data/3d/MANIFEST.md. The short version:
If you know the Cochenour / Red Lake / Balmertown area, worked at the mine, or just want to point out something this project got wrong — I'd genuinely like to hear it.