Support asserting a specific SharePoint knowledge source in RetrievalResult

Problem

Steve from the IES Agent team reported a scenario where a declarative agent has multiple SharePoint sites configured as knowledge sources. The team needs an evaluation that verifies the agent retrieved from the correct SharePoint site, rather than only verifying that the OneDriveAndSharePoint capability ran.

Current behavior

RetrievalResult can currently assert:

• capability
• max_rank
• min_expected_count
• expected_items[].retrievalExtract_contains

However, URL-based expected items are explicitly rejected in V1. RetrievalQuery.selector also evaluates queryString; it is not a site selector. The evaluation diagnostics expose retrievalHits[].webUrl, and successful extract matches return matchedHitUrl, but these values are diagnostic-only and cannot affect evaluator pass/fail.

A content-based assertion can be used as an approximation:

"RetrievalResult": {
  "capability": "OneDriveAndSharePoint",
  "max_rank": 5,
  "expected_items": [
    {
      "retrievalExtract_contains": "a distinctive statement from the expected site"
    }
  ]
}

This does not prove that a particular site was selected when content is duplicated, moved, or shared across knowledge sources.

An attempted URL assertion is rejected by schema and constructor validation:

"expected_items": [
  {
    "webUrl": "https://contoso.sharepoint.com/sites/expected-site/...",
    "retrievalExtract_contains": "distinctive text"
  }
]

Expected behavior

Provide a supported way for RetrievalResult to assert the identity of the selected SharePoint knowledge source or retrieved resource. Possible options include:

• siteUrl or siteId for site-level assertions
• webUrl or webUrl_contains for retrieved-resource assertions

The assertion should operate on the normalized retrieval hit URL/identity within max_rank, contribute to pass/fail, coexist with extract assertions, and report the matched URL/site in the result diagnostics.

Validation

This limitation was reproduced against the current implementation and its focused retrieval schema/integration tests. The pipeline preserves the retrieved webUrl, but the evaluator intentionally does not compare it.

Start with the focused retrieval schema and integration tests mentioned in the issue, then trace how normalized retrieval hits preserve webUrl and identity through evaluation. Done means a supported site or resource assertion affects pass/fail alongside extract assertions and reports the matched URL or site in diagnostics.