# APID Evidence Applicability Gate - Optimization ID: `apid-evidence-applicability-gate-2026-07-31` - Owner: auto-oncall-services - Source references: `APID-29231`, `APID-29259` - Implementation status: deployed to staging in revision `3efeb556` - Effective status: mixed; APID-29231 is `optimized_verified`, while the APID-29259 attempted action is `ineffective` ## Bounded problem The Focus-selected APID signal is narrower than provider availability. It asks whether the reply promotes cumulative `ANALYZE`, unified-read, or another same-window proxy into a root cause without aligned point and instance evidence. ## Deployed verification - Same-cutoff staging replay: `1f2aae2e-48e7-49e1-b54f-7b76371cd25c`. - Historical cutoff: support comment `23279359` was not used; the APID replay target remained the original support reply at `2026-07-24T03:34:38+08:00`. - Response generation completed. The Wetech query-execution scenario reached its 360-second bounded timeout, so provider capability was not verified. - The generated diagnosis nevertheless did not confirm `ANALYZE` or unified-read as a cause. It required exact incident time, affected TiKV instances, and aligned TiDB duration, QPS, query, TiKV CPU/task, and host evidence before choosing among query load, background work, and resource contention. - A judge using the original Focus #531 criteria marked `evidence-applicability-gate`, `case-discriminator-routing`, and `bounded-alternatives` as met. `control-behavior-preserved` was correctly not applicable to this target. The provider timeout remains visible but is not load-bearing for this problem: the Focus criteria do not require provider evidence, and the reply preserved the causal boundary instead of treating missing evidence as a negative result. ## APID-29259 deployed result - Same-cutoff staging replay: `85b4f6e6-2bef-48f5-8b75-d8a8c165249d`. - Historical cutoff remained the original support reply at `2026-07-28T03:37:25+08:00`; the target reply body and later comments were excluded. - Wetech route and authentication succeeded. The diagnostic scenario then reached its 360.008-second bounded timeout with `the_operation_was_aborted`; response generation still completed. - The reply correctly stated that the commit identifier alone cannot identify the SQL, did not make a concrete SQL attribution, and requested time-aligned SQL, TiKV instance, and event-window evidence. - The independent judge marked `evidence-applicability-gate` and `bounded-alternatives` as met, but `case-discriminator-routing` as a gap. The reply did not explicitly reject adjacent `prev_stmt` and aggregate COMMIT summaries as transaction-identity evidence, which is the exact case-specific discriminator required by Focus #531. The shared gate therefore improved the general attribution boundary but did not solve this exact problem signal. The attempted action is recorded as `ineffective` so a later attempt must add and verify the missing explicit identity discriminator instead of repeating the same generic guard. ## Unresolved gaps - The existing Jira internal comment was not refreshed. - This record does not verify Wetech provider readiness, query completion, or the separate provider-execution-state problem. - APID-29259 still needs an explicit statement that adjacent `prev_stmt` and aggregate COMMIT summaries do not preserve transaction identity. - ST-2846 remains an inconclusive Focus control because diagnostic preflight stops before an observable CPU-versus-panel distinction. ## Next validation action Add the missing APID-29259 identity discriminator, replay the same historical cutoff, and require `case-discriminator-routing` to pass before refreshing the Jira internal comment. Keep provider execution and APID-29231's verified problem status separate rather than promoting either whole ticket.