3rd Place at Modern Day Marine 2026: Building Real-Time Dispatch Translation in Three Days
May 4, 2026
Last week I took an Amtrak train to D.C. for the Marine Corps Logistics Command (LOGCOM) AI Forum Hackathon, held in conjunction with Modern Day Marine 2026. Eighteen teams started. Eight made it past the semi-finals (it was supposed to be seven but there was a tie). My team, ERMP, came in third in the final round. I'm glad with the progress we made and I'd like to share on this platform what we built and what I'd want to do differently should any of it ever leaves the prototype stage.
What the hackathon actually was
The MARADMIN that went out a few weeks before the event called for solutions to “Marine Corps logistics and sustainment use cases” so things like contested logistics, maintenance, supply chain, expeditionary operations. Sponsored by the Deputy Commandant for Installations and Logistics. Judging happened across two rounds against a Demonstration Readiness Level (DRL) rubric: DRL 1 was concept-level, DRL 2 was a working prototype with representative data, DRL 3 was an end-to-end demo in a mission-relevant scenario with measurable performance and a clear path to operational testing.
The first round brought 18 teams down to 8 through a five-minute pitch to the judges with a demo (if time allowed). The second/final round was a similar set-up but with more judges, additional 3 minutes (making the total 8 minutes), wider variety of judges from high-ranking military officials, government, industry, and academia, and of course the end result of this round being you could be in the top 3 teams. We successfully made it through the first round and ended up coming in third place after the second round.
The team was five people: two active-duty Marines (one was the team lead and the other was a senior contributor), one retired US Army Lieutenant (and systems engineer) who did most of the coding, a senior consultant who works alongside military personnel in emergency communication centers and acted as the SME for topics involving emergency services on military bases, and me on narrative, problem-framing, and research.
The problem we picked
Our use case on the outside does not seem like classic logistics. It was installation protection specifically, the Public Safety Communications Centers (PSCCs) on Marine Corps installations. These are the 911 dispatch centers for bases. They handle medical, fire, and security calls from a population that includes service members, multilingual dependents, civilian contractors, allied forces, and local national employees. A globally diverse population calling 911 in a crisis.
Our team SME laid out the operational gap for us in a statement of need that I helped shape into the narrative we presented from. The short version is:
When a non-English speaking caller reaches a PSCC, the current procedure is to conference in a third-party human translator (Language Line). Industry data puts that connection time at 60–180 seconds, assuming an interpreter for the right dialect is on duty. National Emergency Number Association (NENA) standards require 90% of 911 calls to be answered within 15 seconds and dispatched within 60. Connecting a translator alone blows past the dispatch SLA before anyone has said anything useful.
The compounding problem is location data. Over 80% of 911 calls now originate from mobile or VoIP, where Phase II Automatic Number Identification (ANI) and Automatic Location Identification (ALI) data is frequently degraded, delayed, or absent. That means in a growing share of calls, the dispatcher is fully dependent on the caller's verbal communication to determine where the emergency is. If you can't understand the caller, and you don't have ALI, you have an untraceable, unresolvable emergency in progress.
And the dispatcher's most important pre-arrival job telling a bystander how to do CPR, how to apply a tourniquet, how to shelter in place also requires being able to talk to them.
Reframing logistics
I want to flag the reframe because it was deliberate. The hackathon was officially about logistics and sustainment. Dispatch translation isn't logistics in the contested-supply-chain sense. The framing revolved around the idea that installation protection is indeed part of logistics command's mandate, and since the LOGCOM Forum's framing was about applying AI to real, mission-relevant Marine Corps problems, we were able to connect the two by making the case that PSCC translation was exactly the kind of problem the forum was looking to surface because it's high stakes, currently solved with high-latency legacy tooling, and unblocked by a real AI capability shift. The judges were clearly impressed by the idea, we believed that this idea was relevant from the get go and could be solved using analytics and AI.
I think this is worth a sidebar for anyone doing one of these in the future, the headline track matters less than your ability to show that the problem is real, the AI delta is meaningful, and a Marine somewhere will actually use what you built. We had active-duty Marines on the team who could speak to the operational reality.
What we built
The flow: a call comes into a phone number with Programmable Voice and Media Streams attached. Audio streams to OpenAI Whisper for transcription with automatic language identification. The transcript runs through GPT-4o for triage classification could be medical, fire, or security this gives the dispatcher a category before they get a full translation. ElevenLabs handles the synthesized voice on the way back to the caller in their language, including pre-arrival instructions. The dispatcher then sees a live transcript on a React + Vite web console. Everything ran on Replit, which is what let us iterate at the speed we did.
The before/after we walked the judges through was a Mandarin-speaking dependent witnessing a cardiac arrest at Camp Pendleton base housing. With Language Line in the loop, EMS gets dispatched at the three-minute mark, on scene at seven minutes and fifty seconds, no bystander CPR. With our system, we showed (using powerpoint slides) the difference with the dispatcher getting the language identified at one second, the panicked transcript at six seconds, EMS dispatched at twenty-two seconds, and bystander CPR cued by the system at one minute ten. Survival probability for an out-of-hospital cardiac arrest drops roughly 10% per minute without compressions. The math on those two timelines is the whole pitch.
My role on the team
My role was crafting our narrative, making sure the technical work we did translated to the presentation in a way the judges could comprehend, understand and relate to.
Our emergency services SME gave us the operational picture from her side and I structured it into the BLUF / Vulnerability / Time-is-the-Enemy framing that ran through our pitch deck. The problem framing: language barrier compounded by ANI/ALI degradation, time-as-adversary, pre-arrival instructions as the dispatcher's most important deliverable was where I spent most of my research hours. I sourced and verified the NENA standards, the 60–180 second translator connection benchmark, the >80% mobile/VoIP origination figure, and the cardiac arrest survival decline statistic. Every number in the pitch was something I could point to a source on.
On the build side, my contribution was evaluation rather than code. I helped sanity-check the Whisper outputs on different language samples and the GPT-4o triage classifications against the operational categories a 911 dispatch system would actually use. The team lead and the retired-Army systems engineer drove the engineering and my job was to make sure that when an executive judge asked “why this, why now, what does NENA say about it,” I had an answer that didn't fall apart on a follow-up.
How I would push this project forward
A working Replit prototype with Twilio, OpenAI, and ElevenLabs in the loop is great for showing what's possible in three days. It is not a thing you can deploy to a Marine Corps PSCC. In my opinion, the path from where we ended to getting something that can actually serve emergency calls is dominated by concerns that have very little to do with the model layer and a lot to do with the data layer underneath it.
A few things I'd want to think through if any of this gets continued:
Audit trail design Every translation is potentially evidence. If a dispatcher acted on a transcript and the outcome was bad, someone is going to ask exactly what audio came in, what transcript came out, what model produced it, what the confidence score was, and who saw it on the dispatcher's screen. I'd want to design that schema before I picked a model.
Criminal Justice Information Services (CJIS) aligned retention The “Beyond the Prototype” slide gestured at this and I'd want to actually nail it down: audio probably transient, transcripts encrypted at rest, retention windows configurable per CAD policy, and clean deletion semantics that you can prove to a CJIS auditor.
Long-tail languages Being able to handle dialect distribution at a specific installation is key, Camp Pendleton's caller base looks different from Kaneohe Bay's, which looks different from another base. The right technical answer is probably installation-specific fine-tuning on dialect data, which means you need a data collection and labeling pipeline that respects the population's privacy. That's a project unto itself.
I'm flagging these because as a security engineer this is where my mind goes for such a project. How do we keep an audit trial and I always ask “what about the data? how do we store? process? clean? etc” they're the kinds of things that turn a hackathon prototype into a product fit for use by the US military.
What's next?
I'll update this post (if I am allowed to) if I hear anything back from the hackathon organisers about pushing this idea forward as a full fledged product.
If you want to follow what comes next, the LOGCOM post recognizing the top teams is here, The MARADMIN that started it all is on marines.mil.