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 a read-everything, change-nothing Auditor made for insurers and customer quality teams, plus custom roles composed from a plain checklist of what each area allows.
Sign-ins use secure, server-side sessions. Every device signed in to your account is listed on your account page, and recent account activity is shown there 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 — are write-only: saved once, used server-side, never echoed back to any screen.
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 it is genuine and unaltered — no account needed.
Sign-ins, permission changes, approvals and security events are logged and readable by your administrators. Frozen manual revisions and per-serial service-bulletin compliance keep the paperwork trail attributable.
The strongest promise a system of record can make is the exit.
An organization administrator can download the whole record — aircraft, flights, maintenance, 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.
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.
The database is snapshotted automatically in a transactionally consistent way, on a schedule, with retention. Service health is published at /status from our own heartbeat — including the gaps.