Audit Binder

When an auditor, an insurer, or a client asks to see the program, the audit binder is the answer: one zip archive assembling the current frozen document from every module your organization holds, fronted by a binder PDF that carries the registers as they stood at assembly time. Organization admins find Download the audit binder in two places: on the Readiness card of the Ops Dashboard, and on the Account page beside the organization data export.

Every binder downloaded is listed in Packages produced on the Audit page with its code, and an organization admin, or a role with Records custody: manage, can download that exact file again later with Download again; each one writes a line to the activity log with its size and SHA-256. To record who asked for a binder and why, produce it from the Audit page: fill in Requested by and Purpose and press Whole binder. On the Audit page, a role with Records custody: manage produces the binder for your own organization as an organization admin does.

The binder also carries the pilot roster with credentials and currency (aircrew first; anyone who is not aircrew has the standing "not aircrew", is never counted as a lapsed pilot, and is explained in a note under the roster). Standing is the one standing every screen shows, measured on the day of assembly: the regulator's recurrent rule where the regime flown under has one, the expiry of every credential on file, your own recency rules, and, where your organization runs Training Programs, each role the person is assigned. A recency rule of yours restricted to night or to one kind of flight holds a privilege and does not set the standing: a pilot who has missed only that rule reads current, with the rule listed under Needs attention. A Part 135 check the training program shows lapsed therefore never sits under a roster line that says current. Regulation and Your rules give each half on its own, so a reader sees whether a lapse is the regulator's or your organization's; a dash means nothing of that half is on record for the person. The credentials on file are your record of what each pilot holds and count under Your rules, except one your regime asks every pilot to hold (a medical where the regime requires one), which counts under Regulation. Training program gives the verdict of each role, with the date a lapsed role lapsed. The Needs attention column names each item with whose rule it is and the date it lapsed or falls due (for example "Recurrent training (14 CFR 107.65) lapsed 2026-08-01"), and a recency item that lapsed with no date says how many qualifying flights it found. Credentials lists every credential the person holds, each once, in its regulator's words, with its number; a renewal on file is listed in place of the one it replaced. After the roster, Flights flown outside standing counts every flight on record stamped on an aircraft reading no go or condition unknown, by a pilot whose currency had lapsed, or outside the authorization it names, how many of each, then lists the 200 newest with their number, date, aircraft, pilot, what the records said (marked "stamped later" for a flight filed before standing was kept, read as the records stood on its day, whose reason reads "Not asked: filed before standing was kept") and the reason given. When there are more, a note says so: every one is listed on the Logbook page's Flown outside standing card under Show all, and in the download Export organization data makes. Flights not yet stamped are counted under it. See Standing at the moment of flight. Then come the authorizations and the insurance policies (each with its Standing today, computed from its dates on the day of assembly: current, lapsing with the days left, expired, not yet in effect, in force with no expiry for a certificate or operations specifications, in force until withdrawn for a self-insurance declaration, or no expiry recorded; an authorization whose kind carries a renewal lead adds the date its renewal has to start by). Each authorization prints its number, its conditions (or "none recorded") and the aircraft it covers; each policy prints its liability and hull limits (or "not recorded"), its territory and the aircraft it covers, or "every aircraft" for a policy covering the whole operation or a self-insurance declaration. Then the maintenance standing per aircraft (its airworthiness with its reasons beside it, program tasks due, open work orders including grounding work lowered or withdrawn without a release, released records and open defects), the Open work orders table (every open order with its aircraft, where it was raised from, such as a service bulletin, a health finding, a life limit, a program task or by hand, its priority, standing, opening date and due date), the Component life register (every part in service or on the shelf with its part number, serial, aircraft, fitting date, in-service date and its life against each limit, including any flying before registration that is not counted), and the occurrence register, and beside its Not yet in the binder list (registers the organization holds and has not started) it states which modules are not part of the organization's program at all, so a reader is never left to assume the binder is the whole of what could exist. The binder's verification code is issued over every register it prints, so an edited PDF fails verification. For a request about one period, one aircraft, one pilot, one job or one occurrence, the Audit page produces a package scoped to the ask instead.

What is inside#

The archive contains:

• 00-audit-binder.pdf, the fronting document. It opens with the readiness meter as it stood, then an index of every file in the archive, then the registers: the aircraft registry with each aircraft's total hours and flights on record, followed by Origin and covered foreign UAS lists (each aircraft's maker and countries and what your organization recorded on each list, with where and when it was checked and any exemption with its end date; see Aircraft), an Hours of record table giving each aircraft's hours, how many came from flight logs the organization holds and how many were entered by hand (hours it arrived with included), and how many of its flights were entered more than 24 hours after they flew, the component life register (a part with a life limit and no serial reads "none: untraceable", and life a part ran before RotorLab is printed with its source), the safety register with risk scores, each hazard's mitigations with their state (in force, planned or ended), and its latest acceptance with who accepted it, the date and the rationale, or, where that acceptance no longer applies, "lapsed" with what was accepted and why it lapsed (see When an acceptance lapses), the safety reviews with when each was last held and next falls due, training coverage per person over the roles each person is assigned, with qualifications inside their 30-day window counted as held and shown as expiring, declaration-of-compliance coverage per type, operating areas with their conformance counts, the occurrence filing clocks, one row per duty (an immediate notice and a written report are separate rows, each filed, waived, due or overdue), and Attached documents: every document attached to the records the binder lists (the pilots' credentials, the authorizations, the insurance policies, the released maintenance records, the occurrences and the declaration sign-offs in force), each with its record, its name, its size and its SHA-256 fingerprint, or "No documents are attached to the records in this binder." The documents themselves are not in the binder: a reader who is handed a copy checks it against its fingerprint here, and the list is covered by the binder's verification code. It carries its own verification code, checkable at https://rotorlab.app/verify.
• The current published operations manual revision, as plain text carrying its own verification code. This is the approved artifact exactly as published, never re-rendered from today's records, so revision 3 in the binder is revision 3 as it was signed. Beside it, manual-<title>-rev<N>.content.json holds the revision's content as approved: its SHA-256 is the revision's timestamped digest.
• The latest frozen area dossier for each operating area, as the same PDF the area page serves, hash and all. The binder's index lists each by its document code.
• Each aircraft type's design dossier with its declaration of compliance, rendered at assembly time.
• attached-documents.json, when any document is attached to the records the binder lists: the same list as the Attached documents section, one entry per document with its record, the kind of record, its name, size in bytes, SHA-256 fingerprint and when it was attached.
• manifest.json, a machine-readable index carrying each file's SHA-256 hash and byte count, so a recipient can prove the archive was not altered after assembly.
• HOW-TO-VERIFY.txt, written from what this binder holds: the steps to check it, the binder's code, and every document inside that has a code of its own.
• verify_package.py, an offline checker that needs only Python. It checks every file against the manifest and names anything missing, changed or unlisted. See Verifying a document.
• A timestamps folder, when the organization's records have been independently timestamped: the proof of every timestamped record, each with the record's anchored fields while it still matches, the proof for your organization's own activity log on each day it had new rows, the day files, the checker verify_anchor.py, and a README that gives how each kind's digest is computed and names the records the binder carries that are not timestamped yet. See Independent timestamps.

The SHA-256 of the zip itself is kept under the binder's code, so a reader can give rotorlab.app/verify the whole zip as well as the PDF. See Verifying a document.

What the binder refuses to do#

The binder holds the same lines the rest of the product holds. It includes sections only for features your organization actually holds, so it never advertises a gap an add-on would fill. A held module with nothing frozen yet is named under not included in both the PDF and the manifest, because a reader who cannot see the gaps cannot trust the rest. And the frozen documents ride as themselves: the binder adds assembly, never a re-rendering that could drift from what was approved.

Related#

• The Setup Guide and Readiness: the meter the binder opens with.
• Ops Manual: the revision discipline behind the manual copy.
• Operating Areas: where dossiers are frozen.
• Aircraft Types: the design dossier and its declaration.