Zovda
Data freshness is treated as a virtue in itself, and it is not. A weekly refresh of a set whose facts change yearly adds churn, not accuracy, and every refresh is a chance to introduce a break.
The cadence should be derived, not chosen by preference.
Start from the half-life of the answer
Some answers change in a day: a price, an availability, a trending topic. Some change in a year: a taxonomy, a body of knowledge, a definition of a category.
Refresh at the rate the answer decays, not at the rate the pipeline can run.
Separate the layers
- The facts, which may change daily
- The examples, which change when behavior changes
- The schema and taxonomy, which should change rarely and deliberately
- The evaluation set, which should change least and never silently
Most teams refresh everything on one schedule and lose the ability to attribute any change to anything.
Make each refresh measurable
Before and after each refresh, evaluate on a frozen slice. A refresh that does not move the frozen slice is either neutral or undetected; a refresh that moves it needs a reason.
Budget for the break
Every refresh can change a field, a category, or a distribution. Reserve the first day after a refresh for checking, not for shipping.
Zovda maintains these collections through Datuva, so each refresh keeps its own record and the schema change is visible rather than inferred. The data research collection shows how dated series are maintained.
Tell us how fast your answers go stale. We reply within one business day.