RotorLabRotorLab holds the designs, flight logs, maintenance records and regulatory evidence that organizations stand behind with their own name. This page says plainly how that data is protected, what you can verify yourself, and what happens if you ever want to leave. Built in Dubuque, Iowa.
Access is your organization's decision, enforced by the platform.
Connect Google Workspace, Microsoft Entra, Okta, or any OpenID Connect provider. SSO only signs in addresses under your verified email domain, and only people your administrator already added — it signs members in, it never creates accounts.
Organizations can require two-factor for everyone, with a grace period each person gets in full. After the deadline the account is closed to everything except enrolling and signing out — a real requirement, not a nag banner.
Five built-in roles including an Auditor made for insurers and customer quality teams, plus custom roles composed from a plain checklist of what each area allows. A role gates both reading and changing, area by area, at the server: an Auditor reads everything and changes nothing, a Pilot sees aircraft, flights, missions, health and maintenance and nothing else. Every built-in role is walked against the route table in our test suite on every release.
Sign-ins use secure, server-side sessions. Your active sessions, with the device, the address it came from, and when each started and expires, are listed on your account page and can be ended one at a time; an organization sets how long a session lives, how long it may sit idle, and whether passwords are refused in favour of its identity provider. Recent account activity is shown in plain language.
A ground station or server that files flights on your behalf holds its own credential, visible and revocable by your administrator like any other member.
Credentials you store — payment provider keys, SSO client secrets, mail passwords, webhook signing secrets — are write-only: saved once, used server-side, never echoed back to any screen, and sealed at rest with the same authenticated encryption that protects flight positions.
A record only counts if a third party can check it without taking your word.
Every generated report and invoice carries a verification code. Anyone you hand the paper to can confirm at rotorlab.app/verify that RotorLab issued it, when, and for which records, with no account needed. The code is a keyed hash held by RotorLab, not a digital signature: it proves issue and origin, and we say so on the verify page.
Sign-ins, permission changes, approvals and security events are logged and readable by your administrators. The log is a hash chain: every row carries the hash of the row before it, so a row edited or removed after the fact breaks every hash that follows, and every export and audit package says whether the chain held when it was made. Frozen manual revisions and per-serial service-bulletin compliance keep the paperwork trail attributable.
A hash chain proves a record has not changed since we recorded it, but not that we did not change it. So once a day every new record is reduced to a single SHA-256 value, and only that value is sent to an independent RFC 3161 time-stamping authority and to OpenTimestamps, which records it in Bitcoin. Your audit binder carries each record's proof and a small checker that needs nothing from us. It proves a record existed in that form by that time; it does not prove the record is true. How to check one.
The strongest promise a system of record can make is the exit.
An organization administrator can download the organization's records (aircraft, flights, components and work orders, missions, types and bulletins, manuals, occurrences, jobs, authorizations) as one archive of JSON and CSV files another system can read, raw flight log files included on request. No support ticket, no waiting. The export is growing to carry every module, and each release says what was added.
A stored flight log is your file. Downloading it back is never gated, metered, or tied to a paid feature — deliberately, so storing evidence with us can never become leverage over you.
RotorLab can annotate records with advisory scores. The rules that govern them are stricter than the models are clever.
Every score names the signals that drove it, the model and version that produced it, and the day it was scored. Nothing anywhere gates on a score: it never grounds an aircraft, blocks a flight, or fails a record. The deterministic record underneath is untouched.
Want zero model output on anything you hand a regulator? Switch annotations off: off means absent everywhere, exports included. And the models improve only from data organizations volunteer — training inclusion is opt-in, off by default, revocable. Your records never train anything unless you say so.
Every model ships with a manifest naming exactly what data trained it and how it scored against the simpler method it had to beat. A model whose predictions cannot yet trace to real recorded evidence is refused by the software itself — not by policy, by code.
Boring on purpose.
Payments run through hosted checkout: card numbers go to the payment provider, never to this server. Procurement buyers can order by purchase order and pay an invoice on net terms instead.
The service is served over HTTPS, session cookies are locked to it, and webhooks we send to you are signed so you can verify they came from us.
Production runs in one data center in Texas; backups are kept in Iowa. The database is snapshotted in a transactionally consistent way on a schedule, with retention. Service health is published at /status from our own heartbeat, including the gaps.
Said plainly, so a procurement checklist gets a straight answer.
No SOC 2 report, ISO 27001 certificate, FedRAMP, StateRAMP or CJIS authorization today. The controls on this page are ours to describe and yours to verify in the product; a formal attestation will be announced here when it exists, with its scope, not before.
Single sign-on is OpenID Connect. SAML is not offered, and there is no SCIM provisioning: members are invited, singly or from a pasted list, and an identity provider that disables a person ends their access here on the next re-check, which an organization sets and defaults to a day.
RotorLab is operated by us as one service. There is no on-premises edition; an organization that needs its own instance is offered a dedicated one that we run. Uptime is published from our own heartbeat at /status; the commitment we make in writing is 99.5 percent monthly, and the page shows what we actually delivered.