Starlink on commercial flights works when it’s available, but predicting whether your specific flight will have it is harder than it should be. Airlines roll out connectivity aircraft by aircraft, not all at once. Fleet assignments change. Tail numbers appear days before departure. The result is a prediction problem that requires reconciling incomplete, time-sensitive data from multiple sources.
A Show HN project called Stardrift tackles this by building a database-backed agent that estimates Starlink likelihood for a given flight number and date. The system combines airline rollout status, aircraft body type, and tail-level tracking to produce a confidence score. It’s a clean example of how agents handle messy infrastructure rollouts when users need answers before the data is complete.
The Three-Tier Decision Tree
The agent evaluates queries in a cascading hierarchy:
- Airline filter: Does the carrier have Starlink at all?
- Body type check: Does this aircraft model (e.g., E145, A320) have Starlink?
- Tail number lookup: Does this specific plane (identified by registration) have the hardware?
Each tier narrows the search space. If the airline hasn’t deployed Starlink, the agent returns a hard no immediately. If the body type is fully equipped (all JSX E145s, for example), it returns a confident yes. The complexity lives in the middle: partial rollouts where only some aircraft of a given type have connectivity.
Data Pipeline and Reconciliation
The agent’s database tracks:
- Airlines beyond trial phase (United, Hawaiian, Alaska, Air France, Qatar, JSX, others)
- Fleet composition by body type
- Tail-level Starlink installation status
- Equipment assignments published by airlines
The challenge is keeping this current. Airlines don’t expose structured APIs for connectivity status. The team scrapes announcements, cross-references flight tracking data, and maintains a manual mapping of tails to Starlink presence. This is brittle by design: the source data is inconsistent, and airlines change assignments without notice.
When the agent can’t find a tail assignment (common more than a few days before departure), it falls back to probabilistic inference. If 40% of an airline’s A321s have Starlink, the agent returns a 40% likelihood. This shifts the problem from binary prediction to confidence scoring.
Versioning and Temporal Drift
Flight assignments change between query time and departure. The agent’s prediction is a snapshot, not a guarantee. A user might check a flight two weeks out, see “high likelihood,” and book. By departure day, the airline swaps in a different aircraft without Starlink.
The system doesn’t version predictions or track deltas over time. It returns the current best guess based on available data. This is a reasonable trade-off for a consumer tool, but it exposes a failure mode: users treat predictions as commitments when they’re really probabilistic forecasts anchored to a moving dataset.
Architecture Sketch
The core flow looks like this:
def predict_starlink(flight_number, date):
# Step 1: Resolve airline
airline = lookup_airline(flight_number)
if airline not in STARLINK_AIRLINES:
return {"likelihood": 0, "reason": "Airline not equipped"}
# Step 2: Resolve body type
body_type = lookup_equipment(flight_number, date)
coverage = get_body_coverage(airline, body_type)
if coverage == 1.0:
return {"likelihood": 100, "reason": "All aircraft equipped"}
if coverage == 0.0:
return {"likelihood": 0, "reason": "Body type not equipped"}
# Step 3: Tail lookup (if available)
tail = lookup_tail(flight_number, date)
if tail:
has_starlink = check_tail_status(tail)
return {"likelihood": 100 if has_starlink else 0, "reason": "Tail confirmed"}
# Step 4: Probabilistic fallback
return {"likelihood": int(coverage * 100), "reason": "Partial rollout"}The database schema likely includes:
airlines(name, starlink_status, rollout_phase)aircraft_bodies(airline_id, body_type, equipped_count, total_count)tail_registry(tail_number, body_type, starlink_installed, last_verified)flight_assignments(flight_number, date, tail_number, body_type)
The flight_assignments table is the most volatile. It needs daily updates from airline feeds or flight tracking APIs.
Trade-offs and Failure Modes
| Scenario | Agent Behavior | Risk |
|---|---|---|
| Tail assigned early | Returns definitive yes/no | Low, assuming tail data is accurate |
| Tail assigned late | Returns probability based on fleet coverage | Medium, user may misinterpret as certainty |
| Last-minute aircraft swap | Prediction becomes stale | High, no mechanism to alert user |
| Airline adds/removes aircraft from Starlink fleet | Database lags behind reality | Medium, depends on update cadence |
| User queries far-future flight | No tail data, pure probability | Low, user expectations are calibrated |
The biggest operational risk is the manual data pipeline. If the team falls behind on tracking new installations or retirements, the agent’s confidence scores drift from reality. There’s no self-healing mechanism: the system doesn’t learn from user feedback or flight outcome data.
Observability Gaps
The agent doesn’t expose:
- Prediction accuracy over time (did the 70% likelihood flights actually have Starlink 70% of the time?)
- Data freshness per airline (when was the tail registry last updated?)
- Confidence intervals (is this 60% based on 10 aircraft or 100?)
Adding these would turn the tool from a lookup service into a feedback loop. Users could see how often predictions hold, and the team could prioritize data updates based on error rates.
Security and Privacy Boundaries
The agent queries public flight data and doesn’t require user authentication. This keeps the attack surface small: no user accounts, no stored queries, no PII. The main security concern is data integrity. If an attacker poisons the tail registry (inserting false Starlink statuses), users make booking decisions on bad data.
Mitigation options:
- Cryptographic signatures on database updates
- Audit logs for manual edits
- Rate limiting on query endpoints to prevent scraping
None of these appear to be implemented based on the public interface.
Deployment Shape
The tool is a web frontend backed by a database and query API. Likely stack:
- Static site (React or similar) for the search interface
- PostgreSQL or similar for the fleet database
- Serverless function or lightweight API server for query logic
- Scheduled jobs (cron or cloud scheduler) for data updates
The compute footprint is minimal. Queries are read-heavy, and the dataset is small (thousands of aircraft, not millions). The bottleneck is data collection, not query performance.
Technical Verdict
Use this pattern when:
- You need to predict outcomes based on incomplete, time-sensitive infrastructure data
- The underlying system (airline rollouts, hardware deployments) changes slowly enough that manual updates are feasible
- Users understand they’re getting probabilities, not guarantees
- The cost of a wrong prediction is low (disappointment, not financial loss)
Avoid this pattern when:
- You need real-time accuracy and can’t tolerate stale data
- The data sources are too fragmented or change too quickly for manual tracking
- Users will treat predictions as commitments (legal, financial, safety-critical contexts)
- You need auditability or compliance tracking for prediction outcomes
This agent solves a real user problem (will my flight have connectivity?) by building a purpose-fit database and a simple decision tree. It’s not trying to be a general-purpose prediction engine. The plumbing is straightforward: data collection, reconciliation, and probabilistic fallback. The hard part is keeping the data current when airlines don’t cooperate. That’s a people problem, not a code problem.
Source Links
- Hacker News Discussion (276 points, 362 comments)
- Stardrift Starlink Checker