
Defense systems don't talk to each other. This isn't news to anyone who has worked integration on a real program. You have legacy systems built decades ago sitting alongside modern systems from different contractors. You have open standards that aren't quite compatible with other open standards. And somewhere in the middle, engineers are writing glue code to make it all work.
That glue code is expensive. It takes months to develop, introduces bugs at every turn, and when requirements change or a new system enters the picture, you do it all over again. The pattern is depressingly familiar to anyone who has lived through a major integration effort.
MOSA is now mandated, and JADC2 requires systems across all domains to share data seamlessly. The policy vision is clear. But the engineering reality hasn't caught up. The tools we have for specifying interfaces and generating integration code still demand too much specialized expertise, and they don't scale to the scope of what MOSA and JADC2 actually require.
We built Flex to address this gap.
Tangram Flex has been developing and using Flex since our founding in 2018. It has been central to our work on defense integration projects for six years, and we've refined it continuously based on what we learned applying it to real systems. We are now making Flex openly available.
Anyone can use it. Anyone can build tools around it. Anyone can publish about it. Our hope is that this becomes the first step toward Flex evolving into the open standard of choice for interface specification.
Flex is a specification language for defining message data types and transform functions. If you need to describe the structure of messages that pass between components and specify how to convert between different formats, Flex is designed for exactly that job.
The syntax will look familiar to anyone who has written C++ or Java. You define a message type with its fields, like this simplified example:
message struct PositionUS {
latitudeDegrees: float64;
longitudeDegrees: float64;
altitudeFeet: float32;
}
Then you define transforms that convert between types:
transform US_to_Metric(i : PositionUS) -> PositionMetric {
PositionMetric {
latitudeRadians = i.latitudeDegrees * degrees2radians;
longitudeRadians = i.longitudeDegrees * degrees2radians;
altitudeMeters = i.altitudeFeet * feet2meters;
};
}
That's the core idea: message types and transforms. From these primitives you can specify complex interface adapters that connect systems built to entirely different standards.
These examples are super simple, of course. Flex comes into its own when describing message sets with hundreds of fields, and complex back and forth protocols.
Most interface specifications exist today as PDFs or Word documents filled with pages of natural language description. Working from these to build systems is tedious and error prone. Flex shines here. Modern AI has been good at extracting structure from adhoc documents. You can point an LLM at an existing interface control document (ICD), generate Flex output, and then validate the result. Errors and ambiguities show up quickly.
The barrier to getting started is lower than you might expect.
Flex has roots in two DARPA programs that shaped how we think about system integration and cyber assurance. Understanding that heritage helps explain why Flex works the way it does.
The first is HACMS, High-Assurance Cyber Military Systems, which ran from 2012 to 2017. HACMS had a bold premise: use formal methods to build software that is provably correct and secure. Not just tested, but mathematically proven.
Galois, Tangram's sister company, was a key performer on HACMS. The flagship demonstration involved Boeing's Unmanned Little Bird helicopter. A red team of professional penetration testers tried to compromise the formally verified system and couldn't. The software held. Meanwhile, the same red team had previously compromised the baseline version of that aircraft completely, to the point where they could have crashed it or diverted it anywhere they chose.
HACMS proved that mathematically rigorous software could work in military systems. But it also revealed a practical challenge. The techniques required deep expertise in formal methods, and you couldn't realistically staff every integration project with theorem-proving specialists.
The second program was SoSITE, System of Systems Integration Technology and Experimentation. Where HACMS focused on assurance, SoSITE focused on connecting heterogeneous platforms through open architectures. The vision was plug-and-fly modularity across manned and unmanned systems.
SoSITE produced STITCHES, a powerful integration toolchain that could automatically generate adapters between systems using different standards. The key insight was compositional transforms: if you know how to convert from format A to format B, and from B to C, you can chain those transforms together. Linear effort achieves quadratic interoperability. But like HACMS, STITCHES often required particular expertise to apply effectively.
When we founded Tangram in 2018, we designed Flex to combine both lineages. We wanted the rigor of HACMS and the compositional power of SoSITE, but we wanted it accessible to ordinary software engineers.
That goal led to two design priorities. First, simpler usability. The syntax needed to be familiar, and the concepts needed to be learnable without a formal methods background. Second, cleaner semantics. The language needed to be precise enough that tools could reason about it reliably and generated code could be trusted.
The result is a language where the rigor lives in the design itself, not in demands placed on the user. Engineers write straightforward Flex specifications, and toolchains can deliver assurance.
The practical benefits flow directly from those design choices.
Speed is the most visible one. Integration tasks that took months can take days. One organization we worked with expected a multi-month development effort to bring a new open architecture standard to their existing systems. With Flex and the Tangram Pro tooling to produce code, they had working code in days. That kind of acceleration changes what's possible within realistic program schedules.
Accessibility is important. You don't need formal methods specialists on every project. Engineers who know C++ or Java can become productive with Flex quickly. This is essential when MOSA compliance is mandated across the entire defense industrial base. You simply cannot mandate something that only PhD-level practitioners can operate.
The clean semantics pay off in trustworthy code generation. Generated adapters behave as specified, with no undefined behavior leaking through. This is the HACMS heritage showing up in everyday practice.
We have a set of powerful Flex tools available, but now that Flex is open, anyone can develop tooling around it. Or just use the Flex interface description as a specification in your standard development toolchain. It provides a precise description that can be leveraged for test development and verification.
Compositionality means that transforms will chain predictably. You can build complex integration pipelines from simple pieces and have confidence the composition will work. This is the SoSITE heritage showing up in everyday practice.
Ownership addresses a concern we hear constantly from program offices. Already, Flex specifications and the code generated from them belong to you. There's no vendor lock-in, which aligns directly with MOSA philosophy. With Flex now open, there is even less risk of lock-in.
Here’s one application we have had success with: Flex enables cyber hardening at the interface level. Interface code is a primary attack surface, and Flex specifications enable the generation of message filters that validate inputs before they reach your systems. The HACMS program demonstrated that message filtering could protect legacy systems from known vulnerabilities without changing a line of their existing code. Flex is the way to put that into practice today.
Flex is now available for anyone to use. Documentation lives at flexlang.org, and you can write Flex directly in the browser using the Flex Editor in Tangram Pro.
If you have questions or want to explore what Flex can do for your program, reach out to us at hello@tangramflex.com. We're genuinely interested in how the community uses this and where it needs to go next.
The integration problem isn't going away. The systems we field will only get more heterogeneous, and the pressure to connect them will only intensify. Flex is our contribution to making that challenge manageable.

