What TripPlanWise measures
The validation tools turn user-provided trip constraints into explainable checks. They do not claim to predict live availability or replace an official source. Each result shows inputs, triggered rules, limits, and a concrete verification list.
Trip Reality Score
The score starts at 100. Published rules deduct points for excessive daily density, short boundary days, long transfers, repeated hotel changes, self-transfers, tightly timed commitments, missing buffers, and unverified entry or airport-transfer details. Traveler profiles adjust selected thresholds rather than changing the meaning of the score.
Destination Friction Index
Twenty manually reviewed destination profiles use six ordinal dimensions: arrival transfer, local transport, payment, connectivity, language navigation, and booking volatility. City-level profiles match city names, city-country forms, aliases, and airport or city codes; a country name does not inherit one city’s profile. Country-only trips use the general Trip Reality rules unless a country-level profile exists. Singapore is intentionally defined as one country-level city-state profile. Fuzzy matches are suggestions that require confirmation. A score of 1 means comparatively low planning friction and 5 means comparatively high friction. These profiles are planning aids, not official travel ratings, safety rankings, or statements about destination quality.
True flight cost
The calculator sums only the amounts entered. Optional time valuation is displayed separately from money actually paid. Exchange rates and live fares are not fetched.
eSIM support
Device matching uses manufacturer support pages and conservative model-family patterns. Carrier locks, country variants, carrier support, and provider coverage can change the outcome, so the result is a readiness checklist rather than a guarantee.
Booking consistency methodology
The checker runs in the browser. Pasted text is used only to propose editable fields; the user reviews those fields before running comparisons. Checks cover passenger counts and possible spelling differences, flight and hotel dates, airport and metropolitan-area changes, connection order and duration, baggage continuity, hotel-night totals, transfers, duplicate-looking reservations, booking-reference presence, and cancellation wording.
Where a common airport exists in the local dataset, the checker converts each local date and time with that airport's IANA timezone before comparing the sequence. This supports overnight and international date-line cases without pretending that local clock times share one timezone. Unknown airport codes remain a manual check. The airport dataset is deliberately limited and is not an official or exhaustive directory.
Hotel-night checks compare arrival, check-in, check-out, and return dates, then show expected and booked nights. A difference is described as a possible issue because overnight flights, intentional airport stays, and day-use rooms can explain it. Duplicate detection uses normalized route, date, property, and booking-type fields and asks the traveler to confirm rather than declaring a duplicate.
The score is an explainable planning summary, not identity verification, legal advice, or confirmation that a booking is valid. Raw pasted text and booking references are not stored by default. Privacy-safe exports exclude raw text, references, ticket and passport details, payment data, and passenger names unless the user explicitly opts to include names.
Destination alias methodology
Destination profiles have canonical names and a separate versioned alias file containing common city-country forms, codes, and restrained spelling variants. Matching checks the canonical name, then exact aliases, then normalized aliases after lowercasing, punctuation cleanup, whitespace normalization, and accent removal.
Cautious edit-distance matching is used only to offer a “Did you mean…?” suggestion. The traveler must confirm it and rerun the check; a fuzzy suggestion never silently assigns a friction profile. When no profile matches, the general Trip Reality rules continue and clearly state that no destination-specific adjustment was applied.
Trip Passport integration
Trip Passport uses the existing tripplanwise-trip-v1 schema in local browser storage. It can carry selected broad fields among the AI Trip Planner, Travel Budget Planner, Packing List Generator, Airport Layover Planner, Trip Reality Checker, flight-cost comparison, eSIM readiness, and Booking Confirmation Checker.
Each tool maps only relevant fields. These can include destination, dates, duration, traveler counts, pace, budget and currency, packing preferences, airport and layover context, and broad accessibility reminders. Import and export are explicit actions. If a saved value differs from a current form value, the panel presents both choices and does not overwrite the current entry silently.
Trip Passport excludes raw booking text, booking references, ticket and passport numbers, payment details, full passenger identity documents, and detailed health information. Clearing tool fields does not clear the saved Passport; clearing the saved Passport is a separate action.
Sources, review dates, and corrections
Source URLs and review dates are recorded in the public data files used by the tools. Official tourism, transport, government, airline, and device-manufacturer sources are preferred. A source can still become outdated between reviews.
See the Source Policy, Editorial Policy, and Correction Policy.