Trust & safety
The answers a reviewer needs, with the date we last checked them.
This page is about how our software behaves, not about the industry. Every statement below is dated, because an undated security or safety claim is not something you can hold a vendor to — and because a claim that was true of last quarter's build is not a claim about this one.
Full review of this page
Approvals & certifications
What we do not hold.
No certification, accreditation, authorisation, integration or customer deployment is held or claimed by KBM Air. This is the complete list, and it is first on the page on purpose.
-
FAA certification, approval or acceptance
None held, none applied for. No aviation authority has certified, approved or accepted any of this software, and none of it is approved for operational use.
-
Department of Defense authorisation to operate
Not held. No accreditation, authorisation or reciprocity of any kind exists for any KBM Air product.
-
SOC 2 Type I or Type II
Not held and the programme has not started. It is a costed roadmap item driven by a real procurement requirement, which is a different thing from "in progress".
-
FedRAMP authorisation
Not held and not started. Alignment work would follow SOC 2 and only if a federal deployment required it.
-
ISO 27001, HIPAA or PCI attestation
None held. The current products do not process health or payment data.
-
Any live system integration
No connection exists to any airline operations, crew, maintenance, reservation, distribution or air-traffic system. Adapters are written to published schemas and run as labelled simulations. No partner relationship is held or implied.
-
Any customer deployment
No product is running in a customer environment. There are therefore no customer references, case studies or outcome figures — and none appear anywhere on this site.
-
Any third-party rating, review score or audit result
None held. No rating, score or independent assessment is claimed anywhere on this site.
If a hard requirement on this list is disqualifying for your programme, that is a legitimate reason not to proceed and we would rather you reached it here than three months into an evaluation. Where a path exists, it is described on the platform page as a costed roadmap item — never as a status.
Security practices
How the software handles what it is given
Six practices that are true of the current build, not aspirations for a future one.
-
Secrets live in the environment, never in source
API credentials, signing keys and mail settings are read from environment configuration at runtime. No key is committed, and the repositories are configured to keep credential files, certificates and signing material out of version control.
Last verified
-
API tokens are signed and short-lived
Surfaces are issued a signed token at page load rather than holding a long-lived credential. A token that is altered does not verify, and one that is captured expires.
Last verified
-
Decision records are hash-chained
Advisory decisions are written into a chained record with a keyed signature over the row fields. A record edited after the fact fails verification, and the interface exposes both the verification and a deliberate tamper test so a reviewer can see the failure rather than take it on trust.
Last verified
-
Demonstrations run on synthetic or public data
No demonstration holds real passenger, crew or operational data. Weather and published navigation data come from public services; everything else is seeded synthetic data generated from a fixed seed, so a run is reproducible.
Last verified
-
The lead form stores the minimum and nothing else
The demo-request form on this site collects what you type plus the originating address and browser string for abuse prevention. It is written to a store that is not readable over the web and emailed to us. There are no analytics, advertising or cross-site trackers on this site.
Last verified
-
Deployment can be inside your boundary
The demonstration surfaces are self-contained with relative paths and no mandatory outbound service dependency, so they run on a dedicated host or inside a controlled environment where data cannot leave.
Last verified
AI feature facts
What the AI actually does, and where it is absent
“AI-powered” tells a reviewer nothing about what is generating the output they are being asked to trust. These are the specifics.
-
Safety-relevant text is generated by rules, not by a model
Weather phraseology is produced by an explicit rule engine over a parsed observation. There is no generative step anywhere in that text path, which is why the same observation always produces the same words and why every phrase traces to a field in the source.
Last verified
-
Risk and recovery scoring is deterministic
Flight risk scores, deviation lookahead scores and recovery option comparisons are computed by rules over records. The same inputs produce the same output every time, and the drivers behind a score are shown alongside it.
Last verified
-
The analyst answers from records, with or without a model
With no language-model credential configured at all, the analyst still answers — deterministically, from the operational records. When a model is present it only phrases what the records already say; facts never originate in the model.
Last verified
-
Every answer carries its sources and its confidence
Analyst and copilot answers name the records they were built from and state a confidence figure. An answer with no sources is a defect, not a style choice.
Last verified
-
No model is trained on customer data
There is no customer data, because there is no customer deployment. Nothing in the current build trains, fine-tunes or retains anything for model improvement, and any future arrangement would be a written term rather than a default.
Last verified
-
No automated action is taken on a model output
Model output is never an input to an action. Actions require a human approval, and the approval — not the model output — is what gets written to the record.
Last verified
Human escalation
Where the software stops and a person takes over
Every one of these is enforced in the engines, not added at the interface.
-
Every advisory action stops at a human
Approve, reject and note are human actions. The system produces the comparison; a qualified person makes the call, and the record names who, when and why.
Last verified
-
Unsolvable cases escalate with the work already done
When the passenger-recovery engine cannot place someone within its rules, it escalates to an agent with the options already computed and the constraint named. There is no code path that invents a seat to avoid an escalation.
Last verified
-
Low confidence is shown, not smoothed over
Confidence figures are rendered next to the answers they qualify. A low-confidence answer looks different from a high-confidence one, because a system that hides its uncertainty under pressure is worse than no system.
Last verified
-
Higher autonomy is an operator decision, not a product default
Supervised-automatic and autonomous tiers exist as designs. They stay designs until an operator — not a vendor — sets the policy thresholds in writing.
Last verified
Degraded mode
What happens when something is unavailable
An operations tool with no defined failure behaviour is a liability during exactly the events it was bought for.
-
No model key: the product still works
The analyst and copilot paths run deterministically with no language-model credential present. This is the normal configuration for a demonstration, not a fallback — the key adds phrasing, not capability.
Last verified
-
Weather service unreachable: labelled synthetic data, never silence
If the public aviation weather service cannot be reached, the operations products fall back to clearly labelled synthetic observations. The label is the point: a stale or substituted observation must never be mistaken for a live one.
Last verified
-
No reporting credential: the tier badge says simulation
The reporting adapter runs in simulation mode with no credential and says so on the surface. Supplying a credential switches the same code paths to live services and changes that badge — that badge is the only interface difference, and it is deliberately not subtle.
Last verified
-
This site degrades to plain HTML
The site is static. With JavaScript unavailable, every page, link and navigation destination still works; the mobile menu control is inert and the footer carries every destination. The demo-request form states that it needs JavaScript and gives an email address that reaches the same place.
Last verified
Per product
What each product touches
The privacy boundary for every product in the portfolio, in one table. The long form is on each product page.
| Product | Personal data | Boundary |
|---|---|---|
| Nexus Dispatch | Crew duty data only, and synthetic in every demonstration. No passenger data. | The product reads flight, crew, maintenance and constraint records to score risk. In every current demonstration those records are synthetic; weather and published navigation data come from public services. Nothing is sent to a third party for scoring, nothing is retained for model training, and in an on-premises or controlled deployment the records never leave the operator’s boundary. Crew data is the sensitive part of this product and is treated as such: duty margin is shown as a constraint, not as a personnel file. |
| Airline Operations Intelligence | None. Operational reporting records only — no passenger or personnel data. | The product reads operational reporting records — arrivals, route conformance, metering configuration, advisories. It holds no passenger data and no personnel records. Today every record is a labelled simulation seeded from published schemas; no live feed is connected. In a controlled deployment the record set and the decision chain stay inside the operator’s boundary, and nothing is sent outward for scoring or retained for model training. |
| Rebound | Yes — passenger manifests. Deterministic synthetic manifests only; no real passenger data has ever been in it. | This is the one product in the portfolio whose real-world input is personal data: a passenger manifest, with names, parties, accessibility and medical needs, and loyalty status. Today every manifest is synthetic and generated from a fixed seed — no real passenger data has ever been in it. In a deployment the manifest would stay inside the operator’s environment, the engine would run against it locally, and nothing would be sent to a third party or retained for model training. Accessibility and medical flags drive prioritisation and are never shown as anything other than a priority reason. |
| AeroVox | None of any kind. The only input is a public weather observation. | AeroVox holds no personal data of any kind. Its only input is a public weather observation, retrieved from a public aviation weather service that requires no credential and identifies no individual. There is no user account, no manifest, no crew record and nothing to retain. It is the simplest privacy story in the portfolio, and that is a deliberate property of the design rather than a stage it will grow out of. |
| Flight Service | None. Geolocation is collected but unused — no output depends on it and it is not stored. | The service holds no accounts and no personal data. Browser geolocation is requested and captured, but nothing in the current build depends on it — no output changes based on the reported position, and it is neither stored nor transmitted onward. Route and aircraft inputs are used for the briefing being generated and are not retained. Every upstream source is a public, unauthenticated feed. |
| CREW Downtime | None collected — nothing is built. A real build would hold profile, position, camera and microphone, and needs a consent design first. | This is the most privacy-sensitive design in the portfolio, and none of it has been implemented — no profile has been captured, no position read, no camera or microphone opened, because there is no application. A real build would hold a personal profile, continuous position, and camera and microphone access, which is exactly the combination that demands explicit, granular consent, a clear retention position and a documented answer on who may see a crew member’s location. That consent design is a precondition of any pilot, not a later refinement, and it does not exist yet. |
| Universal Flight Companion | None today — every traveller, trip and roster on screen is a fixture. | The prototype has no accounts, no backend and no persistence — there is nowhere for personal data to go, and none has ever been in it. Every trip, traveller and roster on screen is a fixture. A real build would hold trip and itinerary data and would need a proper data-protection design, including what a watcher view is allowed to show about someone else’s travel; that design does not exist yet and is not implied by the prototype. |
Statistics policy
Why there are no industry figures on this site.
Not an oversight. A figure without a resolvable primary source is indistinguishable from an invented one, and on an aviation site it is the first thing a reviewer checks.
The content model requires six things before any external statistic can be rendered at all: the figure, the primary source organisation, a resolvable source URL, the publication year, the caveat the figure carries, and the date the wording was last checked against the live source. A statistic missing any of them cannot be added — not as a matter of policy, but because the type will not accept it and the build fails.
No figure has been verified against its primary source from this workspace, so none is published. When one is, it will appear here with its source link, its year, its caveat and its verification date visible next to it, and the argument it supports will be worded no more strongly than the source allows.
Statistics currently published 0
Next step
Bring the person who has to sign.
The most useful session we run is not a demonstration — it is a technical review where someone tries to break the deterministic scoring path and the decision chain. Both are built to fail visibly when they should.