https://github.com/FilOzone/dealbot/blob/main/docs/checks/data-retention.md#why-is-this-called-data-retention-vs-data-availability
Right now, the top-level metric around "retention" implies data loss / deletion in the context data is not "retained" -- however the metric is actually measuring proving reliability, where gaps could indicate node uptime or proving ability instead of data retention. Instead of using the word "retention", we should use a word that more clearly maps to "proving" since that is the onchain process that is being measured and sets a clearer auditor expectation on network and SP health.
https://github.com/FilOzone/dealbot/blob/main/docs/checks/data-retention.md#why-is-this-called-data-retention-vs-data-availability
Right now, the top-level metric around "retention" implies data loss / deletion in the context data is not "retained" -- however the metric is actually measuring proving reliability, where gaps could indicate node uptime or proving ability instead of data retention. Instead of using the word "retention", we should use a word that more clearly maps to "proving" since that is the onchain process that is being measured and sets a clearer auditor expectation on network and SP health.