I spend my days making military command-and-control systems talk to each other. The systems on either side of an interface might be a modern containerized service and a program of record fielded fifteen years ago — and neither one gets to demand the other change. When redeployment is measured in accreditation cycles rather than CI runs, the API contract stops being documentation and becomes the most durable artifact you own. That constraint taught me more about interface design than any greenfield project ever did.
## Contracts outlive implementations
Every implementation on both sides of our interfaces has been rewritten at least once. The contract hasn't. Services get rehosted, languages change, teams turn over — but the messages on the wire persist, because dozens of independently-funded programs have built against them. Once you internalize that the contract will outlive your code, you design differently: you stop optimizing the interface for your current implementation's convenience and start optimizing it for the next decade of strangers who will implement against it.
## Explicit beats clever
Defense messages carry no clever defaults. If a field can be unknown, there's an explicit UNKNOWN value — not an absent key whose meaning each consumer guesses at. It looks verbose next to a minimal JSON API, and it's saved us repeatedly: when a track's identity is 'unknown' versus 'not reported' versus 'assessed hostile,' the distinction can matter operationally. The lesson generalizes — every ambiguity you leave in a contract becomes a divergence between consumers, and you'll discover it at integration time, which is the most expensive possible moment.
## Versioning without breaking the fleet
You cannot coordinate a fleet-wide upgrade across programs with different budgets, contractors, and schedules. So every change is additive: new optional fields, new enum values gated behind capability flags, never a repurposed field or a changed semantic. We assume every version we've ever shipped is still live somewhere — because it is. 'Deprecated' means 'we still parse it correctly and will for years.' It feels glacial coming from web development, but it's what lets 8 platforms interoperate in production without a single synchronized release ever having happened.
## Interoperability is a test suite, not a promise
Two teams reading the same spec will build incompatible systems — reliably. The spec is where agreement starts, not where it's proven. What actually catches divergence is executable conformance: shared message fixtures, golden encodings, and integration events where real implementations exchange traffic. Every serious interoperability bug we've found was a case where both sides were 'compliant with the document' and still disagreed. Budget for the test corpus as part of the contract, not as a nice-to-have.
## Takeaways
You probably aren't integrating warships. But if your API has consumers you can't force to upgrade — public APIs, partner integrations, mobile clients on old versions — you're under the same constraint at a smaller scale. Make unknowns explicit, change contracts additively, assume every version ships forever, and prove compatibility with fixtures instead of prose. The disciplines defense integration forces on you are just what honest API ownership looks like with the deadline pressure removed.