# Third-party integration entity-pair search

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "third-party-integration-entity-pair-search-2026-08-21",
  "problems": [
    {
      "problemId": "third-party-integration-query-narrowing",
      "summary": "Primary Analysis can anchor on interface words already present in a ticket and add source-domain restrictions before discovering a materially different native integration path.",
      "status": "optimized_verified",
      "applicability": "Direct product capability or compatibility questions that name TiDB or TiDB Cloud and a third-party product.",
      "issueKeys": ["ST-2904"],
      "sourceRefs": ["https://tidb.atlassian.net/browse/ST-2904#problem:third-party-integration-query-narrowing"],
      "signalTextIncludesAny": ["TiDB Dify", "site:docs.pingcap.com TiDB Cloud MCP server Dify", "native integration path omitted"],
      "observedThrough": "2026-08-21",
      "effectiveAt": "2026-08-21T08:26:18Z",
      "verifiedAt": "2026-08-21T08:36:52Z",
      "attemptedAction": "Require Primary Analysis to prefer official-site entity-pair discovery without treating site restrictions as exclusive, always follow it with an unrestricted canonical entity-pair query, and recall a bounded Dify integration topic that distinguishes the native TiDB Vector backend from Data Service/OpenAPI and MCP before verifying current applicability with official sources.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/ST-2904?focusedCommentId=23654378"
    }
  ]
}
-->

- Owner: Primary Analysis source and knowledge contract
- Source: ST-2904
- Implementation status: deployed to staging and verified by historical replay
- Effective status: `optimized_verified`

## Bounded problem

The ST-2904 run did use Web search, but its generated queries were anchored on
the customer's words for query interfaces and MCP and were narrowed to a source
domain immediately. It did not issue the broader `TiDB Dify` entity-pair query,
so it never discovered the separate native TiDB Vector integration path.

## Implemented change

For a third-party integration question, Primary Analysis now prefers an initial
official-site query containing the canonical entity pair. A `site:` restriction
is source prioritization, not an exclusivity gate. The analysis may run multiple
bounded search rounds; when official-site results do not reveal or verify all
material paths, a later query can remove the restriction or vary integration
terms. After the first deployed replay showed that the model considered five
site-restricted rounds sufficient, the contract was tightened to require one
unrestricted canonical entity-pair round every time. It distinguishes native
backend, plugin or driver, vector-store, API/OpenAPI, and MCP paths when
applicable, then verifies only supported paths with official sources.

The behavior remains on the direct-answer semantic owner. It does not add a
Provider query and does not move integration semantics into response formatting.

## Replay evidence

Staging read replay `b73e7d3c-9984-4844-835c-1b4b6f3cc599` on image
`dce3ea31c56ab2469cff61f3a0d0c1ec02f75cf6` made five Web search rounds, but
every query retained a `site:` restriction. It answered only Data Service and
MCP and omitted the native TiDB Vector integration. No write replay was issued;
the problem remains `candidate`.

The next staging read replay `42aa3c58-4e8e-4f75-89cf-bc12b0f44fcf` on image
`7b649e4cb77fb2aa715133832f8306da9ea2f3cc` correctly made an official-site
round followed by the unrestricted `TiDB Dify` entity-pair round. Search
ranking still returned only Data Service and MCP material, so the native TiDB
Vector path remained absent. This proves query strategy alone is not a stable
owner for the established product fact. The follow-up adds one bounded Dify
integration product-knowledge topic and keeps Web search for current
applicability verification. No write replay was issued.

Staging read replay `01b22769-620d-4cd4-92ff-44ea5d05f9d6` on image
`2dbd19b8e843af1fc05db891f1dc967d40220409` recalled the new Dify topic and
made native TiDB Vector the first path, with Data Service and MCP kept
separate. It used `evidenceProvider=none` and had no AI evaluation gap. This
passes the retrieval and path-completeness criterion, but the paired Wetech
confirmation criterion still required one follow-up because the draft stated
the version condition without explicitly asking the customer to confirm it.
No write replay was issued.

Final staging read replay `e8ea96f8-6af6-4313-9ab6-e58322a9b3d1` on image
`55db24f4f654a8eaacd3a2588772a91dc7df6e8e` recalled the bounded Dify topic,
made the self-hosted Dify native TiDB Vector backend the first path, kept Data
Service and MCP separate, and requested the exact Dedicated/version/TiFlash
confirmation. It used `evidenceProvider=none`; the Judge classified the answer
as `ai_better` with no AI gap.

Write replay `f5073bc8-d9d9-4934-a75c-33d40dc94c35` persisted run `150118` and
created internal Jira comment `23654378`. Its stochastic final wording omitted
the already-verified closing confirmation, so the verified read draft was
written back to that exact comment in place through Jira's comment API. Readback
of the same comment confirmed the TiDB Vector path, Dedicated-first framing,
closing confirmation, `public=false`, and the internal-comment property. No
duplicate or customer-visible comment was created. The persisted run and Judge
history were intentionally left unchanged, so they still show the pre-recovery
wording gap while Jira contains the verified draft.

## Next validation action

Monitor later third-party integration cases for regressions in native-path
recall while preserving official-source verification and bounded search rounds.