mech.app
Automation

Will My Flight Have Starlink? Reverse-Engineering Aircraft Equipment Assignment Pipelines

How a flight predictor built a database of Starlink-enabled aircraft by scraping tail numbers, equipment assignments, and fleet rollout data.

Source: news.ycombinator.com
Will My Flight Have Starlink? Reverse-Engineering Aircraft Equipment Assignment Pipelines

A developer built a tool to answer one question: will my flight have Starlink? The project (stardrift.ai/starlink) exposes the data reconciliation and prediction challenges that agents face when tracking equipment rollouts across fragmented, time-delayed airline systems. Starlink availability on flights is patchy. Airlines roll out connectivity aircraft-by-aircraft, and equipment assignments change days before departure. The developer built a database of which airlines, aircraft types, and specific tail numbers have Starlink, then layered a prediction engine on top.

The Hacker News thread (276 points, 362 comments) reveals strong interest in the infrastructure behind equipment tracking. The tool checks three things in order: Does this airline have Starlink? Does this aircraft body type have Starlink? Does this specific aircraft (identified by tail number) have Starlink? The first two questions are easy. The third requires tracking tail number assignments, which airlines only publish a few days before departure.

The Data Pipeline: Fleet Databases to Tail Number Lookups

Airlines operate mixed fleets. United has Starlink on some 737s but not others. Air France has it on A350s but not A320s. The developer needed to map airline codes, aircraft types, and individual tail numbers to Starlink status. This requires scraping multiple sources: airline press releases, fleet tracking sites, and real-time equipment assignment APIs.

Data sources for aircraft equipment tracking:

Source TypeCoverageUpdate FrequencyAccessUse Case
Airline press releasesPartial (announced rollouts only)Irregular (months)PublicInitial fleet mapping, rollout timelines
FlightAware / FlightRadar24 APIsGlobal, real-timeMinutes to hoursPaid ($50-$500/month)Tail number lookups, equipment assignments
Airline booking systems (GDS)Complete for bookable flightsDailyRestricted (travel agents, partners)Equipment type per flight number
Crowdsourced databases (SeatGuru, FlyerTalk)Spotty, user-reportedVariable (days to weeks)FreeValidation, gap-filling
Direct airline APIs (United, Delta)Airline-specific, accurateReal-timeRequires partnershipProduction integrations

The developer likely combined press releases (to identify which airlines have Starlink at all) with FlightAware-style APIs (to look up tail numbers) and manual crowdsourcing (to validate which specific aircraft have been retrofitted). The result is a database that maps tail numbers to Starlink status.

State Reconciliation: When Is a Tail Number Assignment Final?

Airlines assign aircraft to flights dynamically. A 737 scheduled for your route today might be swapped for an A320 tomorrow due to maintenance, crew availability, or load balancing. Tail number assignments typically finalize 24-72 hours before departure. Before that, the best you can do is calculate probability.

Prediction strategies under uncertainty:

Equipment type probability: If United has Starlink on 60 of 100 737s, and your flight is assigned a 737 (but not a specific tail), the tool estimates 60% probability. This requires maintaining a count of Starlink-enabled vs. total aircraft per type per airline.

Historical assignment patterns: If a specific flight number (e.g., UA123 SFO to JFK) has been assigned Starlink-equipped aircraft 80% of the time over the past 30 days, use that as the prior. This requires logging tail number assignments per flight number over time.

Real-time tail number lookup: Once the tail number is assigned (visible in airline booking systems or FlightAware), look it up in the Starlink database. If the tail is in the database, return 95% confidence (allowing for last-minute swaps). If not, return 5% (allowing for database staleness).

Fallback to equipment type: If tail number lookup fails (API down, tail not yet assigned), fall back to equipment type probability. Display “Estimated based on fleet average” to manage user expectations.

The tool’s logic likely follows this cascade: check airline, check aircraft type, check tail number (if available), calculate probability if tail is unknown. The developer mentions that tail numbers are “usually only assigned a few days before a flight,” so the tool must handle both pre-assignment (probability mode) and post-assignment (lookup mode) states.

Code Sketch: Tail Number Probability Calculation

from typing import Optional, Dict
from datetime import datetime, timedelta

# Example fleet database (in production, this would be a SQL table or key-value store)
STARLINK_FLEET = {
    "UA": {  # United Airlines
        "737": {"total": 100, "starlink_enabled": 60},
        "787": {"total": 50, "starlink_enabled": 50},
        "777": {"total": 30, "starlink_enabled": 0}
    },
    "AF": {  # Air France
        "A350": {"total": 20, "starlink_enabled": 20},
        "A320": {"total": 80, "starlink_enabled": 0}
    }
}

# Tail number to Starlink status mapping (updated via scraping or API)
TAIL_DATABASE = {
    "N12345": {"airline": "UA", "type": "737", "starlink": True, "last_verified": "2026-03-15"},
    "N67890": {"airline": "UA", "type": "737", "starlink": False, "last_verified": "2026-03-10"},
    "F-HREV": {"airline": "AF", "type": "A350", "starlink": True, "last_verified": "2026-03-12"}
}

def predict_starlink(airline_code: str, aircraft_type: str, tail_number: Optional[str] = None) -> Dict:
    """
    Predict Starlink availability for a flight.
    Returns status, confidence, and reasoning.
    """
    
    # Step 1: Check if airline has Starlink at all
    if airline_code not in STARLINK_FLEET:
        return {
            "status": "NO",
            "confidence": 0.95,
            "reason": f"Airline {airline_code} has not deployed Starlink",
            "method": "airline_check"
        }
    
    # Step 2: Check if aircraft type has Starlink
    fleet = STARLINK_FLEET[airline_code]
    if aircraft_type not in fleet:
        return {
            "status": "UNKNOWN",
            "confidence": 0.5,
            "reason": f"No data for {airline_code} {aircraft_type}",
            "method": "no_data"
        }
    
    type_data = fleet[aircraft_type]
    
    # If all aircraft of this type have Starlink, return high confidence YES
    if type_data["starlink_enabled"] == type_data["total"]:
        return {
            "status": "YES",
            "confidence": 0.95,
            "reason": f"All {airline_code} {aircraft_type} aircraft have Starlink",
            "method": "full_fleet_coverage"
        }
    
    # If no aircraft of this type have Starlink, return high confidence NO
    if type_data["starlink_enabled"] == 0:
        return {
            "status": "NO",
            "confidence": 0.95,
            "reason": f"No {airline_code} {aircraft_type} aircraft have Starlink yet",
            "method": "zero_fleet_coverage"
        }
    
    # Step 3: If tail number is provided, look it up
    if tail_number:
        if tail_number in TAIL_DATABASE:
            tail_data = TAIL_DATABASE[tail_number]
            
            # Check data freshness (warn if verification is old)
            last_verified = datetime.fromisoformat(tail_data["last_verified"])
            age_days = (datetime.now() - last_verified).days
            confidence = 0.95 if age_days < 30 else 0.8
            
            return {
                "status": "YES" if tail_data["starlink"] else "NO",
                "confidence": confidence,
                "reason": f"Tail {tail_number} {'has' if tail_data['starlink'] else 'does not have'} Starlink (verified {age_days} days ago)",
                "method": "tail_lookup",
                "tail_number": tail_number
            }
        else:
            # Tail number not in database, fall back to probability
            probability = type_data["starlink_enabled"] / type_data["total"]
            return {
                "status": "PROBABLE" if probability > 0.5 else "UNLIKELY",
                "confidence": probability,
                "reason": f"Tail {tail_number} not in database. {int(probability * 100)}% of {airline_code} {aircraft_type} fleet has Starlink",
                "method": "tail_not_found_fallback",
                "tail_number": tail_number
            }
    
    # Step 4: No tail number provided, return probability based on fleet
    probability = type_data["starlink_enabled"] / type_data["total"]
    return {
        "status": "PROBABLE" if probability > 0.5 else "UNLIKELY",
        "confidence": probability,
        "reason": f"{int(probability * 100)}% of {airline_code} {aircraft_type} aircraft have Starlink ({type_data['starlink_enabled']} of {type_data['total']})",
        "method": "fleet_probability"
    }

# Example usage
def check_flight(flight_number: str, date: str, airline: str, aircraft_type: str, tail: Optional[str] = None):
    """
    Simulate checking a flight for Starlink availability.
    In production, this would query airline APIs for tail number assignment.
    """
    print(f"Checking flight {flight_number} on {date}")
    print(f"Airline: {airline}, Aircraft: {aircraft_type}, Tail: {tail or 'Not yet assigned'}")
    
    result = predict_starlink(airline, aircraft_type, tail)
    
    print(f"Status: {result['status']}")
    print(f"Confidence: {int(result['confidence'] * 100)}%")
    print(f"Reason: {result['reason']}")
    print(f"Method: {result['method']}\n")

# Test cases showing different prediction modes
check_flight("UA123", "2026-03-20", "UA", "737", None)  # No tail, use probability
check_flight("UA456", "2026-03-20", "UA", "737", "N12345")  # Tail in database
check_flight("UA789", "2026-03-20", "UA", "787", None)  # Full fleet coverage
check_flight("AF100", "2026-03-20", "AF", "A320", None)  # Zero fleet coverage

Agent Architecture for Equipment Tracking

A production agent monitoring aircraft equipment (Starlink, WiFi, seat configurations, entertainment systems) would need:

Fleet database:

  • Airline to aircraft type mapping (which airlines fly which planes)
  • Aircraft type to equipment mapping (which types have Starlink, partial or full rollout)
  • Tail number to equipment mapping (specific aircraft with serial numbers)
  • Historical assignment patterns (which tails fly which routes, how often assignments change)

Ingestion pipeline:

  • Airline press release scraper (detect new Starlink announcements, rollout timelines)
  • FlightAware or FlightRadar24 API poller (fetch tail number assignments for upcoming flights)
  • Crowdsourced validation (accept user reports of Starlink presence, flag discrepancies)
  • Airline API integration (direct access to equipment data where partnerships exist)

Reconciliation engine:

  • Tail number normalization (handle different formats: N12345 vs. N-12345 vs. 12345)
  • Equipment status deduplication (same aircraft reported by multiple sources)
  • Staleness detection (flag database entries not verified in 90+ days)
  • Conflict resolution (if press release says aircraft has Starlink but user reports it missing, prioritize recent user data)

Prediction logic:

  • Fleet coverage calculation (percentage of aircraft type with equipment)
  • Tail assignment probability (if tail not yet assigned, use fleet average)
  • Historical pattern matching (if flight number historically uses Starlink-equipped aircraft, increase confidence)
  • Real-time lookup (once tail is assigned, query database for definitive answer)

Output and alerting:

  • REST API returning equipment status, confidence, reasoning per flight number and date
  • WebSocket stream for real-time tail number assignment updates
  • Webhook to downstream agents (travel booking bots, corporate travel policy enforcers)
  • Dashboard showing fleet rollout progress, data freshness, prediction accuracy

Failure Modes and Fallback Chains

Tail number assignment changes last-minute (aircraft swap due to maintenance):

  1. Monitor assignment changes: Poll airline APIs hourly in the 48 hours before departure
  2. Alert user of swap: If tail changes from Starlink-equipped to non-equipped, send notification
  3. Update prediction: Recalculate probability based on new tail number
  4. Log swap frequency: Track how often swaps happen per airline/route to improve future predictions

Tail number database is stale (aircraft retrofitted but database not updated):

  1. Crowdsource validation: Allow users to report Starlink presence, flag discrepancies
  2. Confidence decay: Reduce confidence for database entries not verified in 90+ days
  3. Scrape airline WiFi portals: If user connects to in-flight WiFi, detect Starlink vs. other providers
  4. Manual verification: Periodically audit high-traffic routes, update database with ground truth

Airline API returns no tail number (assignment not yet made or API failure):

  1. Fall back to fleet probability: Use aircraft type coverage percentage
  2. Display uncertainty: Show “Estimated based on fleet average, tail not yet assigned”
  3. Retry with backoff: Poll API again in 6 hours, then 12 hours, then 24 hours
  4. Alert on persistent failure: If tail never appears, flag API issue for investigation

False positive (tool says Starlink, flight has none):

  1. User feedback loop: Collect reports of incorrect predictions, update database
  2. Audit tail database: Cross-reference user reports with other data sources
  3. Adjust confidence scores: If a tail has conflicting reports, lower confidence to 70%
  4. Refund or apology: If tool is paid, offer credit for incorrect predictions

When Probability Predictions Break Down

The developer’s approach works well for partial fleet rollouts but has limits:

Use fleet probability when:

  • Tail number is not yet assigned (more than 72 hours before departure)
  • You have accurate fleet coverage data (know exactly how many aircraft have equipment)
  • Fleet rollout is stable (not actively adding new aircraft weekly)
  • Users understand probability (can interpret “60% chance” correctly)

Use tail number lookup when:

  • Tail number is assigned (within 48 hours of departure)
  • You have a verified database of tail-to-equipment mappings
  • Database is fresh (verified within 30 days)
  • Users need definitive answers (booking decisions, not just curiosity)

Avoid predictions when:

  • Fleet rollout is in flux (airline actively retrofitting aircraft, data changes weekly)
  • Tail assignment is unreliable (airline frequently swaps aircraft last-minute)
  • Database is stale (no verification in 90+ days, high risk of false positives)
  • Legal or financial stakes (do not use probabilistic predictions for contractual guarantees)

Crowdsource validation when:

  • You lack direct API access to airline systems
  • Database freshness is a concern (need user reports to validate data)
  • You have sufficient user volume (enough flights to get statistically significant feedback)
  • You can handle noise (some users will misreport, need filtering logic)

Technical Verdict

This project exposes the data reconciliation and prediction challenges that agents face when tracking equipment rollouts across fragmented airline systems. The developer built a Starlink predictor by mapping airlines to aircraft types to tail numbers, then layering probability calculations on top when tail assignments are unavailable.

Use this approach if:

  • You are tracking equipment rollouts that happen gradually (partial fleet coverage, not all-or-nothing)
  • You can tolerate probabilistic predictions (users understand “60% chance” and make decisions accordingly)
  • You have access to tail number assignment APIs (FlightAware, airline partners, or booking system integrations)