Trust

How to read this page

Most vendor trust pages are written to reassure. This one is written to be checkable. Where we have a practice, we describe it. Where we do not yet have something, we say so rather than phrasing around it.

If you are running a vendor assessment and need something specific — a security questionnaire, a data-flow description, details of a particular control — ask us directly at hello@aeronexum.net. We would rather answer a hard question than have you infer an answer from marketing language.

Security

The controls below are in place today. They are deliberately stated plainly and without embellishment.

Encryption in transit

Traffic between your browser and the platform is encrypted over TLS.

Encryption at rest

Your records are encrypted where they are stored.

Role-based access control

Users see what their role allows. Quoting, receiving, quality and finance stay in their lanes — which matters more in aviation than in most industries, because segregation of duties is part of how a quality system works.

Automated backups

Operational data is backed up on a regular automated schedule rather than when somebody remembers.

Nothing to install

The platform runs in the browser. There are no servers for you to maintain, no VPN to operate and no update cycle to schedule — which removes a category of security exposure rather than transferring it to you.

Your data

Aviation records outlive vendors. A rotable in service today may still be flying after several changes of ownership, and its history has to survive all of them. That shapes our position on data.

Your data stays yours

Your operational records belong to you. We do not treat them as an asset of ours.

Export at any time

You can export your records whenever you want, not only on the way out. There are no exit fees and no retention of your data as leverage.

We do not sell customer data

Stated in our privacy policy, and it means what it says.

We keep customers with the product

If the platform stops being the system your team would rather use, holding your data hostage would only delay the conversation. We would rather have the conversation.

Privacy

Our privacy policy sets out what we collect, why, and who it is shared with. Two things worth stating here in plain terms:

• This website uses Google Analytics to measure usage and traffic. That is disclosed in the privacy policy, and it is the only analytics we run. We added the disclosure the same day the measurement went live.
• Customer operational data and website analytics are different things. Analytics covers visits to this public website. It is not a window into anyone's inventory, quotes or repair records.

Responsible AI

This section describes commitments, not capabilities. It is a statement of where we draw lines, and it should be read as something you can hold us to.

Actions that always require deliberate human approval

We consider the following categories to be decisions rather than tasks. Software may prepare them. A person approves them:

• Sending communications to a customer or vendor
• Pricing decisions
• Financial commitments
• Accepting a contract
• Actions bearing on regulatory compliance
• Deleting records
• Any commitment made to a customer

In an industry where a misdescribed condition or a premature release carries genuine consequence, we think that list should be conservative and explicit rather than left to configuration.

Confidence before automation

We do not automate something merely because it can be automated. Automation is appropriate when confidence is high and the consequence of being wrong is low. The higher the business risk, the more visible the person becomes — not less.

Explain before recommending

A recommendation nobody can interrogate is not useful in a regulated industry. If the platform surfaces something as important, it should be possible to understand why. Trust in software is built the same way as trust in a colleague: by being right, and by being able to show your reasoning when asked.

Learn without surprising

Systems that adapt to behavior should improve what they suggest — not silently change how the work is done. Predictability is a feature. A tool that behaves differently on Tuesday than it did on Monday, for reasons nobody can see, is a tool people stop trusting.

AI is not the product

People are. The interface should not become an AI application with an operation attached to it. Where intelligence helps, it should feel like the work got easier — not like the software did something.

Availability

We have not published an uptime figure, and we want to be straightforward about why: a service level is a commitment, and commitments should be backed by measurement over a meaningful period rather than by intention.

What we can describe is the approach. The platform is cloud-based with nothing for you to run. Data is backed up automatically on a schedule. Updates are delivered without update cycles or maintenance projects on your side. If you have a specific availability requirement — because you support AOG customers, or because a contract obliges you — raise it with us during evaluation rather than after, and we will tell you plainly whether we can meet it.

How we support customers

You talk to the people who build it

Not a tier-one script. The team answering an operational question is the team that designed the thing being asked about.

We would rather answer than have you guess

Including uncomfortable questions about limitations, roadmap timing and things the platform does not do. An unanswered question becomes an assumption, and assumptions surface later at worse moments.

Onboarding is a conversation, not a project

Inventory, customers, vendors and part records can be imported, and mapping is worked through together so condition codes, serial numbers and traceability land where they belong. We are not interested in six-figure implementation engagements.

Real feedback changes the product

The platform is in active use with aviation businesses, and operational feedback from that use is the main input to what we build next.

How we make product decisions

Every feature has to earn its place. The questions we ask before building something are consistent, and they are all versions of the same one:

• Does it make the situation easier to understand? Adding information is not the same as improving understanding.
• Does it help someone know what deserves attention? If it creates one more place to check manually, it has made things worse.
• Does it help work move forward? If you can look but not act, it is a report rather than a capability.
• Does it survive an interruption? If picking the work back up requires remembering where you were, it will fail on a busy day.
• Does it make the person more confident? Are consequences clear, is the source of information visible, is it reversible where it reasonably can be?

The practical effect of applying these is that we say no to a lot, and ship less than we could. We think that is the correct trade for software people have to use under pressure.

How we think about the roadmap

Depth over breadth

We would rather do the aviation-specific work properly than accumulate adjacent features that a general platform already does adequately.

Every release should feel calmer

Not busier. If a release makes the platform feel heavier to use, it has failed regardless of what it added.

We build for the long shape of the industry

Aviation assets last decades and change hands repeatedly. Software that assumes a short horizon will not serve an organization tracking a rotable through its fourth overhaul.

We do not pre-announce what we have not built

If it is not working, we will describe it as something we intend rather than something we have. Roadmap dates given as commitments tend to become the first thing a vendor breaks.

Transparency

A few standing commitments about this website, which is the part of us you can audit without talking to anyone:

• No invented evidence. No fabricated customer counts, invented statistics, borrowed logos, or certifications we do not hold. Where we quote a customer, they are real and attributed with permission.
• Regulatory precision over confidence. Our Knowledge Center describes FAA and EASA material narrowly, distinguishes regulation from industry convention, and says explicitly where practice varies by contract, operator or jurisdiction. Where we are describing a US framework, we say so.
• We publish what the product does not do. Our category page includes the organizations that should not buy this and the things this category is not.
• We teach the industry, not our implementation. The Knowledge Center is written to be useful whether or not you become a customer. What we do not publish is how the platform is built — and we would rather state that boundary than pretend it does not exist.

If something here is not enough

Vendor assessment in aviation is properly rigorous, and a page like this will not satisfy a serious one on its own. If you need detail we have not published — a completed security questionnaire, specifics of a control, a data-flow description, or an honest answer about something we do not yet do — write to hello@aeronexum.net or use the contact form.

We would rather lose an evaluation on a limitation we disclosed than win one on an impression we allowed.