Next alpha stage commit

docs/product_vision.md

@@ -0,0 +1,88 @@
+# Meubility Product Vision
+
+Last updated: 2026-07-06
+
+Meubility should become an EU-wide mobility platform that combines harmonized mobility data, clear visual representation, routing, comparison, and analysis tooling.
+
+The platform should support both traveller-facing use cases and institutional planning use cases. The shared foundation is a canonical, auditable mobility dataset: sources are discovered, licensed, imported, validated, harmonized, matched to map evidence, versioned, and exposed through stable APIs and visual tools.
+
+## Product Goal
+
+The long-term product goal is to answer:
+
+```text
+How can a person or organization get from A to B, what options exist, how do those options compare, how reliable are they, what do they cost, what emissions do they produce, and what can be booked or reserved?
+```
+
+The answer should be explainable. Every route, price, emission estimate, reliability prognosis, and availability signal needs provenance and confidence metadata.
+
+## Target Audiences
+
+- General public travellers who need understandable route options across public transport, walking, biking, driving, and shared mobility.
+- Public institutions, municipalities, states, and governments analyzing network quality, coverage gaps, accessibility, emissions, car dependency, and improvement potential.
+- Companies planning employee travel, business travel, mobility budgets, or commuting alternatives.
+- Municipalities, venues, and event agencies offering "car-free travel to destination" guidance.
+- Data teams and transport planners who need a workbench for source review, harmonization, QA, and publication.
+- Third-party developers and researchers consuming harmonized mobility data through APIs.
+
+## Mobility Coverage
+
+The canonical data model should eventually cover all relevant mobility options:
+
+- Public transport: rail, regional rail, subway, tram, bus, coach, ferry, cableways, and demand-responsive services where available.
+- Active mobility: walking and biking.
+- Shared mobility: rental bikes, e-scooters, car sharing, station-based rental cars, free-floating vehicles, and similar services.
+- Commercial individual transport: taxi, ride-hailing, chauffeur, rental car, and transfer services.
+- Private car comparison: routing, duration, cost, parking assumptions, and emissions.
+
+Booking and reservation support should be treated as a separate layer from route plausibility. The platform can show a plausible itinerary before it can guarantee or sell the full connection. Where booking exists, it should be clear whether the result is a deep link, a partner booking, multiple independent bookings, or a protected through-ticket.
+
+## Traveller Comparison
+
+Routing results should compare options by:
+
+- Duration and arrival/departure time.
+- Number of changes and transfer complexity.
+- Walking/biking distance and accessibility constraints.
+- Price or estimated cost.
+- Emissions.
+- Reliability prognosis, including connection risk and disruption sensitivity.
+- Booking or reservation availability.
+- Comfort and policy flags where available, such as local-transport-only, bike carriage, wheelchair accessibility, or company travel rules.
+
+Missed-connection simulation should be a first-class analysis capability: if a transfer fails, the platform should estimate the likely delay, fallback options, booking consequences, and whether the route remains acceptable.
+
+## Institutional Analytics
+
+The same harmonized dataset should support analysis for public bodies and organizations:
+
+- Coverage and accessibility by region, municipality, station, stop, venue, or event site.
+- Route and timetable gaps.
+- Missing map or timetable evidence.
+- Reliability weak points and fragile transfers.
+- Emissions and modal-shift potential.
+- Car-free access plans for events, public buildings, tourism, campuses, and large employers.
+- Source-quality reporting: freshness, license confidence, validation errors, route matching confidence, stop matching confidence, and coverage by authority level.
+
+## Platform Architecture Direction
+
+The product should be split into clear layers:
+
+1. Source discovery and licensing.
+2. Raw source snapshots and update history.
+3. Validation and QA reports.
+4. Harmonization and deduplication.
+5. Map/GTFS matching workbench and persistent reviewer decisions.
+6. Active canonical mobility snapshots for routing and analysis.
+7. Routing, comparison, reliability, pricing, emissions, and booking-readiness services.
+8. Public UI, institutional dashboard, and third-party API surfaces.
+
+GTFS harmonization remains the next critical sprint because high-quality routing, comparison, and analytics depend on stable canonical timetable data. Shared mobility, pricing, emissions, reliability, and booking layers should build on that canonical base rather than bypassing it.
+
+## Near-Term Product Implications
+
+- Keep prioritizing the GTFS harmonization and Map/GTFS workbench tracks.
+- Treat routing improvements as a parallel technical track, especially RAPTOR/CSA routing, durable caches, transfer graph precomputation, and route diagnostics.
+- Add cost, emissions, reliability, and booking-readiness as explicit future data layers in the roadmap.
+- Keep API readiness in view: harmonized GTFS and canonical mobility snapshots should become useful outputs even before the public traveller app is complete.
+- Keep institutional analytics in scope from the start, because the workbench already stores the provenance, confidence, and quality evidence that public bodies and planners need.