Hawk & Mason
One design language. One data layer. From the crew's phone to the operations desk.
Three products are in service today: the crew roster app, its company edition, and the roster fatigue assessment. The rest of the platform is built the same way, with launch operators, one module at a time, on the engines and screens your crews already know. Built by someone who flies the line.
The crew roster app. Reads the roster the airline already sends, then shows what it leaves: the FDP ceiling, the rest owed, the month's load, where the fatigue comes from. Logbook with EASA and FAA export, document wallet, widgets and a Live Activity, Crewmates. EASA, UK CAA, FAA Part 117 and SHGM rule sets, seven languages. Nothing reaches our server.
The same app, given by the airline. Crews install it from a link, enter the code your operation holds, and get the full app with the modules you chose: no subscription, no account. Your rule set and branding by arrangement. Crew data stays on the crew member's phone; the code only says which airline, until when, and which modules are on.
Drop a roster export, planned or flown, and read it the way a fatigue risk assessment does: FDP against the table ceiling, including augmented-crew limits, predicted alertness through each duty (Three-Process Model, aircrew parameters), KSS and Samn-Perelli at top of descent, the 2023 night-duty subtypes, planned versus flown for ORO.FTL.110(j). Runs in the browser; the file never leaves your computer.
A new module is not a new product. It reuses the readers, the engines, the licence and the screens the crews already have, so a first version is weeks of work, not a year.
Each of these starts as a trial with a launch operator, on your own files and your own rules, and arrives in the same app and the same design as the products above. The list is open: if your operation needs something else, that is the conversation we want.
A cabin or flight safety report opened from the crew app, with flight number, aircraft, station and crew filled in from the roster, photos attached, and the report routed to the right department. For management: open, overdue and recurring reports, corrective actions and follow-up in one view.
Who took which course, when, with which instructor, and when it expires: recurrent, LPC and OPC, SEP, dangerous goods, CRM, first aid, line checks. The crew member sees it on the phone as My Training, with what is due and what to do; the training department sees the whole fleet's calendar and gaps.
The crew member files a fatigue report from the phone; it lands in Crewops Insight next to the model's prediction for that duty. Roster pattern analysis, planned versus flown, the fatigue report register and the documentation ORO.FTL asks for, in one place.
For operators who plan in a spreadsheet: the planner drops the roster, the limit check runs before it goes out, and the roster lands on every crew phone with change notices, the same way the large crew systems deliver it.
Company notices, safety bulletins and revisions delivered to the crew app, with read receipts and acknowledgement tracking, so the operation knows who has seen what before the next duty.
OM-A, OM-B, SOPs, cabin manual, QRH and bulletins as one controlled library on the phone: revision control, read acknowledgement, offline. On top of it an assistant that answers only from your approved documents and cites the section it used.
The cosmic radiation dose per crew member from the flown sectors, the annual record per person, and the threshold notices the operator has to keep. The crew app already computes the dose per flight; this is the operator's side of it.
Swap, leave and request bidding from the crew phone, with the limit check run before the request is made and an approval flow on the company side; written back to the crew system where its integration allows it.
What a change does before it is published: the limits, the rest and the predicted alertness of the crew it touches. Disruption notices to the crews concerned, and crew recovery views built on the same engines.
Flight and duty time records per crew member from the flown roster, cumulative limits over 7, 14 and 28 days and the year, planned-versus-flown rates, and the exports an authority audit or an FRM review asks for. The crew app's logbook engine, run for the whole operation.
The crew app carries a library of sleep, body-clock and fatigue advice cards, each with its evidence grade and source, in seven languages. An operator can add its own guidance to it. What a crew member records about sleep or health stays on the phone; the operation sees the library, never the person.
NetLine/CrewLink and JetXBit today, AIMS, Leon and calendar feeds by file or page, and an API for your own systems so the platform reads from and writes to what you already run. A reader for a new system is written from one sample export.
knows the crew member reports at 05:20 tomorrow, and what the duty leaves in limits and rest.
knows the SEP recurrent expires in 42 days and there is no session on that day.
knows an open report on that aircraft from last week is waiting for follow-up.
knows a new SOP revision was published and not yet acknowledged.
says it in one line the evening before: three things for tomorrow's duty. That is what a digital operations layer looks like from the crew seat.
Send one roster export, or open Insight on it yourself. We read your format, your rule set and your operation before anything is proposed.
Weeks, not quarters: the module is built on the shared base and goes to a group of your crews or your department, in the same app they already have.
One code opens the crew edition, Insight and the modules you chose, for the period you chose. No per-seat accounts, no fitness-to-fly claims, your systems and records prevail.
Crew data stays on the phone. Insight runs in your browser. Company records run in a workspace set up for your operator, with the data-flow map in the proposal.
A roster export, a problem your current system does not solve, or a module you do not see here. One developer reads it and answers within a working day, in English or Turkish.
Yes. Most operators start with Crewops Insight on their own roster export, or with Crewops Crew for a group of crews. Every further module is added on the same licence, in the same app and the same design, and it starts as a trial on your own files.
Crew data stays on the crew member's phone: roster, sleep, fatigue and health data never reach a Hawk & Mason server. Insight runs in the browser on your own computer. Company modules that need a shared record, such as safety reports or training records, run in a workspace set up for your operator, and the data-flow map is part of the proposal.
No. Crews install Crewops Crew from a link and enter the code your airline holds. No subscription, no account; the code says which airline, until when, and which modules are on.
NetLine/CrewLink and JetXBit with live sync; AIMS eCrew, CrewConnex, FLiCA, Leon, CAE Crew Access, RAIDO and Sabre CWP through their roster pages, PDFs, spreadsheets or calendar links; any .ics calendar or roster PDF. A reader for another system is written from one sample export.
It implements a published biomathematical model and documents its limits. It supports a fatigue risk assessment and the FRM documentation ORO.FTL asks for; it is not an FRMS by itself and it makes no judgement about any person's fitness to fly.
Tell us what your operation needs. The readers, the engines, the fatigue model, the licence codes and the crew app are shared by every module, so a new one starts from a working base. Write to hello@hawkmason.com with the problem; we answer with a first-version plan.
Crewops is independent. Crew system names belong to their owners and are used only to say which formats the platform reads; no endorsement is implied. Insight implements a published model and is not a fitness-to-fly judgement. Operator systems and records prevail.