Docs / TeoScore / Schedule & Time Efficiency
Schedule & Time Efficiency (V4–V6)
Category 2 — how long the trip takes, how well it fits the time you asked for, and how hard it is on your body.
How the category aggregates
When you set a departure/arrival preference (so V5 is active), your schedule fit drives the category: V5×0.50 + V4×0.30 + V6×0.20, renormalized over the active variables — a big arrival miss meaningfully lowers the score instead of being diluted to a third. With no preference set, V5 is inactive and the category is the equal-weight mean of V4 (and V6 when it applies).
Measures — total journey length vs the fastest option in the search.
V4 = V4b (airport-to-airport, incl. layovers) × 0.60 + V4c (pure air time) × 0.40 per dimension: Min = shortest in search, Max = Min × 2.5 ≤Min → 100 · ≥Max → 0 · else 100 × (Max − t) ÷ (Max − Min)
Data & accuracy — benchmark-relative, anchored on the shortest elapsed/air time in the result set. V4a (true door-to-door, incl. ground transit) needs saved traveler addresses the engine doesn't have, so it is always dropped and the weights collapse to the 60/40 state.
Gotchas — doesn't activate without a real search-relative benchmark (matches the spec's "no itineraries → V4 doesn't activate" case) — excluded from the category rather than defaulting to a fixed curve. The 60/40 split means a long layover (which inflates V4b) is penalized more than slow air time alone.
Measures — how close the flight's departure/arrival is to the time you asked for.
Score = max(0, 100 − 7 × (deviationMinutes ÷ 30)) (15 min ≈ 96.5)
Data & accuracy — deviation is measured in local time (via utcOffsetOriginHours/utcOffsetDestHours) and is circular around the 24h clock. A departure and an arrival preference are each scored and averaged. Window mode gives a full 100 inside ±half-window and only penalizes the excess; exact mode penalizes from minute one.
Gotchas — drops when no preference is set (and no pre-computed scheduleDeviationScore). This is a soft preference, not a filter — off-target flights still appear, they just score lower here. Round-trip outbound/return averaging happens in the orchestration layer, not the engine.
Measures — a red-eye penalty. Partial-launch scope: the timezone/jet-lag penalty is dropped for now.
Score = max(0, 100 − redEye) (red-eye = −20 unless waived)
Data & accuracy — red-eye is detected in-engine from leg times + UTC offsets (computeIsRedEye), falling back to an enrichment isRedEye flag. The penalty is waived if you intended a red-eye (explicit flag or an overlapping V5 window).
Gotchas — the jet-lag penalty (zones crossed × a direction multiplier: eastward ×1.5, westward ×1.0) is fully built, tested, and DST-aware, but gated off (V6_JET_LAG_DISABLED) pending a deliberate launch decision — it's not a data-availability gap anymore, the data exists. Re-enabling is a one-line flag flip, not new engineering.