OpenFlightOps — the stack for flight operations

The operational application layer for flight operations. OpenFlightOps consolidates heterogeneous data streams from aviation operations into an audit-proof data foundation, validates them in cascading layers and delivers the result as a real-time decision service — for the cockpit, for ground handling, for compliance evaluation. Apache 2.0 as the foundation, on-premise-capable, exit-ready.

OpenFlightOps is built for airlines, cargo carriers and state air-transport units whose flight operations demand more than a reporting layer: real-time response, an audit-proof data trail, the wet-lease reality, regulatory obligations from ReFuelEU through CORSIA to NIS-2. The stack ingests heterogeneous operational data streams, keeps every version intact, validates in cascading layers and makes the result available for operational use cases — from cockpit decision services to compliance evaluation at the desk.

What OpenFlightOps does

Aviation standards from day 1. Parsers for the operationally relevant data streams of flight operations are included in the stack — flight planning, dispatch, weight & balance, air-traffic data, telemetry, messaging, fuel data. New source systems or wet-lease partners are added via a low-code parser framework, activated in days instead of weeks. No custom development per data source.

Validation in multiple layers. Aviation data contradicts itself by design — five data sources yield six statements, plan expectation diverges from reality, wet-lease partners deliver their own interpretations. The stack consolidates via a declarative, low-code-configurable rule set, combined with statistical outlier detection and an ML-based scoring layer. Tolerances are parameterizable, every correction documented in an audit-proof way.

Audit trail down to the original source. Every incoming document is stored unchanged in its own repository. Hash chain plus RFC 3161 timestamps anchor the inventory cryptographically. Every consolidated figure, every compliance report, every audit statement has a full path back to the original document — the basis for ReFuelEU reporting, CORSIA evidence, tax audits, insurance cases and internal forensics.

Real-time decision services. On the consolidated data foundation, operational decision services can be defined that work in live operations — not in daily reporting. Data integration, rule set and deployment pipeline are in place; setting up a new service becomes a configuration matter.

ML layer on operations data. A pre-integrated browser IDE plus MLflow as experiment tracking, model registry and Kubernetes-based training runtime — all on the same consolidated data foundation. Data scientists work directly on production-near data. Application areas: fuel forecasting, delay prediction, anomaly detection, misconnection risk scoring, predictive maintenance.

A cross-cutting property across all five: low-code configurability. Validation rules, routing templates, parser configurations, decision-service logic, severity scales — all adjustable via runtime configuration. Business analysts maintain them, no engineer needs to change code. New compliance frameworks, new wet-lease partners, new decision services go to production without a release cycle.

In productive use

The productive implementation has been running for several years — wet-lease integration, fuel consolidation, decision services for the cockpit, ML layer on a shared data foundation. Hundreds of thousands of flights per period, continuous validation, audit-proof audit trail.

Open source and entry

OpenFlightOps runs on Rahla, the Apache 2.0 runtime from datatactics. No licensing chains, no vendor lock-ins, exit-ready in standard formats. You operate on-premise, in any cloud or hybrid — the storage layer is configurable, not predetermined. The consequence: you can take the stack with you if you want to part with us. We operate and develop because you want us to — not because a licensing lock holds you in place.

The entry runs through the Tactical Assessment: 30 minutes online, an experienced engineering lead listens and gives the read still in the call. If it fits, the Architecture Sprint follows with a validated implementation plan plus a fixed-price proposal for the engineering phase.