Vision

What flighthelp looks like when it has worked.

The ten-year picture

By 2036, flighthelp is the canonical source for air-travel facts and passenger rights. Three signals confirm this:

Adoption is universal among builders. Every major AI assistant (OpenAI's, Anthropic's, Google's, Perplexity's, the Chinese labs') uses the flighthelp API or schemas — either directly or through retrieval augmentation — when answering questions about flying. Every serious online travel agency has integrated the rules engine or built on top of the API. Major corporate travel platforms use the data for duty-of-care obligations. Travel insurance underwriters use the engine for automated claim eligibility. Consumer travel apps cite flighthelp as their factual source.

The schemas are the standard. When a developer at any company models air-travel data, the first question is "what does flighthelp's schema look like?" The schemas are referenced in IATA documents, in EASA policy papers, in journalism, in academic work, in court filings. They are taught in computer science and aviation programs. Forks exist for other transportation modes (rail, ferry, coach) that explicitly adopt the flighthelp pattern.

The rules engine is cited in court. When passengers, claims companies, regulators, or airlines disagree about compensation eligibility under EC 261 or its successors, the flighthelp rules engine is one of the artifacts they reference. Specific versioned releases of the engine are cited in case law. Regulators have begun publishing their own interpretations against the engine's test fixtures so that disagreements are explicit and computable.

The numbers, ten years out

These are forecasts, not promises. They calibrate ambition.

• API: ~5 billion calls per month. Free tier serves 95% of consumers; paid commercial tier funds operations.
• Dataset: ~800 airlines, ~1,500 airports, ~200 verified regulations and amendments. Coverage is global with depth in EU, UK, Brazil, North America, India, China, and Australia.
• Contributors: ~50,000 registered, ~10,000 active, ~500 trusted, ~40 moderators, ~10 core team.
• Reference site: ~50 million monthly visitors, ~500 million pageviews, 30+ languages.
• GitHub: ~50,000 stars across the org, ~5,000 distinct contributors across all repos.
• Citations: hundreds of academic papers, thousands of journalistic references, dozens of regulator and court documents.
• Budget: ~$3-5M annual, fully published, with no single funder representing more than 15%.

What success does not look like

The wrong version of success looks like:

• A media company. High traffic to the reference site, ad-driven or sponsorship-driven, with the dataset as content moat. This is the failure mode of betraying principle 5.
• A commercial SaaS. Premium API tiers that gate the actually-useful endpoints. This is the failure mode of betraying principle 6.
• A think tank. Lots of policy papers and conferences, not much shipped infrastructure. This is the failure mode of betraying principle 1.
• A claims service in disguise. A "free" rights tool that funnels users to paid claims partners. This is the failure mode of betraying principle 5 in the most insidious way.
• A single-founder project. Tightly coupled to one person's energy, decisions, and reputation. This is the failure mode of inadequate governance.

If any of these happen, the project has succeeded at the wrong thing.

Where the project sits in the ecosystem at maturity

flighthelp at maturity is not visible to most people, the same way Let's Encrypt is not visible to most people who browse HTTPS sites. The traveler who gets a correct baggage answer from Gemini does not know that Gemini got it from flighthelp. The passenger whose claim is settled in fourteen days instead of fourteen months does not know that the claims company's eligibility engine was built on flighthelp. The OTA showing accurate carry-on dimensions does not need to credit the source.

This invisibility is the goal, not a failure. Infrastructure that works fades into the background. The traveler is helped at every step without ever needing to know that flighthelp exists. The project's success is measured in the absence of confusion, not the volume of attention.

The reference site at flighthelp.net remains the one visible surface — used by travelers without good tools, by journalists checking sources, by contributors verifying data, and as the front door for new builders discovering the API. It is small, fast, current, and proud of all three.

Generational succession

The project is built to outlive its founders. By year 10, none of the original founders should be in operational roles. The core team should have rotated multiple times. The governance documents should have been amended through their own procedures, by people the founders never met, and the project should still be recognizably itself because the principles held.

The single most important success metric is this: in 2040, does flighthelp still exist, still operate, and still serve its mission? If yes, the project worked. If no — even if it had a brilliant five years — it did not.