# Wetech Statements Sampling Policy

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "wetech-statements-sampling-policy-2026-08-18",
  "problems": [
    {
      "problemId": "wetech-low-sampled-statements-used-for-workload-attribution",
      "summary": "Automatic Wetech diagnosis can use low-sampled cluster-group Statements rows for workload discovery or attribution even though their ranks, counts, baselines, and empty results are not representative.",
      "status": "optimized_unverified",
      "applicability": "Automatic Wetech Evidence Agent planning for workload discovery, ranking, aggregate attribution, baseline comparison, or absence checks.",
      "issueKeys": [],
      "sourceRefs": [],
      "signalTextIncludesAny": ["wetech statements sampling", "low sampled statements", "statements rank is not representative"],
      "observedThrough": "2026-08-18",
      "effectiveAt": "2026-08-18T06:23:01Z",
      "verifiedAt": null,
      "attemptedAction": "Classify Wetech Statements as optional supplemental evidence: it may corroborate a candidate established by exact-instance TopSQL or Slow Query, while sampled rows cannot prove rank or absence and empty or failed results do not trigger repair, partial acquisition, or handoff.",
      "evidenceUrl": "https://github.com/tidbcloud/app-delivery/pull/77512"
    }
  ]
}
-->

- Owner: Auto-oncall Evidence Agent and Provider Executor
- Source: user-confirmed Wetech cluster-group sampling boundary on 2026-08-18
- Implementation status: deployed to staging
- Effectiveness status: optimized_unverified

## Bounded problem

Wetech Statements is sampled at the cluster-group layer. A returned row may be
a useful lead for a person, but its rank, count, and aggregate values do not
represent the full workload. An empty result is also not evidence that a
statement or workload was absent. Treating this surface as load-bearing can
therefore create both false attribution and false negative conclusions.

## Candidate change

- Keep one narrowly bounded `statements` operation available only as
  supplemental context after exact-instance TopSQL or Slow Query establishes
  the workload candidate.
- Have the Provider Executor mark Statements query coverage as `supplemental`.
  Preserve its compact artifact and query event, but exclude an empty or failed
  result from query repair, scenario completion, evidence-acquisition
  degradation, and human handoff.
- Use affected-instance TopSQL for workload distribution and Slow Query for
  exact executions, plans, and transaction linkage. Statements rows may only
  corroborate that already-established candidate.

## Verification evidence

The initial hard-prohibition candidate was superseded before rollout. On
2026-08-18, the revised supplemental policy passed the full TypeScript build and
882/882 tests plus all 79 Wetech helper contract tests. Focused tests prove that
the helper marks Statements as supplemental, a failed Statements query does not
make the batch or handoff partial, and the failed coverage plus compact artifact
remain visible without entering query repair. The Agent9 Wetech Tool schema
now exposes `statements`; Agent9 materialization classifies that operation as
supplemental and applies the same non-blocking completion and error semantics.
Source PR [#971](https://github.com/tidbcloud/aisupport/pull/971) and
app-delivery PR [#77512](https://github.com/tidbcloud/app-delivery/pull/77512)
were merged, and staging converged to image
`f2c832c6a482e649c8d3496a94a7769b73794cf0` with one Ready replica, zero pod
restarts, and HTTP 200 from both health endpoints. A case-specific Wetech replay
is still pending, so deployment availability does not yet verify the sampled
Statements behavior on a real Wetech case.

## Unresolved gaps

TopSQL remains top-N bounded and Slow Query remains retention bounded. Those
limitations must be stated precisely; this change does not turn either surface
into complete workload census data.

## Next validation action

Replay at least one Wetech workload case that previously considered Statements.
Verify TopSQL/Slow Query supplies the
load-bearing workload evidence; if Statements is attempted, confirm sampled
rows remain corroborative only and an empty or failed result remains visible
without degrading acquisition or triggering human handoff.