# Adaptive Multi-batch Diagnosis - Optimization ID: `adaptive-multibatch-diagnosis-2026-08-06` - Owner: auto-oncall-services - Source reference: Clinic and Investibook manual comparison follow-up - Implementation status: deployed to staging and verified with two post-change replays - Effective status: `optimized_verified` ## Bounded problem The deterministic batch reduced model and provider overhead, but runtime and skill contracts accidentally promoted that implementation detail into a one-batch diagnostic ceiling. A failed or empty query was recorded as a gap, yet neither the evidence agent nor the parent could alter the next query. A successful first batch also could not expose a new load-bearing question for a second bounded batch. ## Intended mechanism - Keep each batch deterministic, read-only, compact, and independently audited. - Return structured complete, empty, failed, and partial results to the same scenario parent before it decides whether evidence is sufficient. - Permit at most three batch rounds per scenario, with at most six selected queries per round and the existing outer scenario deadline unchanged. - Let the evidence agent correct a failed query only by changing an observable condition such as provider surface, supported syntax, entity, filter, granularity, or bounded time slice. Identical blind retries are prohibited. - Let the parent request a later batch when a new result exposes one load-bearing diagnostic question. Stop when the question is answered, the provider establishes an exact limitation, no further query can change the diagnosis, or the common budget is exhausted. - Preserve provider, target, organization, canonical incident window, safety, serialization, and no-fallback boundaries across every round. ## Verification status - 2026-08-06 local typecheck passed. - 2026-08-06 full test suite passed after the schema compatibility fix: 674 tests, 0 failures. - Focused runner coverage proves both a corrected second batch after a structured provider error and a distinct parent-requested second batch after successful first-round evidence. Round-specific Clinic and OP materializers preserve earlier artifacts. - Staging replay `f395d17a-1006-44c9-8293-5f617e6e07de` proved that both scenario parents requested a second batch after inspecting structured first results. Round-2 plans changed provider surfaces, label discovery, grouping, and projected evidence instead of repeating the first queries. It also exposed that the original fixed seven query IDs rejected new bounded objectives such as `container-memory`, `memory-limit`, and `operator-record`. The mechanism now permits safe semantic IDs (maximum 64 characters) with a cumulative maximum of 18 objectives across three rounds. - Staging deployment and case-specific replay remain pending, so the problem stays `candidate` rather than `optimized_verified`. - The first staging `ST-2863` replay (`051ab664-2f6b-4c70-9b57-9ff297cee4b9`) exposed an invalid strict response schema before any provider query: the new `evidenceRefinement` property was not listed in the top-level required array. This is tracked as rollout-failure evidence and is not counted as a diagnosis result; the schema hotfix and replay are required before verification. - The post-semantic-ID staging replay `684c394f-a140-4368-95f2-da5715a6c18c` exposed an OpenAI response-schema compatibility failure before provider execution: the artifact path pattern used a regex lookahead to cap the query-ID segment at 64 characters. The schema now uses a supported semantic-ID pattern while the backend parser independently preserves the exact syntax and 64-character limit. This run is rollout-failure evidence, not a diagnosis result. - Source PR [#672](https://github.com/tidbcloud/aisupport/pull/672) and app-delivery PR [#76476](https://github.com/tidbcloud/app-delivery/pull/76476) deployed image `ebb4871477df5dbb67eed7b460ac88e9c47f7317` to staging. The Deployment was 1/1 Ready, both health endpoints returned 200, poller and worker logs were healthy, and the job table contained no queued or running jobs. - `ST-2863` replay `a278d0c7-16c2-41ef-ad08-ec88db5c0059` completed with Clinic evidence. All three scenario parents inspected round 1, requested a different round 2, and resumed the same thread. The query-execution parent narrowed Slow Query from a one-hour, 20-row, query-time-ordered lookup to a 357-second, five-row, memory-ordered lookup with explicit plan, operator, key, row, and wait fields. Its second bounded HTTP 500 was returned to the parent, which stopped instead of issuing an identical third retry. - `TCID-13001` replay `e201d86d-6920-4b4f-bb02-988fe0a5d6a9` completed with Clinic evidence. After round 1 found co-window read-heavy digests and a 311-second DDL p95, the same parent issued one exact digest lookup for plan, process, wait, backoff, key, and row fields. The lookup completed empty, and the parent preserved that counter-evidence and stopped without round 3. - These replays pass the bounded mechanism criterion: provider errors are visible to the evidence agent, and the parent can issue a later batch whose query count, objective, fields, ordering, and subwindow are chosen from the actual prior result. They do not prove that every final diagnosis is precise. ## Unresolved gaps - `TCID-13001` still fell through the separate typed workload-identity and causality publication boundary, producing a more generic human handoff than the scenario evidence. That is a final-diagnosis integration gap, not a failure of adaptive evidence dispatch. - The Clinic Slow Query surface still returned HTTP 500 in `ST-2863`; adaptive correction made the failure explicit and bounded but cannot repair provider availability. - Cloud and OP share the mechanism, but the real-case verification here used Clinic. OP serialization remains covered by tests rather than a fresh live replay. - Neither Jira internal comment was refreshed: `ST-2863` was materially consistent with existing internal comment `23422952`, while the `TCID-13001` final publication still had the independent identity-boundary gap. Both existing comments were read back with `public=false`. ## Next validation action Track the `TCID-13001` typed identity/publication loss as a separate bounded diagnosis problem. Validate OP adaptive serialization on a suitable live case without reopening this verified evidence-dispatch problem.