Principles

Six principles, in priority order. Every other decision in the project descends from these. When two principles conflict, the higher-numbered one yields.

1. The dataset and rules engine are the product

flighthelp is infrastructure. The schemas, the rules engine, and the verified dataset are the deliverables. Every other piece of the project — the website, the contributor app, the moderation tooling, the documentation, the developer relations — exists to serve those three things.

This principle exists because the natural drift for any project with a public website is to optimize for the website's traffic. That drift produces a consumer media company, not an infrastructure project. The discipline of treating the site as a reference implementation, not the goal, has to be enforced repeatedly against the gravity of analytics dashboards and growth instincts.

Practical implication: when prioritizing engineering time, schema improvements and engine accuracy beat website features. Always.

2. The user is stressed and at the airport

When the reference website is used, it is used by someone in a hurry, on a phone, in bad lighting, often on poor wifi, sometimes after a 12-hour flight, sometimes while being yelled at by a gate agent. Speed, clarity, and offline access beat features. Every byte shipped to the browser, every millisecond of load time, every layer of marketing copy between the user and the answer makes the site worse for the actual person using it.

This principle also applies to the developer experience. The builder integrating the API is also stressed, also on a deadline, also trying to ship something. The API should be obvious. The SDKs should work without configuration. The docs should answer the actual question, not promote the project.

3. Freshness is the moat

Information about air travel goes stale fast. Airlines change baggage fees quarterly. Phone numbers get rerouted. Regulations get amended. The single durable advantage flighthelp can build over commercial competitors is being more current than they are willing to be.

Every datapoint in the system carries a verification timestamp, a verifier count, and a source link. Stale data is flagged. Conflicting data is exposed, not hidden. The project would rather show "this hasn't been verified in 6 months" than show a wrong number with confidence.

This principle is what justifies the contributor system, the scrapers, and the moderation workload. If freshness were not the moat, none of those would be worth building.

4. Community owns the truth

The verified facts in the dataset come from travelers, cabin crew, frequent flyers, and lawyers — not from paid staff. Staff facilitate; they do not gatekeep. Every claim traces to a source. Every revision is logged. Every contributor's reputation is earned and public.

This principle is what makes the dataset trustworthy in a way that no commercial competitor can match. A claims company's data is suspect because they profit from particular interpretations. flighthelp's data is the joint product of thousands of people who individually have no stake in any particular outcome.

The community must be respected as a peer, not used as free labor. Recognition is real. Governance includes them. Contributors set policy alongside the core team.

5. No conflicts of interest

No advertising. No affiliate revenue. No paid placements. No "sponsored" results. No "preferred" airlines. No commercial partnerships that affect editorial decisions about which contact methods rank higher, which scenarios get covered first, or which airlines get more attention.

This rule is absolute and is the hardest to keep. Every successful infrastructure project gets offered money to bend it. The non-profit structure, the public books, the governance documents, and the cultural memory of the project all exist to keep this principle intact across decades and personnel changes.

Revenue comes from commercial API tiers (where the consumer pays for scale, not for favorable treatment), foundation grants, enterprise licensing for SLAs and support, and donations. No category of revenue creates editorial obligations.

6. Open by default

The dataset, schemas, scrapers, rules engine, reference website, and SDKs are all open source. The dataset is CC-BY 4.0; the schemas, scrapers, engine, and SDKs are MIT; the website is AGPL. The licenses are chosen so that downstream use is frictionless and downstream forks remain open.

Only three things stay private: the moderation tooling (to prevent gaming), the contributor risk-scoring system (to prevent farming), and the internal analytics (to protect user privacy from any external party including ourselves).

Openness is not a marketing position. It is the architectural commitment that makes the infrastructure durable. If the foundation were closed, the project would be a single-point-of-failure non-profit. Because it is open, the dataset and code survive any organizational collapse. If flighthelp the entity fails, the data and the engine continue to exist and can be picked up by anyone.

How the principles resolve conflicts

Principle 1 beats principle 2. The reference website should be excellent, but if making it more featureful would take resources away from the schemas or the engine, the schemas and engine win.

Principle 3 beats principle 4. If the community votes for a position that conflicts with verified evidence from a primary source, evidence wins.

Principle 5 beats principle 6. If an open data partnership would create editorial obligations, the partnership is declined even at the cost of some openness.

Principle 6 beats principle 1. The dataset and engine being open is more important than them being polished. A rough open thing beats a perfect closed thing.

These tie-breakers are documented because future leadership will face cases the founders did not anticipate. When that happens, the resolution should be derivable from the principles, not improvised.