Your hotel pricing model refits every Sunday, so what does a drift or conversion-sag trigger catch that the weekly clock misses?
answer
- clock fires blind, evidence fires late
- drift needs no outcomes; conversion does
- the clock is a ceiling, not a response
- a drifted feed is not a drifted market
- ceiling, accelerator, floor, triage branch
basics
~20 sA clock fires on time regardless of evidence, so anything that breaks on Monday waits until Sunday. A drift trigger fires when live inputs or predicted rates leave the training window; a conversion trigger fires when bookings per search sag.
solid answer
~50 sA weekly clock bounds staleness at roughly seven days and does nothing else: it fires whether or not anything changed, and it cannot move earlier when something does. An evidence trigger reads a signal instead. A **drift trigger** compares live inputs and the predicted-rate distribution with the training window and fires when they separate — it needs no outcomes, so it is fast, but it also fires on changes that never hurt revenue. A **live-metric trigger** watches booking conversion and fires when it sags — that is the thing you actually care about, but it only speaks after guests have been served bad rates, and slower outcomes such as cancellations arrive later still. Production policies run all three: the clock as a staleness ceiling, the evidence triggers as accelerators, and a minimum interval so they cannot fire continuously.
go deeper
Know the two shapes: a clock that fires on schedule whatever happens, and a trigger that fires because something was measured. Say which one a weekly refit is.
Explain what each trigger reads and when it can speak — drift needs no outcomes and is fast but imprecise; a conversion sag is precise but arrives only after guests were served the bad rates.
Design the combined policy: a staleness ceiling, evidence triggers as accelerators, a minimum interval, and a triage branch so a broken upstream feed does not fit itself into the next model version.
Argue how much staleness the business will carry against the cost and risk of unattended runs, and who owns the call when the trigger policy and the revenue team disagree.
## What a clock trigger really promises A cadence trigger — "refit every Sunday at 02:00" — makes exactly one promise: **the live model version is never older than one interval**, and even that holds only if every run succeeds and publishes. It promises nothing about correctness. The clock does not know that a competitor group repriced on Monday, that a season turned, or that the last run trained on a day of corrupted booking events. Its virtues are real and are why almost every system keeps one: it is predictable, it can be capacity-planned, its cost is a known line item, and it exercises the retraining path often enough that the path still works when you need it. A retraining pipeline that only ever runs on alarms is a pipeline that is broken the first time an alarm fires. ## What an evidence trigger adds An evidence trigger fires on a measurement rather than on the calendar. Two classes matter here, and they sit at different points on the speed-versus-certainty trade: - **Input and prediction drift.** The monitoring tier already publishes a distance between the live feature distribution and the training window's, and between today's predicted-rate distribution and the reference. It needs no outcomes at all, so it can fire within hours of a change. The price is precision: the inputs can move without the model being wrong, so this trigger fires on some changes that cost nothing. - **A live quality metric.** Bookings per search, or realised rate against the market, sags when the model is wrong in a way that matters. This is high-precision — it is the loss itself — but it is structurally late: guests had to be served the bad rates for the signal to exist, and outcomes further out, such as cancellations against a stay date months away, arrive later than any trigger can usefully wait for. ## The four classes side by side | trigger | reads | fires | blind spot | |---|---|---|---| | clock cadence | nothing | on schedule | every change between runs | | input / prediction drift | live inputs against the training window | hours after a shift | changes that do not hurt revenue; a broken feed looks like drift | | live-metric sag | booking conversion per search | after guests are served | the damage already happened; slow outcomes arrive too late | | business calendar | the event and season calendar | before the dates | only covers changes someone wrote down | ## How they combine into one policy In practice these are not alternatives; they are layers of one policy, and it is worth stating it as an explicit set of rules: 1. **A ceiling.** Refit at least every N days, no matter what — this is the clock, and it caps staleness. 2. **An accelerator.** Refit early when the drift alarm holds above its threshold for k consecutive windows, or when booking conversion sags beyond its band. 3. **A floor.** Never refit more often than once per minimum interval, so an alarm that chatters cannot fill the day with runs. 4. **A triage branch.** If the alarm's shape says "upstream feed", route to a human rather than to the training pipeline. That structure is why "scheduled or triggered?" is a false choice in a design round. The good answer is "scheduled as the bound, triggered as the response, with an interval between runs", and then the interesting part: which signal you trust to move the schedule. ## The trap: refitting on a broken feed A drift alarm cannot distinguish "the market moved" from "an upstream field froze at its last value" or "a unit changed from nightly rate to total stay". Both look like a distribution that walked away from the training window. Wiring the alarm straight into the training pipeline therefore has a failure mode with no lower bound: the refresh fits a new model version on the corrupted window, publishes it, and now the corruption is in the artifact as well as in the feed. The cheap defence is that the trigger's first stop is a data-quality check on the training window — null rates, frozen values, row counts, join fan-out — and that the alarm's payload says which features moved. A single feature moving alone is far more often a plumbing defect than a market change; the whole input vector moving together is far more often the market. ## Why the clock still bounds everything Even with both evidence triggers wired, the ceiling stays, because both can be silent while the model is wrong: drift can be small and directional, conversion can be masked by a seasonal lift, and a metric with slow outcomes has a blind window by construction. The clock is the only trigger that fires when every signal is quiet, which is exactly the case no measurement covers.
- If both evidence triggers are wired up, why keep the weekly clock at all?Because both evidence triggers can be silent while the model is wrong: drift can be small and directional, and a conversion sag can be masked by a seasonal lift. The clock is the one trigger that fires when every signal is quiet. It also keeps the retraining path exercised, so it still works the day an alarm does fire.
- The drift alarm fires and one feature moved alone. Should the refresh run?Usually not. A single feature walking away from the training window while the rest hold is far more often an upstream defect — a frozen value, a unit change, a join losing rows — than a market change. Route it to a data-quality check first; refitting on that window would bake the defect into the next model version.
- Why is a conversion-sag trigger a poor sole trigger for stay dates months out?Its signal depends on guests acting on the rates that were served. For far-out stay dates the booking curve is long and the confirming outcomes — cancellations, no-shows, realised revenue — land after the stay date has passed. The trigger would fire long after the affected room nights were mispriced and could no longer be resold.
saying these in an interview costs you the question
- Presents scheduled and triggered retraining as mutually exclusive choices
- Wires a drift alarm straight into the training pipeline with no data check
- Thinks a weekly clock bounds how wrong the model can be
- Claims a conversion trigger catches problems before guests see them
- Assumes a drift alarm firing means the market changed