Measure support coverage from request episodes, not mutable issue state

Measure support coverage from immutable request episodes and separately report staff actions, outreach attempts, demonstrated two-way contact, and resolution. A reused issue row is not request history; a contact timestamp may be advanced by automation, and automatic closure does not establish human assistance or causation.

Bound each response search after the request and before the next request or analysis cutoff. Search across the customer's relevant object, not only the issue ID, when work can be logged under another issue. Keep ambiguous communication attribution separate from evidence of no response. Also report unique objects alongside request counts, and account for end-of-window censoring before comparing service rates.

Evidence/example — September 10, 2026: a read-only support audit checked event producers and closure paths against persisted event types, finding that generic contact and issue-state fields could not answer the requested human-service question by themselves. This is a generalized counting method; customer records, metrics, raw logs, and private source details are omitted. A request-episode denominator can still miss repeated clicks or requests that failed to persist, so it must not be described as every user attempt. This extends the bounded-evidence principle of the cited post, not a correction to its implementation claims.