# Current Request Target Classification - Optimization ID: `current-request-target-classification-2026-08-27` - Owner: Scenario Classifier semantic prompt - Source reference: `TCID-13070` - Implementation status: merged in PRs #1121, #1122, and #1125; deployed in live image `18be8f819e1e011fe68ac7297d66a15512bdf595` - Effective status: `optimized_verified` ## Bounded problem TCID-13070 explicitly asks Support to validate proposed Dumpling configuration and workload-shaping choices. EBS IOPS saturation, service impact, and a future TiKV scale-in plan explain why that advice matters, but they are not independent requests for incident diagnosis or cluster operation. The current classifier can classify those contextual facts as the entry problem and select `cluster_runtime_issue / evidence_assisted / clinic`. The same ambiguity is generic: operationally severe context can dominate an explicit Q&A target in any scenario. A product-specific keyword or Dumpling exception would not fix the owning semantic boundary. ## Candidate change - Identify the answer, decision, explanation, validation, diagnosis, or action that Support is expected to provide now. - Treat the summary or title as one clue; prefer an explicit request in the description or visible comments when they differ. - Keep impact, metrics, suspected causes, motivation, constraints, future plans, and consequences as supporting context unless the customer explicitly asks Support to act on them. - Check whether answering only the contextual symptom would leave the explicit customer question unanswered. - For reviews of proposed methods, settings, commands, or configuration, treat the proposal as the target. Do not infer an incident-diagnosis request from motivating symptoms, production impact, lookup identifiers, or timestamps. - Select a Provider only when the stated target depends on undiscovered current or historical facts; available lookup keys alone do not make it necessary. - Keep subject and handling separate: select the specific product or workflow domain as `scenarioClass`, and use `resolutionMode` for direct versus Provider-assisted handling. Route a method review by the reviewed workflow, not a downstream resource symptom supplied as motivation. - Preserve Provider-backed runtime classification when diagnosing or resolving the symptom is itself the explicit request. - Use medium reasoning for Scenario Classifier only. High produced the same target result and is not selected; other Auto-oncall Agents keep their existing reasoning settings. ## Verification status The low-effort pre-change classifier selected `cluster_runtime_issue / evidence_assisted / clinic` in three of four frozen TCID-13070 trials. Medium and high each selected that route once in four trials and also drifted once to `feature_usage_or_capability`; increased reasoning did not make the owning distinction stable. With the first generic current-request/context rule applied to the frozen input, the low-effort live model selected `direct_answer / none` in four of four TCID-13070 trials. A paired input that explicitly requested diagnosis of the same IOPS symptom remained `cluster_runtime_issue / evidence_assisted / clinic` in four of four trials. The target still drifted once to the generic `feature_usage_or_capability` class, so the candidate now also makes the scenario-domain versus handling-mode ownership explicit. With the final candidate prompt and the same live `gpt-5.6-sol` low-effort classifier configuration, four of four frozen TCID-13070 trials selected `backup_restore_or_dr / direct_answer / none`. Four of four paired control trials that explicitly requested diagnosis of the TiKV/EBS IOPS incident selected `cluster_runtime_issue / evidence_assisted / clinic`. This is branch-local model evidence that the generic target/context rule corrects the observed route without suppressing an explicit runtime diagnosis. It is not effective-runtime verification until the change is merged and deployed. The final TypeScript build, classifier contract tests, optimization-record validation, and full repository suite passed with 994 tests. The deployed low-effort read replay then passed as run `92bda67d-8043-4e10-8167-0bbb1adfb690`, but the immediately following write replay classified the same frozen request as `cluster_runtime_issue / evidence_assisted / clinic` before publication. This is a reproduced live failure of the low-effort candidate, so the prompt-only deployment is not verification. With the deployed prompt, four additional medium and four high classifier trials all selected `backup_restore_or_dr / direct_answer / none`. Medium also kept four of four paired explicit-runtime-diagnosis controls on `cluster_runtime_issue / evidence_assisted / clinic`. Medium is selected because high did not improve these outcomes. The medium-effort follow-up build, focused classifier and optimization-record tests, and full repository suite passed with 998 tests. After the medium-effort classifier was deployed, read replay `88b7f39d-32a5-4cbd-9362-9980d50c1413` still selected `cluster_runtime_issue / evidence_assisted / clinic`. Its classifier signals correctly recognized the explicit request to validate Dumpling I/O-reduction measures, but nevertheless promoted the supplied IOPS incidents and available Cloud lookup keys into a Provider-backed route. This shows that identifying the request and context is insufficient unless the prompt also binds Provider necessity and scenario domain to that stated target. With those target-bound rules added, four of four medium-effort trials on the same frozen TCID-13070 request selected `backup_restore_or_dr / direct_answer / none`. Four of four paired controls that explicitly requested investigation of the actual TiKV/EBS IOPS incident remained `cluster_runtime_issue / evidence_assisted / clinic`. This is branch-local candidate evidence only; the revised prompt still requires merge, deployment, and read/write replay verification. The TypeScript build, focused classifier and optimization-record tests, and full repository suite passed with 999 tests. PR #1125 merged as `8528b8ecf787c0cdfbc0f953f0b2a2d0decb53d4`. The staging release and app-delivery PRs #78610 and #78611 deployed live image `18be8f819e1e011fe68ac7297d66a15512bdf595`, which contains that merge. The replacement Agent9 Pod became Ready at `2026-08-27T11:42:23Z` with zero restarts; `/healthz` and `/readyz` returned HTTP 200. Runtime import readback confirmed medium classifier reasoning and all target-bound prompt rules. Post-deployment read replay `87a0d3b7-4987-43b2-a426-74c1faf05d44` selected `backup_restore_or_dr / direct_answer / none`, completed response generation without Provider files or calls, and received Judge verdict `ai_better`. Read publication remained entirely `not_requested`. Write replay `91126dda-0ecd-4d32-b540-3a1e3b8b4dd2` independently selected the same direct route with no Provider files or calls. It persisted DB run `150143`, wrote the evaluation, updated the Feishu dashboard, and updated Jira without publication errors. Jira API readback found the existing stable comment `23673939` with `public=false`; its body contains the new direct Dumpling advice and no longer contains the prior Clinic/runtime diagnosis. No public comment was created or overwritten. ## Unresolved gaps None for this bounded classification problem. ## Next validation action Monitor later Q&A tickets for regression of the same supporting-context signal.