A planned Bayesian spread model for Solenopsis invicta — fed by observation and remote-sensing data, informed by the published literature via the Fire Ant Literature engine, and built on the same shared engine core that powers every Infosource product.
A working spatio-temporal model has to handle three things at once: where infestations are observed today, how the probability of spread varies across the landscape, and how interventions shift that probability over time. The plan is to do all three on top of one provenance-first core.
Geolocated detection records, surveillance grids, and remote-sensing signals — held with full provenance so every dot on the map traces back to the source it came from.
Posterior maps of infestation probability, updated as new observations arrive — uncertainty kept explicit rather than averaged away.
What changes under a treatment, a surveillance gap, a climate shift — modelled as parameter perturbations, with the same provenance trail from scenario back to evidence.
The spatio-temporal model isn't a standalone build. It's a Tier 3 instance of the shared Infosource core — pointed at fire-ant biology, and paired with a literature engine that keeps it grounded in what's already been published.
The same compiled-card pipeline as the Crystallography Engine, pointed at the fire-ant corpus. It feeds biological parameters and prior knowledge into the spread model — and every parameter cites the paper it came from.
Planned alongside this toolWhere SDIS gives the single pane across assets, sensors and operations, this tool gives the spread surface to drive decisions on. Same core, different ontology layer; both can be composed onto the same map.
See the full engine familyA mock spread surface — not real data — showing the layered approach: observation points, posterior infestation probability, eradication zones, and a time index. The real output will use your jurisdiction's records and a calibrated model.
If you work on fire-ant surveillance, eradication, or research and would use a tool like this, the most useful thing right now is to describe the decisions you'd want it to support. That shapes the ontology layer before any code is written.