ModelRefs / Data Freshness

Data Freshness

How ModelRefs records review dates, monitors time-sensitive evidence, and communicates stale or incomplete coverage.

Overview

Reference data goes out of date at different speeds, so ModelRefs does not apply one review interval to everything. Each class of content carries its own window, and anything past that window says so.

The governing rule is that a review date is recorded, never inferred. A page with no human review on file is labelled as needing one.

Four review windows

Content is assigned a volatility class, and the class sets how long a recorded review remains valid. A pricing page and a historical benchmark result do not deserve the same interval.

  • High volatility — 7 days

    Facts that move weekly: current pricing, availability, rate limits, newly released models.

  • Medium volatility — 30 days

    Workflow guidance and implementation patterns, which shift as tooling changes.

  • Low volatility — 90 days

    Reference material whose substance is stable: architectures, definitions, established patterns.

  • Historical reference — 180 days

    Results and events that are fixed in time and only need periodic confirmation that the record is still correct.

What the status labels mean

Status is computed from the recorded review date and the window for that class. It is shown rather than hidden, including when it is unflattering.

  • fresh — reviewed inside its window
  • aging — approaching the end of the window
  • stale — past the window, still accurate as far as is known
  • expired — past the window and queued for re-verification
  • needs_review — no human review date on file at all
  • deprecated, archived — superseded or retired, kept readable

No date is ever synthesised

The one rule that makes the rest meaningful: if nobody reviewed a page, no date is written for it. An entry is cleared only by appending a reviewer and an ISO date to the governance record, which is version-controlled and reviewable like any other change.

The alternative — defaulting an unreviewed page to the date it was generated — would make every page look fresh and the whole system worthless. An expired label is information; an invented date is not.

A re-verification queue, published rather than buried

Every governance run recomputes the queue, ordered by priority and age, and writes it to the governance reports along with the average age of the corpus and the count by status. The queue is a public artefact of the build, not an internal dashboard, so the gap between what has been reviewed and what has not is visible to a reader who wants to check.

Benchmark results age differently from pages

A benchmark score carries the date its run was reported, which is a property of the result rather than of the page showing it. A 2024 result on a 2024 model is not stale — it is the correct figure for that pairing, and re-running it today would measure something else. Page freshness asks whether the surrounding guidance still holds; run dates say when each number was produced. Both are shown.

Continue your research

Use these connected ModelRefs sections to compare alternatives, inspect implementation paths, and review the evidence and governance boundaries relevant to Data Freshness.