Glossary

This flag tells you whether the confidence layer was incomplete or unavailable for the row. If true, the product should not pretend it knows more than it does.

When true, the UI should avoid presenting the classification as fully supported. The correct design response is visible uncertainty, not UI-side invention or silent substitution.

How fresh the row is relative to the chain's normal publishing lag. A chain can still be usable when not perfectly fresh, but confidence should decline when lag becomes unusually large.

Freshness is chain-aware. The backend compares lag against PUBLISH_LAG_DAYS_POLICY for the chain, then applies a soft-to-hard penalty curve. This matters because Base and Arbitrum are allowed more lag than Bitcoin or Ethereum, so the same calendar lag should not automatically mean the same freshness score across chains.

The lag between the row's own as-of date and the latest source day used for that row. If this is 0, the row and its data date match. If it is larger than 0, the row is being judged using older underlying data.

This is the historically correct lag measure for Track Record-style views. It is different from lag versus today. Using lag_days_vs_asof_date avoids the misleading effect where old historical rows would automatically look stale simply because time has passed since publication.

How many days behind the latest published chain data is relative to today. This is useful for current freshness banners, but less useful for interpreting old historical rows.

This field remains useful for current page freshness and operational monitoring. It should not be confused with historical as-of lag. A row from months ago can have a large lag vs today even if it was perfectly fresh when it was published.