.png)
.png)
During planning sessions at Project Convergence Capstone 6 (PCC6), planners captured tasks, open questions, and key assertions by hand so they could carry forward into the next round of planning.
Legion engineers embedded with the cell saw an opportunity. Nobody had written that work into a software requirement, because to the planners it was simply part of the job.
Why do some operational workflows stay invisible until deployment?
Some operational work stays invisible until deployment because requirements gathering captures what users know how to describe: the products they own, the processes with names, the steps written into a standard operating procedure.
What it can miss is the work nobody thinks of as a discrete task: reconstructing a planning conversation, tracking assumptions made against operational facts, carrying an open question into the next session. It is time-consuming and repeated, and to the person doing it, simply part of the job.
Some requirements only become visible when you watch the work being done.
What did planners at Project Convergence Capstone 6 need?
Planners at PCC6 needed more of the planning conversation to survive the session. Legion embedded alongside the Future Operations (FUOPS) planning cell of 4th Battalion, 10th Special Forces Group. PCC6 was a division-scale U.S. Army modernization event at the National Training Center focused on validating Next Generation Command and Control (NGC2).
Like most planning, much of the work happened through conversation. Decisions, assumptions, risks, and tasks emerged in working groups and huddles before they made their way into an order. That context was spread across notes, documents, chat, and individual memory.
Planners were manually capturing tasks, open questions, and key assertions so they could feed forward into Courses of Action (COAs). The opportunity was straightforward: capture and preserve more of that context without requiring planners to reconstruct it by hand.
How did Legion build a planning capture App in under 24 hours?
Legion built the planning capture App in under 24 hours because the need surfaced during the exercise itself, with engineers working alongside the planning cell.
The Planning Discussion Capture and Synthesis App was designed to capture planning discussions for later review and identify tasks, open questions, and key assertions for follow-on planning, reducing the reconstruction that would otherwise fall to manual notes and individual memory. It ran on tactical SIPRNet, delivered over the cell's tactical local area network (TACLAN).
Legion could move quickly because the App was built inside the Space the cell was already using. It inherited the deployment's existing data connections, permissions, and approval gates. There was no new environment to stand up or new version of the software to field. Nothing about the deployment changed except what it could do.
Read the PCC6 field report for the full account of the deployment, the workflow, and the environment it ran in.
How does building during operations change software delivery?
Building during operations changes when a requirement can still be answered. PCC6 reinforced a simple point: requirements don't stop arriving once software is deployed. Some only become visible when users are doing the work.
In a traditional software model, a need discovered during an exercise enters a backlog and competes with every other requirement for a future release. By the time the capability reaches the user, the exercise that surfaced it may be long over.
Legion Packs, the role-based capability bundles Legion ships, carry this kind of work as governed, auditable capability, so an App built overnight arrives with the same permissions, attribution, and audit as everything else in the deployment.
At PCC6, the measured result was delivery speed: less than 24 hours from identifying an operational need to a working capability on tactical SIPRNet. The exercise did not measure changes in planner time or planning quality, so we don't claim either.
The useful standard is adaptability: deployed software that can absorb a requirement it was never built for.
Who builds the next one
Legion engineers built this one because they were embedded with the planning cell when the need surfaced. The Legion software underneath made it possible to turn that need into a working capability in less than 24 hours.
Building every new App with Legion engineers does not scale. The model that does is customers building and adapting capabilities themselves. That matters because many of the workflows a staff will need won't be identified in advance. They'll emerge as users encounter new problems and find better ways to do the work.
Legion engineers built this one. The customer builder builds the next one.
The Operations Officer Pack carries this same principle forward: helping staff preserve context across shifts, understand what changed, and act on what matters next. See the Operations Officer Pack.