Important scope note before anything else: export control classification is a legal determination specific to your programme, jurisdiction and counterparties. Nothing here is legal advice, and no software vendor — including us — can make that determination for you. This article covers the engineering consequences once your compliance function has told you what the constraints are.
Aerospace and defence programmes routinely hit a wall that has nothing to do with the physics: the tool they want to use cannot be used the way they need to use it. Understanding why, and what the engineering response looks like, saves a great deal of wasted procurement effort.
Where commercial simulation collides with controlled work
Who may access the technical data
Export control regimes generally govern access to controlled technical data by foreign persons, wherever they are located. That has direct consequences for simulation: vendor support engineers examining your model, cloud-hosted solving, and offshore development teams all become questions rather than conveniences.
Connectivity assumptions
Much modern engineering software assumes network access — licence servers, cloud bursting, telemetry, automatic updates. In a classified or air-gapped environment those assumptions fail, and workarounds are sometimes not permitted by the licence terms.
Deployment restrictions
Commercial licences typically prohibit embedding the solver in software you distribute. If your programme needs simulation inside a delivered system — a design tool handed to a partner, or an onboard analysis capability — licensing usually rules it out regardless of technical fit.
Long programme lifecycles
Defence programmes run for decades. Commercial software versions are supported for years. Reproducing an analysis from twelve years ago, with the same solver version and the same results, is a genuine requirement that commercial support lifecycles do not accommodate.
In most sectors, simulation tooling is a purchasing decision. In controlled programmes it is an architecture decision with compliance consequences.
What owning the solver changes
| Constraint | With commercial software | With an owned solver |
|---|---|---|
| Third-party data access | Vendor support may need your model | Nobody outside the programme sees it |
| Air-gapped operation | Licence server dependencies | Designed for it from the start |
| Embedding in deliverables | Usually prohibited | Your software, your terms |
| Long-term reproducibility | Tied to vendor support life | You archive the exact source |
| Cleared-personnel-only development | Not applicable | You control who touches it |
| Auditability of methods | Proprietary internals | Fully inspectable |
Engineering requirements this imposes
A solver intended for a controlled environment is architected differently from day one:
- No network dependencies of any kind in the execution path — no licence checks, no telemetry, no update pings.
- Fully offline build — all dependencies vendored and archivable, so the code can be rebuilt in ten years without internet access.
- Deterministic, reproducible output — the same inputs must produce the same results on the archived toolchain.
- Complete provenance recording — solver version, inputs, assumptions and environment captured with every result.
- Physical-media update path — installation and patching without connectivity.
- Documented numerical methods — because results must be defensible in review, not merely produced.
Long-term reproducibility is the requirement most often designed in too late. It means archiving not just source but the entire toolchain — compiler versions, library versions, build configuration. A solver you cannot rebuild identically in a decade cannot support a programme that runs that long.
Verification matters more here, not less
Owning the solver removes vendor validation as a fallback. Everything must be established and documented by the programme:
- Verification — method of manufactured solutions confirming observed order of accuracy.
- Validation — comparison against analytical cases, published benchmarks, wind tunnel or flight test data, with documented error metrics.
- Uncertainty quantification where the programme requires it.
- Documented limits of applicability — the conditions under which results are trustworthy, stated explicitly.
- Regression suite proving behaviour has not changed across builds.
We should be precise about scope here: this evidence supports your engineering and certification processes. Any formal tool qualification — under DO-330 or an equivalent framework — is led by your certification authority and your programme, with the software supplier providing the artefacts. A vendor claiming to deliver qualification itself is overstating what a supplier can do.
A realistic path
- Get the compliance determination first. What is controlled, who may access it, and what deployment shapes are permitted. Everything else follows from this.
- Narrow the physics ruthlessly. Owning a general-purpose CFD capability is rarely justified; owning the specific analysis your programme repeats often is.
- Define validation cases up front, with acceptance criteria agreed by the engineering authority.
- Design for the environment — offline, reproducible, archivable — rather than retrofitting.
- Plan knowledge retention. A solver understood by one engineer is a programme risk over a twenty-year lifecycle.
Working on a programme where tooling constraints are shaping your simulation strategy? Tell us the engineering requirements — and involve your compliance function early, because it determines what is even possible. See our CFD solver service and aircraft design software service.