the problems addressed
Multi-domain operations fail at the seams — not because the systems don't work, but because they were never built to share a common understanding of what a commander actually intends. Every service, every domain, every coalition partner brings its own information model. When the fight starts, those models collide. Coordination breaks down. The commander's intent doesn't survive the handoff.
The standard answer has been integration: build more interfaces, add more translators, connect more systems. MDO Intent takes a different approach. Before you can integrate systems, you need an operational information model that defines what commander’s intent means — precisely enough to be machine-readable, flexibly enough to survive any communication standard, and persistently enough to carry from the order all the way to the outcome. That model is the DSL: a Domain-Specific Language for commander's intent, developed through DARPA-funded C2 ontology research and demonstrated in coalition environments across multiple domains and services.
-
Defense programs have adopted Agile development without solving the upstream problem: you can't define a user need when no one owns the whole picture. The result is iterative development of the wrong thing.
-
Formal upper ontologies provide rigorous structure for knowledge representation, but their generality is also their limitation. Mapping commander's intent onto a domain-neutral framework requires so many layers of abstraction that operational meaning gets lost in translation. The DSL is purpose-built for C2 — it preserves formal rigor while staying grounded in how commanders actually think and decide.
-
More structure doesn't mean less judgment — it means judgment applied to the right problems. When the information architecture handles the coordination layer, commanders get back the cognitive bandwidth that's currently consumed by reconciling conflicting data, chasing track provenance, and managing seam friction. The goal of the DSL isn't to replace the art of command. It's to clear the ground so the art can actually happen.
-
A common operational picture is only as good as the data feeding it. When track information has no verifiable chain of custody back to the sensor that generated it, commanders are making decisions on data that looks authoritative but may already be wrong. No amount of system integration solves a provenance problem.
The tire swing is a well-known agile development metaphor for requirements failure in complex systems — each stakeholder builds what they understand, not what the cross-functional, multi-domain teams and their commanders need. In multi-domain operations, the result isn't just a bad product. It's a mission risk.
Why this problem demands a multi-disciplinary background
Most people who work on C2 architecture came from one discipline. They see the problem through that lens — the operator's lens, or the engineer's lens, or the researcher's lens. The MDO interoperability gap doesn't live inside any of those disciplines. It lives between them. Solving it required someone who had spent serious time in each.
Nineteen years as a Surface Warfare Officer gave me the operator's seat — learning what commanders actually need to decide, under what conditions, with what information. Seven years in requirements development and test and evaluation gave me the engineer's seat — writing specifications that had to reflect real operational stress, not just test event performance. DARPA-funded research gave me the formal methods seat — developing the ontological structure that makes intent persistent and verifiable. Coalition demonstrator work at NATO ACT gave me the integration seat — proving the architecture against real systems, real partners, real constraints.
No single one of those seats produces the DSL. All of them together do.
The pattern is documented. The architecture exists.
If you're working on C2 interoperability, requirements development, coalition integration, or defense acquisition reform — read the blog. If what you find there matches a problem you're trying to solve, get in touch.
Contact
Interested in working together? Fill out some info and I will be in touch as soon as I can. I can’t wait to hear from you!