Why My Urban Heat Agent Returns "INSUFFICIENT_EVIDENCE" Instead of an Answer

Urban heat is one of the clearest examples of a problem where the obvious signal can mislead. Temperature tells you where it is hot, but not why, what the evidence says, or whether anything can be done about it. When I started the Graph Hacks challenge, I wanted to build an agent that treats that gap seriously.
The problem
Heat prioritization depends on connected information: the risk factors in an area, the evidence behind each claim, the facilities nearby, and the interventions that could help. A single temperature reading, or a table with one row per zone, loses those relationships. And an agent that always picks a winner can produce a confident answer built on incomplete or unverified data.
What HeatPath does
HeatPath compares two urban heat hotspots. It stores each hotspot as a HeatZone node in FalkorDB, linked to RiskFactor, Evidence, Facility, and Intervention nodes through relationships such as HAS_RISK, SUPPORTED_BY, and NEARBY_FACILITY. The agent runs Cypher queries to pull each hotspot's connected records, builds an investigation report, and compares the two.
Its most important behaviour is what it refuses to do. If a hotspot is missing, its data is unverified, its measurement dates aren't comparable, or no verified evidence is linked to it, the decision is INSUFFICIENT_EVIDENCE and no winner is chosen. Even when those checks pass, it still needs a validated prioritization policy before recommending anything. Every run is saved as an InvestigationHistory node, so the reasoning can be audited later.
Why a graph
Investigation questions are about relationships. "What risks does this hotspot share with that one?" is one traversal in a graph. In a relational schema, it becomes a set of joins that get harder to maintain as the model grows. Storing investigation history in the same database also means past runs can be retrieved as context.
What I learned
Conservative defaults matter. It's easy to build a system that always answers. Building one that can say "not enough evidence" required deciding, in advance, what counts as enough.
Keep history separate from evidence. Past investigations are useful context, but if they could override current evidence, a stale or wrong earlier conclusion could drive a new decision. I made the history read-only with respect to decisions.
Test the refusals, not just the answers. Five automated tests cover missing records, synthetic data, unverified records, mismatched dates, and the absence of a prioritization policy. Most of the value is in those cases.
Be honest about the data. HeatPath uses synthetic records. A passing check doesn't prove the evidence is real, and the project is a prototype, not a validated prioritization system.
What's next
Real-world validation would need independently verified data and an agreed prioritization policy. Until then, HeatPath is a demonstration of how graph-connected evidence and conservative decision rules can work together.
The code is at https://github.com/SharanyaRamSR/heatpath-hackathon.