# Classification Gap Ownership

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "classification-gap-ownership-2026-08-13",
  "problems": [
    {
      "problemId": "internally-discoverable-wetech-inputs-classified-as-customer-missing",
      "summary": "APID-29339 mixed a Support-owned Wetech target lookup with the customer-owned choice of which SQL execution plan needed analysis.",
      "status": "optimized_verified",
      "applicability": "Clinic, Wetech, or Manus read-only diagnostics where target and incident-window routing is internally available, while target-specific SQL or execution-plan questions still require the customer to identify the requested SQL when no SQL, Digest, or concrete plan is supplied.",
      "issueKeys": ["APID-29339"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/APID-29339#problem:internally-discoverable-inputs-classified-as-customer-missing"
      ],
      "signalTextIncludesAny": [
        "resolution:clarification_needed",
        "cluster_alias",
        "sql_or_digest",
        "diagnostic_wetech_target_missing"
      ],
      "observedThrough": "2026-08-13",
      "effectiveAt": "2026-08-13T05:24:05Z",
      "verifiedAt": "2026-08-13T05:33:15Z",
      "attemptedAction": "Use provider capability and question intent consistently at classification and final reconciliation: remove internally discoverable target and exact-window inputs, remove SQL only for symptom-led workload discovery, and retain target-specific SQL and Manus target choices as customer-owned clarification.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/APID-29339"
    }
  ]
}
-->

- Optimization ID: `classification-gap-ownership-2026-08-13`
- Owner: Scenario Classifier and Auto Coverage provider normalization
- Source reference: `APID-29339`, job `150084`
- Implementation status: deployed to staging in image `66d6d5786b463ca3c6368cdb9083662626e5b0bd`
- Effective status: `optimized_verified`

## Bounded problem

The initial classification grouped an absent Wetech cluster alias and the
absent target SQL together as customer missing context. The selected provider
can start from the account route, and the Scenario Router can resolve the
cluster from the internal candidate inventory. However, APID-29339 asks about a
particular execution plan without supplying the SQL, Digest, or plan that
identifies it. Internal workload discovery must not guess which SQL the
customer wants reviewed.

## Implemented change

- Require the classifier to apply the same customer-owned versus Support-owned
  boundary used by final reconciliation.
- Normalize SQL or Digest out of clarification only for symptom-led incidents
  where Clinic, Wetech, or Manus can discover workload candidates. Preserve it
  for target-specific execution-plan or tuning questions with no supplied SQL,
  Digest, or concrete plan.
- Normalize exact-window keys out of Provider-backed clarification.
- Normalize Wetech target and Cloud identifiers out of clarification because
  the Wetech Account Alias starts internal target resolution.
- Preserve the explicit Manus target as a genuine customer scope choice.

## Verification status

- Source PRs: `tidbcloud/aisupport#864` and refinement `#866`; full test suite
  passed with 791 tests and no failures.
- Deployment: `tidbcloud/app-delivery#77146` merged as `23567f560bffa25881e59dda317bb35c26c1612a`.
  The staging Deployment reached generation 402 with one updated, ready, and
  available replica on image `66d6d5786b463ca3c6368cdb9083662626e5b0bd`.
- Frozen-input replay: run `ea38e494-1a5d-4e04-84c9-d4314c68f984`
  included only original customer comment `23547774` through the Job 150084
  cutoff. It classified the case as `clarification_needed` with
  `evidenceProvider=wetech` and `missingKeys=[sql_or_digest]`; neither
  `cluster_alias` nor `time_window` returned.
- Final ownership: the customer draft asks only for the target SQL, EXPLAIN,
  and the concrete plan question. The Wetech readiness and target mapping
  failures remain Support-owned in the internal handoff.
- Jira refresh: existing internal comment `23547826` was updated in place from
  the verified replay result. Readback returned `public=false`, exact expected
  ADF, an SQL request, and no request for customer cluster context. No new Jira
  comment or customer-visible reply was created. Existing DB run, evaluation,
  and Base history were not rewritten.

## Next validation action

Monitor new target-specific execution-plan and symptom-led slow-query tickets
to confirm the intent boundary remains stable beyond APID-29339. Treat any
future Wetech target or readiness failure as a separate provider reliability
problem rather than reopening this classification problem.