# Defence and space > Mission software built entirely inside your boundary. Source: https://neuralinverse.com/industries/defence/ --- [Industries / Aerospace and defence](https://neuralinverse.com/industries/) # Mission software built entirely inside your boundary. For firmware, FPGA and software teams on closed programmes. Policy, models and records stay on your network. Standards MIL-STD-882E · ECSS-E-ST-40C · DO-254 Firmware tools Arm GCC, Arm Compiler 6, IAR, OpenOCD, J-Link FPGA tools Verilator, GHDL, Yosys; Vivado, Quartus, Libero, Radiant Models Served inside your network Deployment Self-hosted, your cloud or air-gapped What your team gets ## Separate programmes, disconnected networks, named people. Govern features are in use today. Domain modules are pre-release; their state is listed under Tools and formats. - **Fully disconnected:** Govern is designed to need no internet at runtime, installed from an offline bundle with models you host. Prove it on a host with no route out before you rely on it. - **Programme separation:** Each programme can be its own organisation, with its own members, policy and audit chain, kept apart by the database itself. - **Agents under your rules:** Allow, ask and deny rules for commands, files, network, pushes and models. The firmware and FPGA templates keep device programming and bitstreams with a person. - **Signed, offline policy:** Policy reaches each machine signed, keeps working offline for the grace period you set, and can be revoked for one person or the whole organisation. - **Named accountability:** Every action is tied to a person. A requester can never approve their own request, and signing an approval needs re-authentication. - **Records your auditor can check:** The audit log and its signed exports are verified offline with a standalone tool, without access to your systems. Who uses it ## For the engineers on the programme and the people who answer for it. - **Embedded software engineers:** Build, test, flash and debug mission firmware with your compilers and probes. - **FPGA engineers:** Write, simulate and synthesise RTL, with timing and utilisation beside the code. - **Programme security officers:** Set agent policy, approved models and emergency suspension for each programme. - **Safety and quality engineers:** Approve controlled changes and export the audit record for reviews. Tools and formats ## What the modules handle, and how far each is verified. The Embedded and HDL modules drive the toolchains your programme already uses, inside your network. - **Firmware projects:** Keil, IAR and STM32CubeIDE projects imported into CMake; builds of a CMake preset with a Flash and RAM report; host unit tests. Built and tested on recorded tool output; not yet run against IAR or Keil. - **Flash and debug:** Flashing after a confirmation; debugging with peripheral registers from the SVD, RTOS awareness, fault decoding and a serial monitor. Running an image in QEMU is verified against QEMU 9.1.1; nothing has been run on a board. - **Static analysis:** Cppcheck findings, including MISRA C:2012, in the Problems view. Built and tested on recorded tool output. - **FPGA, open flow:** Lint, simulation, cocotb testbenches, formal verification, waveforms, synthesis and place and route. Verified on Linux. Programming a board is not yet run. - **FPGA, vendor flows:** The vendor tools driven in batch mode, with their messages and timing and utilisation reports in the same views. Kit shipped or modelled: not yet run against the vendor tools. Domain modules are pre-release. Nothing is verified by a customer yet, and nothing is verified on Windows. Do not rely on a capability for production work until it is verified for your tools, versions and operating system. Product names belong to their owners. How a change moves ## A person decides before anything leaves the desk. 1. Propose An engineer or agent drafts a change to mission software. 2. Verify Your qualified tools build, check and test it. 3. Approve A push to the programme's release branch waits for a named approver. 4. Record Change, results and approval kept together in the audit record. Standards ## Evidence for your safety case. The certification is yours. - **MIL-STD-882E:** Evidence toward MIL-STD-882E: changes to safety-related software with their approver and reason. Hazard analysis stays in your safety process. - **ECSS-E-ST-40C:** Evidence toward ECSS-E-ST-40C: change records, test results and approvals for your software reviews. - **DO-254:** Evidence toward DO-254: each implementation run kept with the commit it came from, and each RTL change with its review and approval. Neural Inverse provides evidence toward these standards. Certification stays with your organisation and assessor. Products used [Neural Inverse Build → Editor, Agents and CLI with the domain tools your engineers need.](https://neuralinverse.com/build/)[Neural Inverse Govern → Policy, approvals and audit for every AI tool your teams use.](https://neuralinverse.com/govern/) Product names belong to their owners. Related industries[Avionics](https://neuralinverse.com/industries/avionics/)[Semiconductors and FPGA](https://neuralinverse.com/industries/semiconductors/)[Telecommunications](https://neuralinverse.com/industries/telecom/) ![](/photos/team.jpg) ## Talk to our team. Neural Inverse is available by request. We work with your engineering, security and procurement teams from the first conversation. [Request access](https://neuralinverse.com/contact/?topic=access)[Contact us](https://neuralinverse.com/contact/)