Proof of Performance
CONTINUOUS FLIGHT VALIDATION
~1,000 Flights Every 3-5 Minutes
Replaced manual operational checks with automated validation across the entire schedule, running continuously on a rolling multi-day horizon.
OPERATIONAL INDEPENDENCE
Business-Owned Rule Updates
Removed the reliance on core system vendors to implement new regulatory or operational constraints. OCC users now create and update rules themselves.
SINGLE SOURCE OF TRUTH
Centralized Operational Logic
Consolidated rules that previously lived in legacy systems, scattered documentation, and duty managers' knowledge into one transparent platform.
The Turning Point: From "In the Duty Manager's Brain" to a Single Source of Truth
Before DecisionRules, Wizz Air's operational logic lived in three uncomfortable places. Some rules were hard-coded into legacy systems. Some lived in scattered documentation. And some, by Wizz Air's own description, existed "mostly in the brain of the duty managers."
The decision to bring in DecisionRules was driven by a single requirement from the business: the Operations Control Center had to own its rules end to end. One specific place where every alert and warning is defined, tested, and pushed live by the people who actually run the operation, with no waiting on vendor change cycles.
The Challenge: Fragmented Logic and Vendor-Dependent Change
Before implementing DecisionRules, Wizz Air's operational rules were spread across systems, documents, and people. Three problems compounded each other:
- Fragmented logic. Rules were defined in different applications. Some were documented, some were not, and some existed only in the memory of individual duty managers.
- Manual scanning at scale. Duty managers were manually scanning the line of flights to identify issues. The approach is error-prone and was becoming impossible to sustain as the airline grew.
The result was an operation with limited clarity on why specific alerts were being raised, and no way to push a regulatory or operational update without going through a software release.
| Problem | Impact |
|---|---|
| Logic scattered across systems and people | Rules existed in different applications, in documentation, and in human memory. |
| Manual flight-by-flight review | Manual scanning of the line of flights was error-prone and unscalable. |
| No single source of truth | The team lacked clarity on why specific alerts were being generated. |
Why Wizz Air Chose DecisionRules
Wizz Air evaluated multiple tools by writing real airline use cases and trying to implement them in each, to see which was most capable. DecisionRules was selected on three criteria:
- Scalability. The engine could handle repeated processing of large flight batches across the schedule.
- Integration fit. Technical capability to integrate with the internal data lake and event bus via REST API and JSON.
- Business user independence. OCC users could create and maintain rules themselves, without heavy IT intervention.
A proof of concept was run on representative use cases to confirm that the tool could handle the complexity of airline operations logic before the team committed.
One of the main reasons we chose DecisionRules was that the business wanted to have full control of the rules. Previously, some logic was documented, but some existed only in the brain of the duty managers. We needed a specific place where we have control of all these items. Now, we can create the rules ourselves, keep them up to date, and make changes without complex release processes.
Daniil Romanov
Operations Control Center Team, Wizz Air
Implementation and Architecture
Wizz Air's solution architecture treats DecisionRules as the validation layer of a continuous flight-monitoring loop:
- Data Ingestion: Wizz Air collects data from various source systems into a database and event bus. The data is converted to JSON and sent to DecisionRules via API.
- Rule Evaluation: DecisionRules processes operational data in batches and returns alerts. Checks currently run every 3 to 5 minutes for activities scheduled within a rolling multi-day horizon
- Alert Delivery: Alerts are stored in cache. They are then displayed on the UI for the duty managers, who manage by exception rather than manual oversight.
- Authoring and Testing: OCC users build and maintain rules directly in the DecisionRules UI. The team makes extensive use of the Playground and Test environments to simulate rule updates before pushing them live.
Implementation Notes and Lessons Learned
The DecisionRules platform integration itself was straightforward. The Wizz Air team and DecisionRules collaborated closely throughout the implementation process and DecisionRules providing guidance on optimization.
Key Use Cases
- Aircraft Registration Workflow: The system alerts the OCC if an aircraft is assigned to a flight it cannot legally operate, for example because of short-runway restrictions or because the aircraft is in inactive status.
- Operational Constraint Updates: When a specific airport changes its requirements (for example, turnaround times for airports such as Prague), business users update the rule template directly without a code release.
- Other Operational Alerts: The platform raises alerts for issues such as expiring radio licenses and runway restrictions tied to specific aircraft types, which the OCC can act on before the day of operations.
Measurable Outcomes and Benefits
- Operational Visibility: The system successfully generates alerts for issues such as aircraft registration mismatches, expiring radio licenses, and runway restrictions tied to aircraft type, giving the OCC a continuous view it did not have before.
- Automation at Scale: Roughly 1,000 flights are checked every 5 minutes for the next 3 days, replacing manual scanning of the schedule.
- Business Ownership of Logic: OCC users now own the lifecycle of operational rules. Rule definitions sit with the business, while IT focuses on data integration. The team also maintains internal documentation that maps which rules belong to which workflows and data models.
- Independence from Vendor Cycles: Rules and templates can be changed on the fly (for example, turnaround times for specific airports) without code releases or vendor change requests.
Conclusion
By implementing DecisionRules, Wizz Air consolidated operational logic that previously lived across legacy systems, scattered documentation, and individual duty managers into a single, transparent platform owned by the operations team. The OCC now monitors every flight in the schedule continuously, updates rules without waiting on vendor cycles, and is building redundancy into one of the most safety-critical parts of the airline.
For Wizz Air, DecisionRules has become a critical component of the airline's digital transformation, bridging the gap between rigid legacy aviation systems and the need for agile, modern operations.
In a dynamic environment like aviation, relying on manual checks or waiting for vendor software updates is no longer an option. DecisionRules gave us the speed and control we needed to ensure compliance and efficiency at scale. If you are looking to take ownership of your business logic and automate complex decisions, DecisionRules provides the flexibility to make it happen.
Daniil Romanov
Operations Control Center Team, Wizz Air
Erik Lehocky
Head of Solution Consulting