Real-time aircraft disruption detection, recovery option scoring, role-gated approval and OCC propagation — supported by implemented aviation logic including multi-AOC, readiness, audit and human-approval controls.
Operational prototype. This presentation covers capabilities confirmed working in the Verum platform as of May 2026. Live demo: GBC Air scenario AOG-01 — KMIA hydraulic failure.
This is a controlled Stage 2 demonstration environment prepared for IAGi review. It does not represent the final production hosting architecture. Production-readiness planning includes migration from controlled demo hosting to secure cloud/server infrastructure.
Multi-AOC architecture includes aircraft-to-AOC mapping, AOC status checks, crew approvals per AOC and FTL framework resolution — allowing Verum to support operators across multiple AOCs, regulatory frameworks and jurisdictions.
When an aircraft goes unserviceable, a controller must simultaneously manage crew legality, aircraft availability, passenger rights, cargo commitments, and regulatory compliance — in under 30 minutes, often without automated decision support.
Industry benchmark: OCC controllers take 20–40 minutes to assemble recovery options manually across fleet, crew, and MX systems — by which time slot windows may have closed.
A delayed passenger flight on a short-haul sector triggers EU261 Art. 7 claims of €250–€400 per eligible passenger, plus duty-of-care obligations within 2 hours of notification. Every minute of delay counts.
Manual IRROPS decisions leave no structured audit trail. Post-incident reviews — regulatory, safety, or insurance — cannot easily reconstruct who decided what, with what information, at what time.
Verum is GBC Air Technical Services Ltd.'s integrated airline operations system — designed as a multi-departmental seamless solution, including OCC, crew control, disruption management, compliance and dispatch readiness. One control surface, ten operational modules, full audit chain — engineered for real airline operations.
Verum is developed by aviation specialists around real operational workflows — not as a generic software product retrofitted for aviation.
Flight watch, readiness gates, W&B, fuel, cargo, documentation — unified in a single OCC control surface.
FDP projector, duty-time tracking, crew legality gates — integrated directly into the disruption recovery workflow.
Configurable multi-jurisdiction regulatory logic, EU261 triage, hash-chained audit log — built into every decision and approval record.
Verum is developed by GBC Air Technical Services Ltd., led by aviation professionals with more than 30 years of combined operational, compliance and aviation management experience. The platform is built by people who understand real airline operations from the inside.
David is a seasoned aviation executive, senior pilot, instructor, check pilot and examiner, with experience in aviation company set-up, operational management and supporting operators in improving their performance.
dbarma@gbc-air.comMarc has extensive front-line aviation operations experience across short and long-haul environments. His background in project management, compliance, performance and aeronautical systems supports his role as primary architect of Verum.
magusti@gbc-air.comVerum IRROPS is a connected engine chain that takes an aircraft impact event and drives it through recovery scoring, human approval, execution, and system-wide propagation — with every step recorded.
Aircraft, Crew (FDP/docs), W&B, Fuel, Cargo, Checklist, Documents. Real B737-800F limits. Configured for multi-AOC regulatory logic. Each gate has an alert upsert path.
Forward duty-time projection per crew member. Per-sector breakdown. BREACH_PROJECTED / AT_RISK / OK classification. Read-only — never mutates duty state.
5-state triage lifecycle. EU Art. 7 exposure calculation (€250/€400/€600). Hash-chained audit log. Human-decision gated. Advisory output only.
In the 65 minutes between AOG declaration and departure block, the OCC must:
The moment GBC-737-02 is declared unserviceable, the Decision Queue engine
classifies it as an AOG issue at home station, scores it CRITICAL,
and positions it at the top of the queue. The network exposure banner turns RED.
Priority is computed in real-time: SEV_WEIGHT × urgency_multiplier × network_factor.
At T-65 min, this flight is in the highest urgency tier.
T–65 min to STD
The Recovery Engine evaluates all dispatchable fleet against three gates:
Safety (airworthiness, CofA), Legality
(FDP headroom, crew documents), Feasibility
(station match, schedule conflict window, turnaround time).
GBC-737-04 scores FEASIBLE — same type, same station,
no conflicting schedule in the slot window. Cost breakdown is pre-computed.
GBC-737-04 · KMIA · B737-800F · FEASIBLE
The controller selects GBC-737-04 as the donor aircraft and submits the
AIRCRAFT_SWAP decision. A native confirmation modal fires before the
record is created — preventing accidental submissions.
The governance engine routes this to Senior OCC approval automatically.
The flight state does not change. The operation is still on GBC-737-02
until the approval completes and execution runs.
DEC-001 · status: AWAITING_APPROVALAPR-001 · approvalClass: MANDATORY
The Senior OCC reviews the decision record — aircraft, flight scope, cost — and approves.
The DEC transitions to READY. Execution is now permitted.
On execution, the engine writes a field-level mutation log:
exactly which flight, which field, from what value, to what value,
by whom, at what time. This record is permanent.
AWAITING_APPROVAL → READY → EXECUTEDaircraft: "GBC-737-02" → "GBC-737-04"
The Propagation Engine fires 10 ms after execution and runs all registered reconcilers
in one pass. Flight Watch, Readiness, Alert state, FDP Projector, and the OPS Timeline
all reflect the updated aircraft assignment automatically.
The AOG-01 issue is resolved from the queue. Readiness re-evaluates GBC411.
The impact marker is cleared from GBC-737-02's scope.
gbc:decisionExecuted → gbc:alertsReconciled → gbc:timelineRefreshRequested
From AOG declaration to confirmed swap: detection, option scoring,
approval routing, execution, and state propagation — all inside a
single operational loop. Every action is timestamped, role-attributed,
and recorded in the immutable audit log.
The controller's next task is already visible in the queue: the FDP
breach on CM001 still requires resolution.
Every disruption touching a passenger-carrying flight generates an EU261 regulatory exposure case automatically. The OCC does not need to trigger it manually.
EU261 advisory exposure awareness — implemented. Passenger-impact triage, eligibility screening, exposure estimate and audit trail are included.
Formal claim resolution, passenger communications, GDS rebooking and finance posting are outside this demo scope. The EU261 engine gives the OCC early-warning awareness — human review and downstream action remain with the operational team.
The audit log uses SHA-256 hash chaining. Every record references the hash of the previous entry. Any tampering breaks the chain and is detectable. Human-gated transitions cannot be skipped — the state machine enforces them in code, not policy.
Every audit log entry carries the SHA-256 hash of the previous entry. The chain is verifiable independently. Tampering with any entry invalidates all subsequent hashes.
State machine enforced in engine code. REVIEW_REQUIRED → DUTY_OF_CARE_ACTIVE requires actor_kind = 'USER'. An API call with the wrong actor is rejected — no bypass path exists.
Every DEC and APR record carries approvedBy, approvedAt, and approvalReason — immutable after write. The execution record inherits the approver's identity.
This IAGi demo shows how Verum's IRROPS module supports operational disruption management inside an integrated airline operations environment.
This is a read-only demo environment using simulated / anonymised operational data. It is designed to demonstrate the workflow, control logic and audit discipline of Verum without connecting to live airline systems.
EU261 advisory exposure awareness — implemented. Passenger-impact triage, eligibility screening, exposure estimate and audit trail are included in this demo.
Formal claim resolution, passenger communications, GDS rebooking and finance posting are outside this demo scope.
Verum is presented as a working operational prototype / beta. This platform is designed for real airline operations and is engineered for production extension.
Verum is not a notification dashboard. It is a decision engine that integrates regulatory logic, fleet state, crew legality, and governance into a single operational loop.