Fieldcraft/Endymion

Emergency Management System Built by operators for missions

Comment

Fieldcraft/Endymion — Hackathon Submission

Inspiration

Fieldcraft/Endymion came from real disaster response operations, not a theoretical use case.

Our team has spent decades supporting emergency management and disaster response missions alongside FEMA, USACE, National Guard units, and prime contractors. We’ve worked through the operational reality: spreadsheets, fragmented tools, delayed status updates, and decisions made under pressure with incomplete visibility.

The core motivation was simple: teams in the field and teams in command often operate with different pictures of the same mission. We built Fieldcraft/Endymion to close that gap with one shared operational workflow and an AI assistant focused on clarity, not noise.

What it does

Fieldcraft/Endymion is an AI-assisted operations platform for disaster response and emergency infrastructure missions.

It currently delivers:

  • A map-centric operational view of incidents, assets, and mission activity
  • A command workflow from planning to dispatch to mobilization to verification
  • A dedicated reporting workflow with SITREP, utilization, and cost outputs (including PDF/HTML/CSV export)
  • A field workflow for work execution, status updates, evidence capture, and synchronization
  • Cross-surface visibility between command users (Fieldcraft) and field users (Endymion)
  • An AI operations assistant that can:
    • Generate SITREP-style summaries from current mission context
    • Answer operational questions using available data
    • Suggest priority actions with explicit grounding to mission information

Instead of relying on static reports, the platform keeps mission state visible as operations evolve.

How we built it

We implemented the product as two connected layers:

  • Fieldcraft (Command Layer): planning, dispatch, tracking, reporting, and verification
  • Endymion (Field Layer): field task execution, status updates, and sync-aware operations

Technical approach:

  • A shared mission data model across command and field experiences
  • A map-first interface for situational awareness and operational coordination
  • An AI sidecar constrained to mission context with grounded response behavior
  • A modular backend with deployment paths for separate web surfaces and API services
  • Offline-aware queue/sync behavior to preserve field workflow continuity when connectivity is limited

For demoability, we prioritized one complete operational loop: incident/planning packet → assignment/dispatch → field status/evidence → verification/timeline → reporting + AI SITREP output.

Challenges we ran into

  • Scope control: emergency ops software is broad; we focused on one high-value workflow instead of a wide but shallow feature set.
  • Realism vs speed: we needed a demo that judges could understand quickly while still feeling credible to actual operators.
  • AI usefulness under pressure: in high-stakes workflows, AI must reduce cognitive load. We shaped prompts and behavior around operational questions, not generic chat.
  • Dual-app multi-user design: command and field users have different needs; making both surfaces coherent required careful UX and data-model alignment.

Accomplishments that we’re proud of

  • Built a domain-informed prototype with an end-to-end mission workflow, not disconnected screens
  • Delivered a command/field architecture that mirrors real operational roles
  • Implemented AI support for SITREP and operational Q&A with grounded context behavior
  • Added map-centric visibility and workflow state progression across planning, dispatch, mobilization, and verification
  • Embedded offline-aware behavior into field operations instead of treating it as an afterthought
  • Shipped independent deployable services for command web, field web, API, and supporting media hosting

What we learned

  • In emergency operations, summarization + prioritization + explanation creates more value than fully autonomous AI.
  • Product decisions are stronger when anchored in operator workflows instead of generic dashboard patterns.
  • A narrow, complete workflow demonstrates more credibility than a long feature list.
  • Shared context between command and field roles is foundational to better coordination.

What’s next for Fieldcraft/Endymion

Near-term roadmap:

  • Expand integrations for logistics/asset systems and operational communications
  • Strengthen mission risk flagging and SLA-risk visibility
  • Improve mobile-first field UX for responders and technicians
  • Extend multi-team coordination workflows across agencies and contractors

Why this matters

Fieldcraft/Endymion is built to improve operational clarity when consequences are real. Our long-term vision is a modern operational backbone for disaster response where teams can coordinate faster, act earlier, and make better decisions under pressure.

Judge FAQ (Credibility + Risk)

  • How is AI kept trustworthy? Responses are constrained to mission context and designed to prefer explicit uncertainty over unsupported claims.
  • Does AI replace operators? No. The assistant is used for summarization, prioritization support, and Q&A; humans remain decision-makers.
  • How mature are external integrations? The current prototype demonstrates modular integration pathways; some adapters are MVP/mock-first and are being hardened in pilots.
  • What happens with limited connectivity? Field workflows are designed to continue with offline-aware queue/sync behavior, then reconcile on reconnect.
  • Can this be deployed in separate environments? Yes. The architecture supports distinct web surfaces and API deployment paths for staged rollout.

Built With

Share this project:

Updates