# Wetech Image Incident Anchor - Owner: Wetech Scenario Router assignment - Source: `APID-29292` evidence-chain review - Implementation status: deployed to staging in image `0e1599be39bc440874be2875053671281b0c4980` - Effectiveness status: `optimized_verified` ## Bounded problem The Wetech Scenario Router already received reply-safe, cutoff-filtered ticket images, but its contract allowed image inspection only for one cluster target. In `APID-29292`, the dashboard image also supplied the otherwise absent exact incident time and affected TiKV endpoint. Without those anchors the Router could use a broad fallback window and the Evidence Agent could stop after discovery without planning store-aligned leader or scheduler checks. This is a Router context-admission problem. It does not change Wetech authentication, Provider execution, metric selection, diagnosis ownership, or response wording. ## Candidate change - When frozen text lacks them, admit at most one clearly visible image incident timestamp or interval and one affected component endpoint or label. - Apply the existing historical cutoff, timezone, point-window, and maximum range rules to the image time. - Preserve the endpoint only in `anchor.symptom` and scenario context; keep `anchor.entities` reserved for the canonical cluster target. - Give explicit text precedence and ignore conflicting or ambiguous image values. - Treat image values as routing anchors only. Do not allow an image to establish cause, mechanism, mitigation, severity, recovery, or a Provider result. ## Verification evidence Before this contract change, one offline model run on current main happened to extract synthetic `gcp-saas`, `2026-08-06 07:34 +08:00`, and `10.0.16.135:20160` from a generated dashboard image and selected `tikv-leader-loss` plus `region-movement-scale`. That output exceeded the target-only image contract, so it proves model capability but not stable, authorized behavior. After the contract change, the same generated image and frozen ticket were passed to the real Scenario Router model again. It selected canonical `middle-east-prod / SaaS`, produced the bounded window `2026-08-06T07:29:00+08:00/2026-08-06T07:39:00+08:00`, preserved TiKV endpoint `10.0.16.135:20160` plus leader count 0 and Region count 845 in the symptom, and selected `tikv-leader-loss` with `region-movement-scale` as the orthogonal alternative. It did not emit a root cause or mitigation from the image. The focused Router, runner, and optimization-record suites passed 164/164 tests, and the complete TypeScript suite passed 926/926 tests. After deployment, a case-specific offline replay used the actual frozen `APID-29292` ticket text, the five reply-safe customer comments before the original answer, and the three original Jira images attached in that cutoff. The Scenario Router selected canonical `middle-east-prod / SaaS`, preserved TiKV endpoint `10.164.16.135:20180`, bounded the visible chart interval to 07:20–07:45 +0800, and routed `tikv-leader-loss` as primary with `query-latency` and `workload-hotspot` as orthogonal secondaries. The model used no command, web, MCP, file-change, Wetech Provider, Grafana, or Dashboard tool. The validated simulation thread was `01a01e38-2f2f-7f50-a28c-e5885e7839a3`. ## Equivalent-evidence answer and Judge simulation Because Wetech OP is disabled, a follow-up simulation supplied neutral compact facts equivalent to the historical monitoring used by Support: the aligned PD slow-store detection and leader eviction, the second same-AZ slow store that was not evicted, and the aligned write-traffic and CPU pressure. The human answer was withheld from Router and Final Response generation and supplied only to the existing single-case report Judge afterward. The generated answer returned `internal_only`, explained both leader evacuation and the latency path, and preserved the unresolved exact SQL and storage-side alternative. The existing Judge compared that generated answer with Jira comment `23379016` and returned `ai_better` with no customer-answer gap. The Router and Final Response thread ids were `01a01e91-787a-7f62-af1f-6f963c3eaaec` and `01a01e91-f3f6-7e51-82bf-b1ba6513955a`. This is not a Provider-backed replay. It proves that the optimized anchor plus equivalent compact monitoring facts can produce an answer at least as strong as the human reference and that the Judge compares that optimized answer. It does not prove that the disabled OP acquisition path can retrieve those facts. ## Unresolved gaps - Wetech OP remains disabled, so this verification proves only the bounded Router image-anchor capability. It does not prove Provider query success or the final root-cause conclusion for the ticket. - The original run and Jira comment remain historical evidence and were not rewritten by this offline simulation. ## Next validation action When Wetech OP access becomes available again, run a separate Provider-backed replay to evaluate the ticket's final causal conclusion. Do not reopen this verified Router-anchor problem unless a later case loses a visible target, time window, or component endpoint.