TurnaroundIQ

Simulate airport disruptions, compare feasible recovery plans, and prove every decision with an auditable evidence trail.

Comment

TurnaroundIQ — Every Minute Matters. Every Decision Needs Proof.

The Problem

An aircraft turnaround involves multiple interdependent ground-service activities. Baggage handling, cleaning, catering, boarding, equipment availability, and departure deadlines all affect how a turnaround progresses.

When one task is delayed, the impact can extend to dependent tasks or compete for resources needed elsewhere. A recovery option that appears attractive in isolation may introduce conflicts or violate scheduling constraints.

TurnaroundIQ explores this operational problem through a working simulation: how can ground-operations teams compare disruption-recovery options, understand their trade-offs, and maintain a clear record of why a decision was selected?

The Solution

TurnaroundIQ is a simulated airport ground-operations decision-support platform. It lets users select an aircraft turnaround, trigger a disruption, calculate its impact, and compare recovery plans against a deterministic scheduling engine.

Rather than presenting an unexplained recommendation, the application exposes task dependencies, resource conflicts, estimated departure delays, feasibility checks, and the evidence behind each decision.

The application uses fictional data. It does not connect to live airport systems or issue operational instructions.

What We Built

1. Operations Overview

A central dashboard summarizes simulated turnarounds, task progress, turnaround status, equipment availability, and active disruptions. Its metrics derive from the application's shared dataset.

2. Turnaround Workspace

Users can inspect individual aircraft turnarounds through task lists and a timeline, including planned and recalculated timings, dependencies, critical-path indicators, and resource conflicts.

3. Disruption Simulator

Five repeatable scenarios are available:

  • Late baggage equipment
  • Delayed catering vehicle
  • Cleaning task overrun
  • Gate or stand conflict
  • Multiple simultaneous disruptions

Triggering a scenario updates the simulation's state and calculated schedule. Users can reset the scenario and replay it to compare outcomes.

4. Deterministic Scheduling Engine

The scheduling engine uses dependency-aware topological ordering, forward scheduling calculations, backward-pass critical-path analysis, resource-conflict detection, and schedule validation.

The engine calculates results from scenario inputs rather than relying on random scores or generated narratives. Recovery plans are checked against hard constraints, and the application can report when no feasible recovery option exists.

5. Recovery Planner

TurnaroundIQ compares four recovery strategies:

  • Accept Delay
  • Crew Surge / Parallelize
  • Equipment Reallocation
  • Partial Mitigation

Each candidate is evaluated using the actual scheduling engine. The interface compares estimated departure delay, delay saved relative to the disrupted baseline, affected tasks, and constraint violations. Infeasible candidates are not presented as valid solutions.

6. Evidence Ledger and JSON Export

Users can save a decision record containing the baseline, disrupted schedule, final schedule, evaluated alternatives, and constraint-validation results. Individual records can be exported as structured JSON for inspection.

The current ledger uses in-memory demo-mode storage rather than durable database persistence. Exported records provide inspectable simulation evidence, not proof of real-world operational performance.

How We Built It

TurnaroundIQ uses React, TypeScript, Vite, Tailwind CSS, and Supabase Edge Functions. The application separates its scheduling logic, scenario data, domain types, state management, and interface components.

We built the deterministic scheduling engine first so that the recovery planner could evaluate real candidate schedules rather than rely on static recommendations. We then added disruption scenarios, recovery alternatives, the evidence ledger, JSON exports, and automated tests.

Proof and Verification

The implementation reports:

  • 53/53 automated tests passing
  • TypeScript type checking passed
  • Lint completed with zero errors and one pre-existing warning
  • Production build succeeded

The tests cover scheduling dependencies, resource conflicts, disruption effects, delay calculations, recovery-plan generation, infeasibility detection, deterministic replay, scenario resets, ledger accuracy, and JSON export content.

These results demonstrate software-level functionality within the simulation. They do not establish that the system has been tested or validated at an operating airport.

Who Could Use It?

Potential users include airport ground-operations coordinators, airline station-operations teams, ground-handling providers, and aviation technology teams evaluating turnaround planning and disruption management.

These are target users, not confirmed customers or partners.

Business and Deployment Path

A potential commercial model is a SaaS licence for airport ground handlers or airline station-operations teams, with additional integration services for operational data and existing planning systems.

The next responsible step would be a controlled pilot with an airport or ground-handling partner. That pilot would use approved, anonymized historical turnaround data, operationally reviewed constraints, and domain-expert evaluation to compare simulated outcomes with the partner's existing workflow.

Only after validation, security review, and appropriate operational approvals should any real-world deployment be considered.

What We Learned

A decision-support tool is only as useful as its constraints, calculations, and evidence. A polished interface or AI recommendation is not sufficient if the proposed schedule is infeasible or its reasoning cannot be inspected.

Building TurnaroundIQ reinforced the value of separating candidate generation from independent validation. It also showed why deterministic calculations, repeatable scenarios, and an auditable decision history matter when developing software for operational environments.

Current Limitations and Next Steps

TurnaroundIQ is a demo-ready simulation, not a certified aviation product. It uses fictional data, has no live airport integration, and has not undergone real-world airport validation. The evidence ledger is currently in-memory.

A server-side Jev integration adapter has been implemented, but live Jev access is not configured because API credentials could not be created without available organisational credits. No live Jev recommendation is claimed. The application remains usable through its deterministic recovery planner.

Our next steps are to validate the scheduling model with aviation domain experts, test it against approved historical data, introduce durable audit storage, and evaluate a controlled pilot with an operational partner.

The Team

TurnaroundIQ was developed as a solo software prototype, covering product design, application implementation, scheduling logic, testing, and deployment.

Our goal: make disruption-recovery decisions easier to compare, validate, and explain—while proving what the software can do before making claims about where it can be deployed.

Built With

Share this project:

Updates

Submission history