Heatline

Heatline is a human-governed, turn-based AI environment crisis command simulation

Comment

Inspiration

I have always loved learning—reading books, using AI to teach myself new subjects, and exploring what technology could make possible. I am also a longtime Civilization player, so I enjoy systems where conditions evolve, resources are limited, and every decision creates consequences.

While reading news about extreme heat, drought, and infrastructure failures around the world, I began wondering: what if the strategic clarity of a turn-based game could help people rehearse real crisis decisions?

That question became Heatline: an attempt to combine AI-assisted planning, constrained optimization, and turn-based simulation into a system for exploring how a city might respond to a rapidly changing heat emergency.

What it does

Heatline is a human-governed, turn-based AI crisis command simulation created for Orion Global Hackathon 2026.

Before entering the command room, the player can choose a prepared emergency or design a custom exercise by changing temperature, power outages, transit disruption, available staff, generators, shuttles, water, budget, and the opening incident.

Each turn represents a 30-minute operational period. The player:

  1. Receives new incident evidence.
  2. Inspects an AI-generated response strategy.
  3. Examines affected locations, expected changes, constraints, and trade-offs.
  4. Edits, rejects, or authorizes individual actions.
  5. Watches the approved response deploy and auto-resolve.
  6. Faces the resulting recovery, steady-state update, or new disruption.

Heatline does not finish simply because a timer expires. In stabilization mode, the session ends only after the city satisfies a public set of coverage, resilience, resource, authorization, and crisis-pressure targets for two consecutive periods.

The current city and outcomes are synthetic. Heatline is a decision-rehearsal prototype, not a live emergency dispatch or forecasting system.

How we built it

I built Heatline with React, TypeScript, and Vite, separating the product into several cooperating systems.

A symbolic strategy agent converts typed incident evidence into structured NOW, NEXT, and WATCH actions. These actions explain what should change, why it matters, which locations are affected, and what measurable result is expected.

A deterministic optimization engine then evaluates the bounded response space. It examines all 63 non-empty combinations of six modeled response centers alongside the available shuttle configurations. It rejects plans that violate budget, staffing, generator, water, closure, inventory, or human-directive constraints. It also removes every active center once to measure how much service would remain after the worst single-center failure.

The simulation resolver applies only the actions authorized by the player. It calculates modeled recovery, advances the clock, reveals the next event, and marks the previous approval as stale whenever new evidence arrives.

The interface connects incidents and proposal items directly to their map locations. Ordered deployment animations, consequence reports, plan deltas, resource indicators, and a full-screen clock make every turn understandable without hiding important information inside menus.

The current AI is intentionally local and inspectable rather than a hosted LLM. A future language model could improve scenario generation and explanation, but it would remain constrained by the deterministic solver and human approval boundary.

Challenges we ran into

The hardest challenge was preventing the AI from feeling like a collection of static templates. A useful strategy needed to change when the incident changed, when resources disappeared, or when the player made an intervention that worsened the situation.

Another challenge was balancing the crisis system. Early versions produced disruptions too frequently, making the simulation feel like an unavoidable apocalypse. I redesigned progression around a recovery-led event pool, with a lower chance of new disruption and a greater chance of recovery or steady-state updates.

Visual causality was also difficult. It was not enough to display a new number after approval. Heatline needed to show which action deployed, where it occurred, what changed, how time advanced, and why the following plan was different.

Finally, I had to keep the interface readable while exposing budget, resources, incidents, locations, AI reasoning, authorization state, and stability progress on one command screen.

Accomplishments that we're proud of

I am proud that Heatline developed into a complete playable loop rather than remaining a static dashboard.

Players can create scenarios, receive changing evidence, compare adaptive proposals, interfere with the plan, trigger AI countermeasures, authorize individual actions, and observe their modeled consequences over multiple turns.

The optimizer produces an inspectable receipt showing evaluated configurations, rejected options, constraints, targets, and resilience results. The system also maintains a genuine human-approval boundary: required actions cannot be silently removed, and no simulated response resolves until the current proposal is authorized.

Most importantly, Heatline now has a measurable finish condition. The player is not told that the crisis is solved because the interface says so; the modeled city must satisfy disclosed targets for two consecutive operational periods.

What we learned

I learned that trustworthy AI is not only about producing an intelligent-looking answer. Users need to understand what changed, what assumptions were made, which constraints were checked, and where human authority begins.

I also learned that game-design principles can make serious systems easier to understand. Turns, visible consequences, scarce resources, changing conditions, and clear win conditions transform an abstract optimization model into something people can explore and challenge.

Finally, I learned the importance of being honest about a prototype’s boundaries. Synthetic measurements can support repeatable testing and demonstrate a workflow, but they are not evidence of real-world safety or impact without domain experts, authoritative data, and field validation.

What's next for Heatline

The next step is to evaluate Heatline through historical tabletop exercises with emergency-management professionals and measure planning time, constraint violations, overrides, comprehension, and recovery across repeatable scenarios.

Future versions could add authoritative adapters for GIS, weather, utility, transit, facility, and inventory data; authenticated operational roles; collaborative planning; durable audit histories; rollback; and configurable city packages.

I also want to introduce an LLM-based scenario director and explanation layer. It could generate richer evolving incidents, interpret operator questions, and explain alternative strategies—but it would never bypass the deterministic feasibility engine or the human authorization gate.

The long-term vision is for Heatline to become a safe rehearsal environment where cities can test difficult decisions before those decisions have to be made during a real emergency.

Built With

Share this project:

Updates