Roster, next duty, calendar
Roster from the file or feed you provide, or the crew member's own import; next duty on the Lock Screen and the watch, the month at a glance, calendar sync to the calendar they choose.
For airlines and operators
CrewBag for Operators is the same application as the personal edition, delivered as a version-pinned build that you classify inside your own EFB programme and, for a type B application, put to your competent authority for approval. A core package, and options you pick, each one scoped, priced and switched on by you. We bring the engineering, the evidence and the change control.
Everything in the personal edition, on the devices they carry today. One import, then the day is on the device.
Roster from the file or feed you provide, or the crew member's own import; next duty on the Lock Screen and the watch, the month at a glance, calendar sync to the calendar they choose.
Cumulative limits against the published authority limit, with the document and its date shown. Reference, with the source on screen.
The operational flight plan as a document, read the way it was printed. The OFPs your crew accepted are kept hash-chained, on the device and, in the operator edition, in your archive.
Every flight logged from the roster and the OFP, exportable in an EASA-style layout; your authority decides what it accepts. Pilots keep their own logbook when they leave.
Decoded METAR and TAF, the weather map on the route, NOTAMs with the raw text one tap away. Advisory only. The official briefing decides.
Gross-pay estimation from the roster and a payslip check against it, at the rates in your agreement. Rest and duty reference with the agreement named.
The operator edition differs from the personal edition by who holds the switches, not by what the software is.
Your fleet runs the version you qualified. A new version ships to you as a release candidate with its change record; it goes live when you say so.
Change controlEvery capability is a switch you own: on, off, or read-only, per fleet, per base, per role. The crew sees what you decided they see.
ConfigurationRetention periods, export formats and deletion are set by you and recorded. Personal data stays on the device unless your programme says otherwise.
GovernanceAccepted OFPs, signatures and audit trails kept in one of three places, your choice. A tenancy we run in the EU, listed in your information-security risk assessment as an interface: we report security events to you within 24 hours, work under your oversight, and your authority may access us on request. Your own servers, with the same software, under your keys: we hold no data and have no access unless you grant it. Or a mix, with the archive on your side and each data flow documented. In every case: encrypted in transit and at rest, backed up on your schedule, access logged, export on demand.
DataThe operational picture across your fleet: which version is in use, what is pending, and, where your policy allows it, who has accepted what. You are the controller of that record; retention is set by you.
OperationsOne contract, one invoice, seats managed by you. Crew members pay nothing themselves.
CommercialOne record per flight, built step by step on the crew's device. Every entry is tamper-evident in an append-only, hash-chained trail; the device signs each entry, your identity scheme says who acted, one named user per device, and each entry carries the application version, configuration and data cycle it was made with. Entries are timestamped when made, never when synced. Nothing is rewritten; a rejected step is kept with the reason. Where your operations manual says so and every required item is present, the record can serve as your journey log or equivalent.
The final signature closes the record with a hash of the whole chain and transfers it to your archive over an encrypted link. Optional connections: your OFP provider, your performance provider, and your ACARS/AOC datalink for out, off, on and in times. Retention runs per record class, as your rules set it: flight-preparation documents, fuel-check data, recency items and management-system records each keep their own clock, and the export splits them. The module is enabled by you inside your approval; the records are yours, and crew members can obtain their own on request.
By itself it is not a performance tool: CrewBag for Operators computes no take-off, landing, mass-and-balance or fuel figures. Where you connect it to your performance provider, it displays that provider's output as delivered, engine-out procedures and EOSIDs as text, with the provider, the inputs and the time of computation on screen. It recomputes nothing, interpolates nothing and draws no procedure on a map; a figure is marked superseded the moment an input changes. A type B function, inside your approval, with your provider contract behind it.
When EASA's AI rules under RMT.0742 are adopted and you switch model help on, every model input and output enters the same trail, for your compliance and quality control.
Operations manuals, checklists, notices and bulletins as searchable documents on the device, in the revision you released. Read receipts per crew member, where your policy allows it and your staff have been consulted; retention set by you. A plain PDF reader for everything else.
The route on the accepted plan can be handed to your charting application on the same device: Lido mPilot or ForeFlight today; others as their publishers permit and your programme approves. A hand-off, opt-in, switched on by you. CrewBag holds no chart data and draws no charts.
A model offers information; it never decides. On the ground it helps prepare the day from the documents on the device. In flight the personal edition shows a METAR, TAF or NOTAM as issued, from a rule the crew member set; it is a display, not an AI.
You climb the ladder, we never climb it for you: no alerts at all; alerts from deterministic rules only; then model help at EASA Level 1A or 1B, at your request, inside your approval, once EASA's AI rules under RMT.0742 are adopted. It is an option in the table below.
Every step is your switch, disclosed at the point of use, never in a signature step. Models run at Mistral AI on EU servers; nothing of yours trains any model. EASA's Concept Paper and NPA 2025-07 are our design baseline, not binding law, and confer no approval on us.
Build your package
The core is the three sections above: the app your crews get, the controls you hold, and the acceptance chain. Everything below is an option: scoped with you, priced in the contract, switched on by you inside your approval, and carried in the same version-pinned build and the same trail. Each option is a tool inside an approval you hold and a procedure you own. None of them makes you compliant, prevents an error or replaces a check; your procedures do that, and the option records what your people did. Nothing below is in the product today unless its status says so.
| Option | What it does | Your approval it sits under | Status |
|---|---|---|---|
| Performance and mass & balance display | Your provider's output as delivered: take-off and landing figures, mass and balance, engine-out procedures and EOSIDs as text. Provider, inputs and time of computation on screen; nothing recomputed, nothing drawn; superseded the moment an input changes. | Your EFB approval, type B (AMC3 CAT.GEN.MPA.141(b)); CAT.POL.MAB.105(b) and (c), your integrity check, your signatures; your provider contract | On request |
| OFP provider connection | The plan reaches the crew's device from your dispatch or provider, with the integrity hash recorded at import. | Your EFB approval (AMC3(a)(3)); your OFP provider's system, described in your operations manual | On request |
| ACARS / AOC datalink | Out, off, on and in times into the flight record automatically. | Your EFB approval, type B (AMC3(d), AOC communications); your datalink contract; never air traffic services | On request |
| Weather and NOTAM screens | Displays for your routes and bases in the order your operations manual sets. Information as issued, never redrawn, source and time on every line. | Your EFB approval, type B (AMC3(a)(4), (a)(6), (g)) | On request |
| Reporting | Occurrence and safety reports, your fatigue reports where you run fatigue risk management, or your own forms, raised from the crew's device and routed to the persons you designate, never to an authority; reporter identity confidential by design; the flight record attached under your confidentiality rules. Where your contract includes it, the module is the collection, routing and storage tool of your mandatory and voluntary reporting systems, operated under your procedures and your just-culture rules, with reports exported in the form your authority sets, ECCAIRS-compatible. | Reg. 376/2014 and ORO.GEN.160: your reporting system, your designated persons; the contract | On request · in the contract |
| Technical log, read | Aircraft status and open items on the commander's device at acceptance. An electronic technical log of our own is a longer-term option: approved at initial issue by your competent authority, change-managed under your CAMO, scoped after the read is in service. | Part-M M.A.306, your CAMO; the read under your EFB approval (AMC3(a)(1)) | On request · read first |
| Turnaround channel | Ground handling and flight deck on one channel: loadsheet ready, fuel ordered, boarding complete, doors, pushback request. Common buttons on both sides, delivery state always visible, every event kept. Replaces no check, never reaches air traffic services, no loadsheet figures. Voice notes optional, recorded under your policy. | Your EFB approval, type B (AMC3(d)); your PED policy (AMC1 CAT.GEN.MPA.140(e)); never air traffic services | On request |
| Rostering | Rosters and changes published to the crew's device, with acknowledgement receipts where your policy allows it, and the duty and flight-time totals your crews already read. From a spreadsheet or a feed you provide. | ORO.FTL.110, your crew-control procedures; GDPR, you as controller | On request |
| Documents and read receipts | Operations manual, notices, bulletins and checklists in the revision you released; a plain PDF reader for the rest. Read receipts where your policy allows it and your staff have been consulted; retention set by you. | Your EFB classification, type A or B by content (AMC2(a), AMC3(a)(1)); your document control; GDPR and staff consultation for receipts | Reader available receipts on request |
| Fleet view and audit export | Who has accepted what, on which version; open items; exports for your auditors and your authority, from the same trail. You are the controller of that record. | Your EFB administration (SPA.EFB.100(b)(3)); GDPR, you as controller | On request |
| Crew messaging | Messages per flight and per rotation, verified crew only, retention set by you, on your tenancy. | Your communications policy; GDPR, you as controller | On request |
| Storage | A tenancy we run in the EU, listed in your risk assessment as an interface; or your own servers with the same software, under your keys, no access by us unless you grant it; or a mix with the archive on your side. Encrypted in transit and at rest, access logged, export on demand. | ORO.GEN.220 and ORO.MLR.115, your records; your Part-IS risk assessment, where we are an interface; GDPR Art 28 for the hosted option | On request · your choice |
| Alerts and model help | The ladder you climb: no alerts at all; alerts from deterministic rules only; then, once EASA's AI rules under RMT.0742 are adopted, model help at Level 1A or 1B at your request. Each step your switch, disclosed at the point of use, never in a signature step. | Your EFB approval (AMC3(g)); EU AI Act Art 50 at the point of use; EASA's AI rules under RMT.0742 once adopted | On request · off by default |
| Something else | Tell us what your operation needs and cannot get at your size. If it belongs on a crew member's device and inside your programme, it can be an option. Anything that computes performance, shows aircraft position or writes into a regulated record is not. | Scoped with you | Scoped with you |
We do not classify our own software. You classify an application inside your programme and, for a type B application, your competent authority approves its use. What we bring is the evidence pack, prepared with you, and a security posture that is operated, not promised.
| Framework | What it means for you | Where we stand |
|---|---|---|
| EASA EFB rules · FAA AC 120-76E | CAT.GEN.MPA.141 and SPA.EFB.100 with their AMC/GM (ED Decision 2019/008/R). CrewBag for Operators is built to be classified and approved as an EFB application inside your own EFB programme. Only you and your competent authority can do that; we supply the evidence for your dossier: software description, change-control record, data-integrity design, failure modes, human-factors notes, training material. | Evidence pack drafted with you |
| EASA Part-IS | We contract as a supplier inside your Part-IS information security management system: our activities work under your oversight, and your competent authority may have access to us on request, as IS.I.OR.235 requires. Security events reach your named contact within 24 hours, with what your own 72-hour report needs. | Contracted supplier |
| EU AI Act | Model-assisted features are disclosed at the point of interaction, propose and never decide, and enter no signature step. The operator edition's AI behaviour is designed against EASA's published AI work — Concept Paper Issue 02 (2024) as our baseline, and NPA 2025-07 (RMT.0742) as the rulemaking proposal we track. Neither is binding law today and neither confers any approval on us. Models run at Mistral AI on EU servers; nothing of yours trains any model. | Designed in |
| ISO 27001 | An information-security management system: risk register, statement of applicability, access reviews, change and incident records, management reviews on a calendar. | ISMS in build · readiness checked on a dated calendar |
| SOC 2 Type II | Trust services criteria with evidence over an observation period. The evidence trail is being accumulated now. | Evidence being gathered · observation period ahead |
| GDPR | Data protection by design: personal data on the device by default, a records register, a rights process, processors named in the policy, EU hosting. | In place |
| DO-200B · ED-76A | We do not process aeronautical data under DO-200B/ED-76A. State text is republished as issued, with publisher, reference and AIRAC cycle shown, and flagged for re-check at every cycle boundary. | Republication, not processing |
| NIS2 | Where you are an essential entity, your supplier demands flow down to us. We answer them from the same control set. | Answered on request |
We are not ISO 27001 or SOC 2 certified today. Policies, a risk register, access reviews and incident records exist and are dated; the statement of applicability and the internal audit are the open items on our own readiness check. A contract with you carries certification as a commitment with a date.
A working session with your EFB administrator, flight operations and IT: which capabilities, which fleets, which data stays where.
Engineering starts when you commit. You receive release candidates with their change records and the evidence pack drafted for your programme. Your evaluation, your pace.
Version pinning, change control and the archive run under your control. Changes ship as releases you approve; incidents and reviews are recorded and shared.
We walk you through the application on a device, the acceptance chain, and the evidence pack outline for your programme. Bring your EFB administrator.
We answer every request. Nothing on this page is an offer; scope and price are set in the contract. Contracting party: Menegoz Aero Systems (in formation); named in full in the contract.