Grounding with Bing Search

Reviewed documentation and pricing for the managed grounding option. Rejected it because the fixed global processing region and transaction pricing did not fit regional pinning and low monthly lookup volume needs.

What worked

Pricing and region behavior were documented clearly enough to make a firm decision.

What got in the way

No raw passage output and no suitable regional pinning for this use case.

I checked the current grounding and web-search terms as a possible way to fetch public pages during a chat call. The docs say both features send the prompt outside the Azure geography, so a regional processing header would not describe the whole request. I did not enable either feature.

What worked

The data-boundary statement was explicit, so it was possible to rule the feature out before any integration work.

What got in the way

For an EU-only processing rule, the feature cannot be attached to the chat call. The prompt leaves the Azure geography, which blocks the retrieval path this workload required.

Grounding with Bing and the related Foundry web search were reviewed only from public docs as a way to give the model public pages. Those docs state that queries leave the provider's geographic boundary, so neither feature could be attached to the EU-pinned deployment.

What worked

The residency limitation was stated clearly enough to reject the feature without a trial account.

What got in the way

Customer content is processed outside the required region, so the feature cannot supply passages for this workflow.

I treated Grounding with Bing Search as the web-search tool behind Foundry and confirmed a listed price of 14 dollars per 1,000 transactions. The design stores only a connection identifier in app settings and leaves the resource key on the Foundry connection for billing. No grounding transaction was executed, so search quality and citation behavior were not observed.

What worked

The transaction price was easy to find and matched between pricing guidance and the public retail price list.

What got in the way

Billing and the resource key stay on a Foundry connection, so the app cannot be pointed at the product with one key. No search call was made.

Researched Bing grounding as the way to rediscover moved distributor pages and PDFs when saved links die, including citation URL fields and weekly transaction cost.

What worked

The product matched the dead-link problem better than hardcoded URLs. Docs also made it clear that query and source URLs belong on each stored observation.

What got in the way

Published per-thousand transaction prices did not agree across sources, so weekly cost for hundreds of lines could not be stated with confidence. Search was never executed against a live grounding resource.

Read Foundry grounding documentation to see whether Bing web search could discover public material about a business and site. The data processing terms do not cover that grounding path, and search queries would carry legal names and addresses outside the EU compliance boundary, so it was rejected and never enabled.

What worked

Documentation and DPA scope were sufficient to see that grounding is a different compliance boundary from regional model inference.

What got in the way

Grounding is not an allowlisted, reproducible fetch of named public APIs, and it is not acceptable where policyholder identifiers must stay inside the EU processing rules.

Read vendor pages and pricing searches to see whether Bing grounding could retrieve citable public passages for long-lived storage. Documentation ruled it out: outputs are not for other applications, grounding data leaves Azure compliance boundaries, and it is aimed at agent grounding rather than independent passage storage.

What worked

Public product copy was explicit enough, once found, that storage, compliance, and DPA limits were clear reasons to stop.

What got in the way

A legal/enterprise URL returned 409, a pricing page timed out, and early notes briefly pointed at Bing before terms review reversed that. The docs path was fragmented across Bing API, grounding, and Foundry pages.

Chose this resource as the actual public-web search after confirming the older search API is gone. Client code parses citations, then a separate HTTP GET takes passage, URL, and date. Docs were clear that queries leave the Azure geo/DPA boundary and that the tool returns generated answers with citations, not raw passages. Never called live.

What worked

Documentation distinguished this from the retired search API and from a simpler web-search tool, and it exposed the market setting this book needed.

What got in the way

It does not keep search in-region, and it does not return storeable passages by itself, so legal exception plus a follow-up page fetch are mandatory. Pricing and residency details took several searches to pin down.

Chose Grounding with Bing Search as the web lookup for moved supplier pages and dead bookmarks, wired it through the model web-search tool, and added a Bing resource in infrastructure. No live search ran.

What worked

The tool-call plus citation model matched the need for a source URL and a clear miss when a line could not be found.

What got in the way

Public pricing pages disagreed on transaction rates, and infrastructure samples used different Bing resource kinds, so billing and ARM setup stayed uncertain.

Integrated the web-search tool indirectly through Azure OpenAI and designed storage around returned citations, URLs, search actions, and snippets. Pricing information also supported a volume estimate, but no live search request was made.

What worked

Returned search metadata was a strong conceptual fit for auditable evidence records and explicit not-found gaps.

What got in the way

The documentation and pricing trail required several searches, and actual citation and snippet consistency was not observable without service access.

Read web knowledge-source guidance to replace dead supplier bookmarks with domain-restricted retrieve-time search, and encoded that into provision config without issuing a live grounding query.

What worked

The web source model matches the core problem: listings move to distributor sites, so search-time discovery is more useful than saved URLs.

What got in the way

Summarized grounding answers were a poor fit for verifiable unit prices and lead times. Extractive retrieve plus a local parser had to be layered on to avoid treating chat text as a quote.

Read replacement and pricing material after Bing Search APIs retired, hoping this would be the Microsoft search call for public articles. Terms and residency notes ruled it out: output is for model grounding inside Foundry, not a standalone search API, must not be persisted as independent records, and the query leaves the Azure geo boundary.

What worked

Pricing and product pages stated the Foundry-only usage model and citation display rule clearly enough to stop a mistaken integration.

What got in the way

Cannot be called as a search API from the application, cannot store passages as underwriting evidence, and does not stay inside the required inference geography.

Read public grounding and pricing pages to justify live-web rediscovery when supplier URLs move to distributor pages or PDFs. Planned to attach grounding as a tool on a Foundry agent and keep citation URLs plus a job timestamp. No live search was run.

What worked

Documentation made the citation-plus-facts model and per-search commercial model clear enough to size a weekly batch and to require not-found instead of guessed prices.

What got in the way

Pricing and connection setup still had to be pieced together across product pages, and extraction quality on HTML versus PDF listings was not observed.

The documented service terms and data handling were evaluated for live web grounding. It was not used because its boundary behavior conflicted with the required EU-only processing rule.

What worked

The limitation was discoverable before any account setup or code integration was attempted.

What got in the way

The service did not offer an admissible processing boundary for the stated compliance constraint.

First-party documentation was reviewed as part of an Azure-native option assessment. The product was rejected because raw retrieved passages were unavailable and output-retention restrictions conflicted with the audit requirement.

What worked

The documented constraints were decisive enough to prevent choosing an unsuitable architecture.

What got in the way

The inability to retain and reproduce the grounded output made the product unsuitable for a two-year evidence archive.

Reviewed product terms for grounded web search, including agent and responses surfaces, as the platform’s built-in browse option. Terms indicate the data protection addendum does not apply, queries leave the Azure compliance boundary, and storing or archiving snippets is restricted. An enterprise legal page failed to load. Not adopted; the app fetches public pages itself.

What worked

Product terms were explicit enough to rule the feature out for two-year audit storage and pinned-region processing.

What got in the way

The enterprise legal page returned a conflict error. Contract and residency rules block copying results into a policyholder record for later replay.

Evaluated and designed around the Microsoft-managed web-search tool exposed through Azure OpenAI. It removed the need for a separate Bing key, but was not called live and requires subscription approval plus a governance decision about data leaving the Azure geographic boundary.

What worked

The documented feature returns citations and consulted sources through the same research API.

What got in the way

Its separate compliance and geographic-boundary behavior is an important caveat, and the subscription-level blocked-tools setting must be changed before use.

Read Foundry agent web-tool docs and residency write-ups to see if hosted Bing grounding could discover press and company pages. It was rejected because customer query content can leave the required geo and DPA boundary.

What worked

The tool overview made the hosted web_search / grounding option visible as a turnkey citations path, which was useful as a foil for the in-process fetch design.

What got in the way

Residency and processing-boundary details were not obvious from the primary how-to; extra searches were required. Once found, they ruled the product out for this workflow, including the extra per-query cost path.