The same secure core, wearing your industry's vocabulary

The modules

Each one has a page describing the operation it is for. The module is the software that would make that page true.

• Aviation — aircraft airborne and on stand, with the channel list indexed by tail number
• Maritime — berths, tenders and bridge-to-shore, on links that drop and come back
• Transportation — runs, depots and driver hours against the traffic on the channel
• Construction — sites, trades and permits, where the crew changes weekly
• Manufacturing — lines, shifts and stoppages, in a building that eats radio
• Hospitality — rooms, covers and requests, quietly, in front of guests
• Emergency response — incidents, units and status, where being wrong is expensive
• Retail — floor, stockroom and tills across a chain

What a module may and may not do

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.

• May register a new message kind in the shared protocol, so every client agrees what it is before anyone sends one
• May add screens, panes and list views, and read from your own systems
• May not touch the crypto. A module's data is sealed by the same code path, with the same channel key, as a voice frame
• May not introduce a new algorithm or library — X25519, HKDF-SHA256 and AES-256-GCM are the entire permitted set, on every platform
• May not ask the server to read content. If a feature only works when we can see the payload, it does not ship as a module

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.

How they reach you

Modules are enabled per organisation rather than compiled into everybody's app.

• Enabled per org. A hotel does not carry a flight board it will never open
• The core stays one codebase. Modules are layers on it, not forks of it, so a security fix reaches every industry at once
• Composes with white label. Your branding and your industry's screens are separate switches — have either or both
• Composes with on-premise. A module is part of the same deployment, with the same gaps documented on that page

Which one gets built

Honestly: by who asks, and how specifically. A module is worth building when somebody can describe the shift it has to survive — not the feature list, the shift.

• What your people do when the network drops for twenty minutes
• Which system already holds the data the module would show
• Whether dispatch and the field need different screens or the same one
• What currently gets said on the radio that should not have to be