Modules add the screens, data and integrations one operation actually works with — rides, custody, calls, loads, shifts, crossings and live facility boards — on top of the channels, PTT and encryption every customer gets. The common kits ship now; vendor-specific adapters remain customer-led work.
One shared set of capability kits is assembled into four dispatch modes. Other industries can enable the same kits without carrying a fork of the product.
This is the load-bearing decision. Seven industries each inventing their own way to move data would mean seven encryption paths, and the security of the product would become the security of whichever one got the least attention.
That last constraint bites, so it is worth being concrete: an aviation module cannot have our servers correlate encrypted positions against a flight-data feed, because our servers cannot read the positions. Correlation happens on the device, or in your own console where the keys are. Some integrations are harder this way and a few are not possible at all — we would rather say which before a contract than after one.
Modules are enabled per organisation rather than compiled into everybody's app.
The reusable product layer is built. The next work is a named adapter or preset, chosen by a real operation and the system it already uses — not by adding a vague industry tile.
Name the PMS, ELD, hospital interface or dispatch workflow already in place. We will say which shipped kit fits, what adapter is missing, and whether the encryption boundary makes any requested part impossible.