SentinelSwarm

• 

  Architecture Diagram

• 

  Slack Chaos Zone

• 

  Incident Control room

• 

  Evidence,ledger and sources

• 

  How refresh works

• 

  How human approval works

Inspiration

Flood response does not usually fail because nobody sent a message. It fails because the important messages are in different places.

A route update appears in #routes. A shelter reports capacity in #shelters. Someone asks for water in #supplies. Volunteers announce availability elsewhere. By the time a coordinator has read all of that, the situation may already have changed.

SentinelSwarm was built around a narrow, real workflow: a coordinator handling a monsoon-flood incident in Zone B needs one reviewable plan inside Slack, without pretending a bot should make emergency decisions.

What it does

A coordinator writes:

@SentinelSwarm analyze Zone B risk

SentinelSwarm creates an Incident Control Room in the Slack thread. It pulls together Slack context, weather and flood signals, and local operational data for routes, shelters, volunteers, supplies, and zones.

The result is not a chatbot summary. It is a Block Kit control room containing:

• Source labels and an Evidence Ledger
• Incident severity and confidence
• Route status and recommended alternatives
• Shelter, volunteer, and supply matches
• A draft action plan
• Approval controls

The plan stays a draft until a person clicks Approve Plan. Only then can it be posted to #coordination.

How we built it

SentinelSwarm uses Node.js, TypeScript, Slack Bolt, Slack Socket Mode, the Slack Web API, Block Kit, Zod, Open-Meteo, and Railway.

The main retrieval path uses Slack Real-Time Search through assistant.search.context. The app starts from an app_mention because Slack provides the required action token in that workflow.

The planner is deterministic by default. It combines incident reports, route data, shelter capacity, volunteers, supplies, and risk signals to rank urgency and recommend actions. Gemini refinement is optional and disabled for the primary demo.

We also built deterministic fallback paths for every external dependency:

• RTS failure uses mockContext.json
• Weather failure uses mockWeather.json
• Flood failure uses mockFlood.json
• LLM failure uses the deterministic planner

The Slack card shows whether information came from RTS, channel enrichment, a live signal, or fallback data.

Challenges we ran into

The difficult part was handling change safely.

Slack RTS needs an action token from the original mention, but that token should not be stored. That means Refresh Analysis cannot simply repeat the original RTS request. Instead, refresh safely rebuilds the plan from the original report, deterministic fallback context, optional Slack channel enrichment, and current risk signals.

We also had to prevent stale approval. If a route changes after a coordinator has approved a plan, that approval should not silently apply to the new situation. Refresh Analysis resets the plan to draft and requires approval again.

Accomplishments that we're proud of

We delivered a complete Slack workflow:

Field reports and operational updates → Incident Control Room → Route update → Refresh Analysis and What Changed → Human approval → Approved #coordination handoff

The strongest part of the project is the boundary around automation. SentinelSwarm can organize evidence and propose a plan, but it cannot dispatch people or publish final assignments on its own.

We are also proud that fallback mode is visible rather than hidden. A demo that continues working during an API failure is useful only if the coordinator can see what kind of information they are relying on.

What we learned

We learned that crisis-support software needs to be legible before it needs to be clever.

A recommendation is only useful when a coordinator can inspect its sources, understand its limits, and decide whether to act. That is why the Evidence Ledger, source labels, refresh behavior, and approval gate became central parts of SentinelSwarm instead of secondary polish.

What's next for SentinelSwarm

The next step is testing the workflow with campus safety teams, NGOs, and volunteer coordinators using authorized data.

Future work would focus on better shift handovers, durable plan state for longer incidents, permission-aware evidence access, and feedback from real coordinators. The core rule would remain unchanged: SentinelSwarm helps people make decisions; it does not make emergency decisions for them.

Built With

• node.js
• railway
• slack-block-kit
• slack-bolt
• slack-real-time-search
• slack-socket-mode
• slack-web-api
• typescript
• zod