Why This Matters
HeatShield Planner was built for the Kiro Spark Challenge. This page maps the feature set to the three judging rubric categories so evaluators can quickly see how each capability contributes to the overall project.
Potential Value
Heat-related illness is a real risk on the ASU Tempe campus, where summer temperatures regularly exceed 110 °F. HeatShield Planner addresses this by turning a single-route comparison tool into a full-day heat-risk planner.
Full-Day Planner
Users enter 2–5 campus commitments and receive per-transition heat-risk analysis for every walking segment in their day. Instead of checking one route at a time, the planner evaluates the entire schedule and highlights the riskiest segment automatically.
Heat Budget Dashboard
A visual heat budget shows how much of a daily exposure budget each walking segment consumes. Shaded routes, cooling stops, and shuttle alternatives reduce consumed budget — giving users a concrete way to see the cumulative benefit of heat-aware planning.
Shuttle Alternatives
When a walking segment is classified as "higher-risk" or "not recommended," the planner recommends the nearest campus shuttle stop as an alternative. This provides a practical fallback that goes beyond "avoid the heat" advice and offers a concrete action.
Implementation
The planner is built as an additive module layer on top of the existing ShadowPath Route_Engine. No existing files were modified (except navigation links and the GeoJSON dataset). All new logic lives in lib/planner/ and components/planner/.
Pure Utility Functions
Every planner computation — schedule transitions, segment risk, daily exposure, heat budget, safety evaluation, and recommendations — is implemented as a pure function with explicit inputs and outputs. No side effects, no hidden state. This makes the entire computation layer deterministic and independently testable.
TypeScript Types
All new data structures are defined in a single lib/planner/types.ts file: CampusCommitment, ScheduleTransition, HeatBudget, DailySafetyEvaluation, and more. The type system enforces that risk levels are always one of "lower-risk," "higher-risk," or "not recommended" — the word "safe" cannot appear.
Property-Based Tests
The planner includes 16 correctness properties verified with Vitest and fast-check. These properties cover invariants like "N commitments produce exactly N−1 transitions," "consumed budget plus remaining budget always equals 100," and "higher shade always reduces heat budget consumption." Each property runs a minimum of 100 iterations across randomly generated inputs, catching edge cases that example-based tests miss.
Quality & Design
Quality is not just about code — it is about how the app communicates with users, who it includes, and how transparent it is about its limitations.
Responsible Language
The app never uses the word "safe." All risk communication uses three carefully chosen labels: "lower-risk," "higher-risk," and "not recommended." Recommendations are framed as options ("consider leaving earlier") rather than directives ("you must leave earlier"). A prototype disclaimer on the Day Planner page reminds users that the planner uses demo data and estimated calculations for educational and planning purposes only.
Accessibility
Every new component is keyboard-navigable and screen-reader compatible. Form inputs have associated <label> elements. Toggle switches use role="checkbox" with aria-checked. Risk badges use role="status" with descriptive aria-label attributes. Color-coded indicators always include text labels so colour is never the sole means of conveying information.
Methodology Transparency
The Methodology page documents the Exposure_Score formula, all input variables and weights, data sources, known limitations, and responsible design decisions. The Kiro Process page shows the full spec-driven development artefacts — requirements, design, tasks, test plan, and experiment log — so evaluators can trace every feature back to a requirement and every test back to a correctness property.