How RotorLab protects the record

Single sign-on

Connect Google Workspace, Microsoft Entra, Okta, or any OpenID Connect provider. SSO only signs in addresses under your verified email domain. By default it signs in only people your administrator already added; your administrator can let it add people on their first sign-in, inside your plan's user limit, and let your provider's groups set their role at each sign-in. A person in none of the mapped groups keeps the role they have, so removing someone from a group does not by itself remove the role. It never makes anybody an administrator.

Enforced two-factor

Every organization administrator needs two-factor, with 14 days to set it up. Organizations can require it 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. The second factor is an authenticator app, or a security key or passkey (WebAuthn), which signs only for this site, so a look-alike page cannot capture and replay it. An organization can accept security keys only.

Eight built-in roles, and custom ones

Eight built-in roles including an Auditor made for insurers and customer quality teams and a Billing role for a finance or purchasing contact, who sees and manages the plan, orders, invoices and billing details and buys for the organization, and reaches nothing else, 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 every area except billing and changes nothing. The crew board opens for any role holding Members (view), the Auditor included; public reporting settings and the full organization export stay with your administrators; the whole-organization binder stays with your administrators and any role they give Records custody, and an Auditor's whole-program audit package carries the binder. Records custody places legal holds, sets how long records are kept, and produces packages, release copies and the binder, without the right to file or edit a record. A Pilot sees aircraft, flights, missions, health, maintenance and the operations manual, and nothing else. A Dispatcher runs the dispatch board and the jobs its sorties serve. An Operator-maintainer flies like a Pilot and records the operator's maintenance, while releasing work stays with Maintenance. Every built-in role is walked against the route table in our test suite on every release.

Sessions you can see

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 favor of its identity provider. Recent account activity is shown in plain language.

Ground stations are accounts

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.

Support access you give

RotorLab support opens your organization's records only while one of your administrators allows it: for 24 hours, 72 hours or 7 days, with a reason, and you can end it at any time. In an emergency, when nobody can give access, support can open your records for at most a day with a written reason, and every administrator of your organization is emailed at that moment. Either way, everything support opens or changes is written to your activity log, which your administrators and Auditors read on every plan. The account support uses requires two-factor authentication and its sessions end after eight hours.

Write-only secrets

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.

Verifiable documents

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.

An audit trail in plain language

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. Every export and audit package says whether your organization's chain held when it was made, and gives the recipe to check its rows yourself. Frozen manual revisions and per-serial service-bulletin compliance keep the paperwork trail attributable.

Timestamped by someone other than us

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 the new records of these kinds, and the newest row of your activity log, which commits to every row before it, are 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: issued reports and invoices, flight records, stored flight logs, attached documents, job photos, operating area dossiers, audit packages, published operations manual revisions, published public reporting periods, earlier copies of corrected reporting periods, maintenance releases, occurrences, training sign-offs, hazard risk acceptances, completed checklist runs, pilot credentials, authorizations, defects, work orders, declaration of compliance sign-offs, serial conformity inspections and frozen type baselines. Records of other kinds, such as hazards and mission plans, are not anchored one by one. A record corrected after it was anchored is anchored again in the next pass as a new version, and its proof lists the days of the earlier ones. Your audit binder and each audit package carry the proofs of the records in them, how each digest is computed, 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.

Export your records, any time

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. Each person can download everything held about them from My Account, and an administrator can export everything about one member, for an access or portability request; neither carries a colleague's own records, and an occurrence a colleague filed about the person's flight is shown in full only to a reader whose role reads occurrence reports.

Your log files come back

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.

When a plan ends

When a plan ends, your organization's records stay read-only with export for 90 days. For the 12 months after that they are kept with no access unless you buy or restore a plan. We send an alert 30 days and a final notice 7 days before the records are deleted. Buying or restoring a plan at any point before deletion restores full access. Records on legal hold are never deleted while the hold stands, and deletion is never automatic. The Terms of Service, section 15, say the same.

When records are deleted

Deleting an organization leaves a certificate of what was deleted, when and why, kept for twelve months. A verification code on a document the organization issued then answers that the document was issued and the organization has since closed. Activity log rows and timestamp entries stay in place with the organization's details taken out, so no other organization's records stop verifying. Each deletion is also written to a signed journal kept apart from the database, so restoring a backup taken before it deletes the organization again. A photo or document removed from a record is kept, hidden, for the window your organization sets on the Retention page, then deleted with a line in the disposal register.

Every outside party RotorLab can reach, said plainly. A copy run in offline mode calls none of them, except single sign-on, email and webhooks to hosts inside its own network that the people who run it list. An organization can also switch off, for its own members, map imagery and terrain from outside services, weather, place and elevation lookups, address autocomplete, and usage analytics.

RotorLab can annotate records with advisory scores. The rules that govern them are stricter than the models are clever.

A claim with a citation, never a verdict

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.

Two switches, yours

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.

Provenance, enforced

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.

Card details never touch us

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.

Encrypted in transit

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.

Backups and status, measured

Production runs in one data center in Texas; backups are kept in Iowa. The database is snapshotted in a transactionally consistent way every 24 hours and the last 7 snapshots are kept, so a snapshot is deleted after about 7 days. Service health is published at /status from our own heartbeat, including the gaps, and any incident we are working on is posted there. We run to a 99.5 percent monthly target, and the page shows what our own heartbeat measured. The Terms carry no uptime warranty or service credits.

What a buyer who runs a Section 508 check needs to know.

The target

We build RotorLab to WCAG 2.1 level AA, which takes in the WCAG 2.0 level AA criteria Section 508 incorporates and is the level the Justice Department's ADA Title II rule sets for state and local government. Every page declares its language and has a main landmark, every page with the navigation bar has a skip link to its main content, form labels are tied to their fields, and every PDF RotorLab issues is tagged with its language, title and reading order.

Our conformance report

We keep an accessibility conformance report on the VPAT 2.4 template, Section 508 and WCAG edition, for each release, and it says where we fall short as well as where we meet a criterion. Ask for the current one through Contact.

Report a barrier

Something you cannot reach with a keyboard, a screen reader or magnification: tell us through Contact, choosing Accessibility. We answer a reported barrier within thirty days.

Said plainly, so a procurement checklist gets a straight answer.

Certifications

No ISO 27001 certificate, FedRAMP, GovRAMP (formerly 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.

Identity protocols

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, or added on their first SSO sign-in where the organization allows it, 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. A PIV or CAC card is used through your own identity provider, not read by RotorLab directly. Where an organization requires SSO, its members, administrators included, cannot sign in with a password, and a person's API key works only within the re-check period after their last SSO sign-in. The platform operator's own account is not bound by an organization's rule, so a locked-out organization can still be helped.

Where it runs

RotorLab is operated by us as one service. A government or defense organization that must keep its records inside its own network runs its own copy of the release there, in offline mode: that copy makes no connection outside the network, so it has no independent timestamps, map imagery, DJI log reading, weather or airspace downloads or card payments, every signed-in page says so, and the organization runs, secures and backs it up itself. Its maps and terrain can come from a tile server inside the same network, and its single sign-on, email and webhooks can reach the hosts inside that network its operator lists. Uptime of our service is published from our own heartbeat at /status.