Examples of Substantial Implementation

1. Flight Delay and Compensation Logic (APPR Rule)

File: src/services/claimEstimator.ts

This flow computes the amount of compensation the user can receive according to the APPR Canadian flight compensation regulations.

• It fetches flight data from our PostgreSQL database directly instead of getting it from an external API.
• It figures out the final arrival delay by checking the scheduled and actual arrival times.
• It specifies the compensation amount according to the official APPR regulations by taking into account the airline size (large or small) and the flight delay duration.
• This regulation indicates that even though there are connecting flights, the delay is to be measured at the final destination which is the demand of Canadian law.

Related core functions:

• calculateFinalArrivalDelayHours()
• apprDomesticCompensationFromHours()
• airlineSizeFromCode()
• estimateApprDomestic()

2. Final Arrival Delay Calculation for Connecting Flights

File: src/services/delayService.ts

This module analyzes a user’s complete flight itinerary to determine how much later they arrive at the final destination.

• It does not rely on any outside services but works with flight timestamps in the database.
• It processes connecting flights by adding delays cumulatively (for example if Flight A’s delay causes you to miss Flight B, the total delay is calculated at the final arrival of Flight C).
• This reasoning is applied to the compensation rules therefore ensuring correctness for itineraries with several segments.

Related core functions:

• calculateFinalArrivalDelay()
• calculateCompensationForItinerary()

3. Background Jobs for Data Management

Files:

• src/jobs/flight-cleanup-job.ts
• src/services/flight-cleanup.ts

We put in place a system of automatic background jobs that would allow the database to be cleaned and updated regularly.

• Every day, the cleanup service operates and eliminates old flights (flights that have actual arrival dates beyond the set threshold).
• As a result, it not only prevents the accumulation of unnecessary data but also makes sure that only pertinent flight records are kept for initiating compensation checks.
• The jobs that are associated with this process are scheduled and executed automatically without depending on the APIs of any third parties.

4. Business Rules & Data Integrity

• Our logic follows specific business rules:

  • Delay < 3 hours → no compensation
  • Delay between 3–6 hours → partial compensation
  • Delay ≥ 9 hours → maximum compensation

• Compensation values differ by airline size (large vs small)

• All calculations are based on validated flight data that is obtained directly from our database. This guarantees the reliability of the data and the non-reliance on API responses.

5. N8N & AI Automation

Files:

• Claim Generation.json
• Airline Claim Response Evaluator and Generator.json
• ChatbotResponseGenerator.json

This implementation handles the creation, response evaluation, counter-offer generation, and chatbot response generation for AERO.

• Uses LLM nodes in N8N to create workflows that parse and extrapolate conclusions based on data related to flight delays and cancellations. Mainly by referencing the APPR laws, it is able to create claims, evaluate claim responses for fairness and create counter claims if they aren't, and also generate messages for the chatbot based on user input to assist them with flight delays, cancellations and general airport knowledge.
• Incorporates JSON nodes to help parse data outputted by LLM nodes throughout the workflow.
• Relies on webhook triggers and email triggers to start up.

6. Real-Time Disruption Dashboard & Data Visualization

Files:

• components/live-disruption-metrics.tsx
• hooks/use-realtime-metrics.ts
• hooks/use-airport-metrics.ts

This implementation translates raw backend flight data into an interactive, highly responsive dashboard for the user.

• It utilizes a custom sliding carousel architecture with dynamic pixel-snapping that recalculates seamlessly based on the user's device size (mobile vs. desktop).
• It implements a custom AnimatedCounter utilizing requestAnimationFrame to create smooth, performant number tickers for financial and claim metrics.
• It integrates VictoryPie to dynamically map and render visual disruption ratios (Delayed vs. Cancelled vs. Unaffected) for individual airports, calculating exact percentages and fallbacks on the client side.

Related core functions:

• AnimatedCounter()
• Dynamic snapping logic via useBreakpoint()
• Time-frame toggling state management

7. Instant Eligibility Checker & Complex Form Validation

File: app/(tabs)/index.tsx

This flow manages the critical first step of the user journey by verifying if their flight qualifies for compensation before they enter the full claim pipeline.

• It implements strict client-side validation using Regex to ensure flight codes (e.g., AC123) and dates are perfectly formatted before ever hitting the backend, saving API calls and reducing server load.
• It utilizes a complex UI state machine to seamlessly transition the user interface between "Idle", "Checking/Loading", "Eligible", and "Ineligible" views without requiring a page reload.
• It integrates a custom Popover DatePicker system that adapts to the device's native color scheme (dark/light mode) to capture scheduled departure times in precise UTC formats.

Related core functions:

• validateInputs()
• handleCheck()
• Conditional UI rendering blocks

8. Intelligent Claim Routing & Session Management

Files:

• app/(tabs)/index.tsx
• lib/auth-client.ts

This implementation handles the security and user-experience flow when a user attempts to file a claim or access protected routes.

• It continuously listens to the authentication state (authClient.useSession()) on the client side.
• It intercepts user interactions (like clicking Claim Now) and conditionally routes them based on their authorization status.
• If a user is not logged in, it acts as a smart router, capturing their intended destination (/manual-claim) and passing it through the login portal as a URL parameter. This guarantees a frictionless UX, dropping the user exactly where they wanted to be once authentication succeeds.

Related core functions:

• handleClaimPress()
• Session state observation