CropHeat AI
Turning hyperlocal climate intelligence into crop-specific heat-risk decisions.
An explainable hybrid risk engine combining live geospatial temperature intelligence with crop and growth-stage sensitivity.
Weather data is not the same as crop risk.
Farmers and agronomists can get generic forecasts, but a headline temperature does not answer whether the heat is dangerous for a specific crop at a specific growth stage. CropHeat AI was built to turn field-level climate intelligence into an interpretable risk decision.
A transparent risk pipeline, not a black box.
CropHeat AI combines FortyGuard's hyperlocal temperature intelligence with sourced crop heat-sensitivity thresholds. The system produces a 0–100 risk score, exposes the factors contributing to that score, and then provides a plain-language advisory.
Temperature, exceedance and persistence heatmaps from FortyGuard.
Temperature, exposure, persistence, humidity/wet-bulb, crop sensitivity and growth stage.
Transparent weighted scoring with sourced thresholds rather than invented values.
From geospatial API to field-level decision.
Heatmaps + environmental data
Service orchestration
SQLite + credit protection
0–100 explainable score
Map + timeline + advisory
The API stays behind the backend boundary.
FortyGuard calls are isolated behind the backend service layer. The frontend never talks directly to FortyGuard, and the API key stays on the server. Heatmap calls are cached and shared by region, while environmental parameters are sampled selectively to conserve credits.
These values are documented in the project README as personally verified FortyGuard outputs, not fabricated application metrics.
The LLM explains the score — it does not calculate it.
When an Anthropic API key is available, the advisory layer receives the already-computed risk score, severity level, and contributing factors and turns them into plain-language recommendations. If the LLM is unavailable, a deterministic rule-based fallback takes over and is explicitly labeled as such.
Built with constraints in mind.
One shared regional heatmap is preferred over a request per field; caching and a budget guard reduce unnecessary API consumption.
The UI distinguishes LIVE, CACHED, DEMO DATA and SIMULATED instead of presenting synthetic data as live.
Core risk scoring does not depend on an LLM being available, so the product remains usable when advisory generation fails.
Crop heat-sensitivity thresholds are documented with agronomy references rather than invented for the demo.
The system stack.
What is intentionally not claimed yet.
The current demo uses a small fixed San Jose, California region sized for the FortyGuard Basic-tier heatmap cap.
The what-if simulator currently varies temperature; exposure and persistence are not yet wired to a full live recomputation.
Live Anthropic calls are implemented but were not smoke-tested with a funded key in the build environment; the rule fallback is confirmed working.
The current heatmap-to-field mapping uses nearest-centroid matching; polygon area-weighting is a planned improvement.