Crew, rostered inside the rules.
Flight and duty time limits, fatigue risk and licence currency are constraints the solver works within, so the roster it publishes is legal by construction.
The applications a flight operation runs.
Crew, the buying behind them and the numbers underneath, on one platform.
A compliant roster is not the same as a roster you checked afterwards.
Most crew planning produces a roster and then audits it. Every breach found that way has already been published, already been seen by the crew, and still has to be unwound by hand.
Compliance as an input
Duty limits, minimum rest, cumulative hours, type ratings, recency and medical expiry all enter the solver as constraints. A roster that would breach one is never generated, so there is no exception queue sitting behind it.
Flight and duty limits, enforced at assignment
Duty periods, minimum rest and cumulative hour ceilings bind the solver directly. Under CASA, fatigue risk management sits alongside them as a constraint rather than as a policy someone signs off afterwards.
Currency the system will not let you miss
Type ratings, recency, line checks and medical expiry live on one crew record with their dates. A pairing that would assign an out-of-currency crew member is infeasible, so the roster cannot produce it.
Disruption absorbed, not escalated
A delay, a sick call or an aircraft swap re-enters the solve while the day is still running. The roster re-solves around what actually happened and holds every limit it held before.
What it changes for a flight operation
The roster is legal when it publishes
Breaches are prevented at solve time rather than found in an audit, so the exception queue that follows a published roster stops existing.
Utilisation without crowding the limits
Cost, coverage and fatigue are optimised together, so better utilisation comes out of better sequencing rather than out of crew running closer to their ceilings.
An auditable record of every assignment
Which constraints applied, which were binding and why a crew member was assigned are recorded with the roster, so a regulator’s question has an answer that nobody has to reconstruct.
The aviation platform, module by module.
OpenAir is the aviation platform on Mission Systems: crew rostering, flight and duty limits, currency and disruption as aviation-specific modules on the shared operational model. Launchpad solves inside the rules, records which constraint bound each assignment, and escalates only what a person has to decide.
Explore OpenAirFAQ
As hard constraints inside the solver. Duty periods, minimum rest and cumulative ceilings bind every assignment, and under CASA fatigue risk management enters the same way. A roster that breaches a limit is an infeasible answer, so it is never produced.
Yes. Limits, rest rules and currency requirements are configuration rather than code. CASA is the regime we have implemented as a worked case; another is modelled against its published rules with your compliance team in the room before anything goes live.
The solve continues after publication. A delay, a sick call or an aircraft swap re-enters as new input and the roster re-solves around it, holding every limit it held before. Crew see the change rather than a phone tree.
One record per crew member carries type ratings, recency, line checks and medical expiry with their dates. Currency is checked at the moment of assignment rather than in a monthly report, so a lapse cannot be rostered through.
You set that per capability. It can propose and wait, publish inside limits you set and tell you afterwards, or run unattended. Most operations start with approval on every publish and raise the dial as the record builds.