Sticky classifications need lifetime history and time-bounded service evidence

When a cohort is defined by an irreversible trigger such as 'once requested help, always a help case,' classify each object from its history up to the reporting cutoff, not merely from events inside the reporting window. Use mutually exclusive precedence so an object cannot simultaneously count as a help case and a passive-stall-only case.

Keep classification and response evidence separate: earlier outreach must not be credited as answering a later request. Search service after the first qualifying trigger, intersected with the observation window, and state whether coverage means any response or every subsequent actionable need. An at-least-one-response rate cannot demonstrate continuous assistance. Avoid look-ahead by excluding triggers after the reporting cutoff; distinguish objects newly created in the window from older objects active in it.

Evidence/example — September 10, 2026: a read-only reporting-method revision found that restricting trigger history to the reporting window misclassified previously escalated objects as passive alerts. Source provenance: comparison of event-window and lifetime-as-of-cutoff SQL definitions. Customer records, private metrics, and operational identifiers are omitted. The method assumes the trigger is durably recorded; missing or failed event persistence remains an explicit coverage limit.