skip to content

Which refresh trigger covers a convention week that invalidates the hotel pricing model before any alarm fires?

level: seniorimportance: nice to knowfreq 30%

answer

  1. three triggers react, one anticipates
  2. the evidence is the damage
  3. the signal lives in the business calendar
  4. fire on lead time, not on the date
  5. no comparable history means override

basics

~20 s

A business-calendar trigger — wired to the events, seasons and portfolio-change calendar — fires ahead of the dates. Drift and conversion triggers read evidence from traffic that has not happened yet, so they can only react after the affected room nights are already mispriced.

solid answer

~40 s

This is a fourth trigger class, distinct from the clock and from the two evidence triggers. A **business-calendar trigger** fires on a known future change: a citywide convention, a season turnover, a new property class entering the portfolio, a competitor opening. Drift and conversion triggers cannot help, because the evidence they read is produced by the very demand the event creates — by the time the input distribution or bookings per search move, the high-demand nights have been sold at the old pattern's rates and cannot be resold. The trigger's response is usually a refresh scoped to the affected stay dates, with the training window reweighted toward comparable past event periods. Where no comparable period exists, the honest response is a human override rather than a refit.

go deeper

for a junior

Know that some changes are known before they happen, so a refresh can be scheduled against a business calendar instead of waiting for a measurement to move.

for a middle

Explain why drift and conversion triggers are structurally late for a known event: the evidence they read is produced by the demand that has already been mispriced.

for a senior

Scope the response — affected dates and properties, a training window reweighted toward comparable past periods, and an override when no comparable period exists.

for a principal

Decide who owns the calendar feed and the override path, and how the organisation handles dates where no data exists and someone simply has to make a call.

## Why evidence triggers are structurally late here Both measurement-based triggers are downstream of traffic: - an **input-drift alarm** fires once the live feature distribution has moved, which requires the convention's searches and bookings to have already arrived; - a **conversion trigger** fires once bookings per search have sagged, which requires guests to have been served the wrong rates and reacted. For an event with a long booking curve, both arrive after the damage. A room night sold three months early at a normal-week rate is gone; there is no inventory left to reprice once the alarm speaks. This is the asymmetry that justifies a fourth class: the other three triggers are **reactive**, and this one is **anticipatory**. The clock cannot substitute either. A weekly refit fires on time regardless, and the model it produces is still fit on a history in which this particular event has not happened. ## What a calendar trigger is wired to The signal is not in the ML system at all — it comes from the business: - a **city and venue event calendar** — conventions, festivals, sporting fixtures, public holidays; - **season boundaries** for each market, which move year to year and are not a fixed date; - **portfolio changes** — a property opening, a wing reopening after refurbishment, a new property class; - **competitive changes** someone knows about in advance, such as a competitor property opening nearby; - **rate-plan or policy changes** that alter what a booking means. Making this a trigger means treating that calendar as a **pipeline dependency with an owner**, not as tribal knowledge. Two consequences follow: a missing calendar entry is a silent miss, so the feed needs its own freshness check; and the trigger fires on a **lead time before the dates**, not on the dates — it must fire early enough for the refreshed model version to price the booking window that matters. ## What the refresh actually does Firing is the easy half. The response has to be scoped, because a citywide convention affects a handful of properties and a band of stay dates, not the portfolio: 1. **Scope to the affected stay dates and properties**, so the rest of the portfolio is not disturbed by a refit aimed at one week. 2. **Reweight the training window toward comparable past periods** — previous editions of the same event, or structurally similar high-demand weeks — because the ordinary recency-weighted window is dominated by normal weeks and will regress the event back to the mean. 3. **Register the result as its own model version** with the trigger recorded, so the rates for that week are explainable afterwards. ## When a refit is the wrong response | situation | right response | |---|---| | several past editions of the event exist in the history | a scoped refit reweighted toward them | | a recurring season turnover with years of history | a scoped refit, or a calendar feature the model already reads | | a first-ever event with no comparable period | a human pricing override for those dates | | a property class new to the portfolio | an override or a fallback policy until booking history accrues | The bottom two rows are the important admission: **you cannot fit a pattern that has no examples**. A refresh trigger that responds to every calendar entry with a refit will, on a first-ever event, produce a confidently wrong model version and hide the fact that nobody knows what the right rate is. Routing to an override keeps the uncertainty visible and puts it in front of someone who can price it. ## Operating it A few practical properties separate a calendar trigger that works from one that decorates a design document: - it fires on **lead time**, tuned to the booking curve of the affected dates; - the calendar feed is monitored for freshness, because silence is indistinguishable from "no events"; - each firing records which calendar entry caused it, so a later question about that week's rates has an answer; - it sits **alongside** the clock ceiling and the evidence triggers, which stay on — it is an extra reason to refresh, never a replacement for them. The interview point is compact: three of the four trigger classes wait for the world to prove the model wrong. The fourth uses the fact that some changes are known in advance, and it is the only one that can act before the inventory is gone.

  • Why not encode the event as a feature and skip the trigger entirely?
    Often you should, and a mature system does both — an event-flag feature lets the live model react without a refresh. But a feature only helps if the model was fit on enough past events to have learned what the flag implies, and the feature itself must be populated in advance for future stay dates. The trigger covers the cases the feature cannot: a first-ever event, a new market, or a flag whose meaning has changed.
  • How early should the calendar trigger fire before the affected stay dates?
    Early enough to cover the booking window that actually matters. If most room nights for that week are booked sixty to ninety days out, a trigger firing two weeks ahead has already missed the bulk of the inventory. Derive the lead time from the booking curve for those dates rather than using one portfolio-wide default.

saying these in an interview costs you the question

  • Expects the drift alarm to catch a known upcoming event in advance
  • Refits the whole portfolio for an event affecting one market week
  • Fires on the event dates rather than ahead of the booking window
  • Refits confidently on an event with no comparable past period
  • Treats the business calendar as tribal knowledge, not a monitored feed