Not all 23 get invoked in one pass. The system runs 4 different types of cycles, each with its own Gemini call, and within a cycle the model picks a subset of tools based on the context rather than fanning out to everything.
Over the last week, the median ends up being about 6 tool calls across 4 distinct tools per cycle.
Latency-wise, median completed cycle time is about 37s overall. The heavy path is FIRMS: about 135s median / 265s p90 over the same window.
It runs asynchronously in the background, so the web UI isn’t blocked on a cycle finishing, though cycle latency still affects how quickly new detections get enriched.
Thanks, this is really helpful. That filtering/perimeter pipeline is exactly the kind of deterministic path I'm interested in learning from, especially for pushing more of the false-positive reduction upstream before the model gets involved at all.
My take so far is that models seem most useful in the contextual triage step and in synthesizing multiple sources into a structured assessment. But most of the system around that is and should be deterministic.
The physics-based approach you're describing makes a lot of sense to me for spread prediction - different tool for a different part of the problem.
If there's a public writeup on the filtering process you'd recommend, I'd love to take a look.
Happy to help. This is the official methods description for the Canadian gov's FM3 data, it's probably the best place to start although the details are mostly covered in much longer publications that require some digging: https://cwfis.cfs.nrcan.gc.ca/background/dsm/fm3
Good call. The system does try to match to official reporting and update when it finds one, but the working names in the meantime could definitely cause confusion.
Probably another case where that should be deterministic instead of model-generated. Thanks.
Honestly, not robustly enough yet. I've already been hitting timeouts on NWS gridpoint forecasts.
Right now some weather failures don't stop the rest of the assessment loop. Successful fetches get persisted so the system builds historical weather context over time.
The webhook idea is interesting. The monitoring loop is already separated from the web layer, so publishing to external consumers would be a natural extension.
Fair points, I leaned a little hard into the ops aesthetic. Grey text might not be doing anyone any favors.
On the Evidence tab, I agree that it should be incident-specific to be useful on its own. Right now the model scopes what evidence gets attached, so probably a case where that should be deterministic instead.
Right, that's a clean way to frame the boundary. Appreciate it.
On ICS integration, I haven't gotten there yet. The system outputs structured incident records, but I don't have real operational experience on that side.
The limited-connectivity point is interesting. If the output is a compact structured record that doesn't need a live connection to be useful, that could change what integration looks like.
If you have a strong opinion on what people actually use there, I'd be interested.
From what I've seen, the teams that are actually on the fireline mostly use paper ICS 214s and radio. The structured digital stuff lives at the ICP/EOC level. So the gap is really between field collection and the management system — if you can get a compact record off a phone with no connectivity requirement, that bridges it without asking anyone to change their workflow.
I think the practical win is SALUTE-style reports that auto-populate grid and DTG, exportable as plain text. No one wants another app to learn at 0200 on a fire.
Over the last week, the median ends up being about 6 tool calls across 4 distinct tools per cycle.
Latency-wise, median completed cycle time is about 37s overall. The heavy path is FIRMS: about 135s median / 265s p90 over the same window.
It runs asynchronously in the background, so the web UI isn’t blocked on a cycle finishing, though cycle latency still affects how quickly new detections get enriched.
reply