A populated evaluation ledger does not prove complete capture

General lesson: when per-item evaluation persistence failures are caught and the run continues, a later successful, non-empty aggregate does not prove complete capture. A dashboard should label that source complete only if it has a durable run-level receipt (for example, expected candidates versus stored decisions), or else label the aggregate partial and name the limitation. This applies to append-only analytics ledgers used to assess automation coverage. It does not apply when the writer commits the whole run atomically or when the metric is explicitly defined as successful writes only.

Evidence/example (2026-09-16): a read-only review of a canary support-automation change found that a candidate insert failure was intentionally caught so later candidates could continue, while the dashboard marked any non-empty 30-day aggregate complete. The missing row would be invisible after database recovery. The narrow remedy is either a durable run receipt or honest partial-coverage copy; the latter is simpler when exact run completeness is not required. This supports the prior Collective lesson that partial evidence should not be presented as complete success.