Catalogue › Microsoft Foundry › foundry-grounding-strategy

Foundry grounding strategy

Chooses how a Microsoft Foundry solution grounds its answers and actions - supplied context, retrieval over indexed content, live lookups through tools, web grounding or none - per knowledge need, with ownership, permissions, freshness and citation decided before retrieval is engineered. Use when a Foundry agent needs organisational knowledge, when answers are confidently wrong, or when a team proposes fine-tuning to teach facts.

Department

Microsoft Foundry

Lifecycle

Mobilise, Deliver, Improve

Maturity

builder, scaler, ai-enterprise

Risk tiers

1, 2, 3, 4

Platforms

ai-foundry, azure, sharepoint, fabric

Editions

starter, scale, enterprise

Reviewers

security-privacy, evaluation-quality, design-authority

Status

draft

Copilot Cowork

Microsoft Foundry plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Licence

CC BY 4.0, by Simon Foote

Purpose

A model answers from what it was trained on unless the solution gives it something better, and for most organisational work the answer must come from the organisation's own, current, permitted information. This skill decides, for each kind of knowledge the solution needs, how it reaches the model: supplied directly in context, retrieved from an index, looked up live through a tool, taken from the web, or not needed at all. It settles ownership, permissions, freshness and citation before anyone starts tuning chunk sizes. Grounding goes wrong when every need is pushed into one vector index, when the index ignores who may see what, and when fine-tuning is used to teach facts that change every month.

When to use

• A Foundry agent or application has been approved and needs organisational knowledge or data to answer or act.
• Answers are fluent but wrong, out of date, or uncited, and the team suspects the grounding.
• A team proposes fine-tuning a model so it "knows" the organisation's policies or products.
• Structured business data and unstructured documents both need to inform the same answer.
• Someone asks whether the solution should use web search.

When not to use

• Engineering the index, chunking, embedding, ranking and filters once retrieval is chosen - use ai-foundry:retrieval-design.
• Organisation-wide grounding patterns across Microsoft 365, Copilot Studio and Foundry - use ai-architecture:grounding-patterns.
• Grounding a Microsoft 365 agent - use m365-agents:agent-grounding.
• Knowledge sources for a Copilot Studio agent - use copilot-studio:studio-knowledge-architecture.
• Setting the standards content must meet before agents use it - use knowledge-management:knowledge-grounding-standards.

Questions to ask first

1. What questions or tasks must the solution handle, and for each, what information would a capable person consult to do it well?
2. Is that information documents, structured records, live transactional data or public information, and who owns each source?
3. Do different users have different rights to the same source, and must answers respect those rights?
4. How quickly does each source change, and how stale may an answer be before it causes harm?
5. Must users be able to see where an answer came from?

Required inputs

• The agent or solution architecture, with its users and their access model.
• A knowledge inventory for the sources in scope, with owners and condition, from knowledge-management:knowledge-inventory where it exists.
• Data classification of each source, from data-governance:data-classification-for-ai where it exists.
• A set of real questions or tasks with known good answers, to test the strategy.

Where a source has no owner or its classification is unknown, mark it [To confirm: ...] and leave it out of grounding. Ungoverned content grounded into an AI answer becomes an authoritative-sounding error.

Decision framework

Choose per knowledge need, not per solution. Most solutions combine two or three approaches.

Fine-tuning changes how a model behaves, not what it reliably knows; it is never the grounding strategy for facts.

Practitioner approach

List the knowledge needs before the sources. Take the real questions and tasks and, for each, write what a capable person would look at to answer it. Group them into needs: reference text, document bodies, live records, analytical data, public facts. This stops the conversation starting with a vector database and ending with an index of everything.

Test each source before choosing an approach for it. Who owns it, is it current, is it duplicated elsewhere, and is it classified? A retrieval index amplifies whatever is in the source, including obsolete versions and drafts. Where content is in poor condition, the strategy carries a precondition to clean it with the knowledge-management department, and the solution waits or launches with that source excluded.

Decide permissions next, because they constrain everything else. If users have different rights to the same content, answers must be trimmed to the user, either by retrieval that applies the user's identity or security filters, or by a live lookup that runs as the user. A single service identity that can read everything, feeding everyone, is the commonest serious grounding flaw. Record which approach enforces permissions for each need.

Match freshness to harm. For each need, agree how stale an answer may be and choose the approach that meets it: live lookup for transactional data, scheduled re-indexing for documents, with the interval set by the owner. Record the refresh route and its owner.

Decide citation behaviour. For any answer that someone may rely on, the solution should show where it came from so the user can check. Design the grounding so that sources are traceable to a document or record, and decide what the solution does when nothing relevant is found: say so and hand over, never answer from the model's general knowledge as if it were organisational fact.

Treat external and user-supplied content as untrusted. Retrieved documents, mail and web pages can carry instructions aimed at the model, so grounding content must never be able to trigger tools or change the solution's behaviour.

Write the strategy as a table of needs, approach, source, owner, permission method, freshness and citation, and pass retrieval needs to ai-foundry:retrieval-design. Test it early with the real questions, looking separately at whether the right content was found and whether the answer used it faithfully. State what the strategy cannot determine: whether retrieval quality is good enough, which only groundedness testing shows.

Outputs

• The grounding section of the foundry-solution-design template: knowledge needs, approach per need, sources and owners, permission enforcement, freshness and refresh route, citation and no-answer behaviour.
• A list of content preconditions handed to the knowledge-management department.
• A retrieval brief for ai-foundry:retrieval-design covering each need that uses an index.

Microsoft platform considerations

Foundry can ground agents through several kinds of knowledge connection, including search indexes, files, connections to Microsoft 365 and data platforms, tools and web grounding, and the options, their permission handling and their preview status change frequently. Web grounding may involve services with separate terms and data flows outside the Azure boundary. Check the current source records for what each connection supports, especially whether it honours user permissions, before designing around it.

Adoption considerations

Users trust grounded answers more when they can see the source, and stop trusting the whole solution after one confident wrong answer. Explain what the solution knows and does not know at launch, and give people an easy way to report a wrong or outdated answer.

Knowledge considerations

This skill depends on knowledge being owned, current and classified. Each grounded source needs an owner who accepts that an AI solution relies on it and a review cycle through knowledge-management:knowledge-review-cycles. Questions the solution cannot answer are a signal for knowledge-management:knowledge-gap-analysis.

Security and privacy considerations

Grounding is where oversharing happens. Enforce user permissions for every source with mixed access, minimise personal data in indexes, set retention for indexed copies to match the source, and confirm processing locations for indexes and web grounding with the DPO. security-privacy:data-exposure-review reviews the strategy from tier 2.

Responsible AI considerations

Users must be able to tell an organisational answer from a model's general knowledge. Where answers inform decisions about people, money, safety or rights, citations and a clear no-answer path are mandatory, and the design goes to responsible-ai:ai-transparency.

Evaluation requirements

Evaluate retrieval and answer faithfulness separately on the real question set: was the right content found, was the answer supported by it, were citations correct, and did the solution decline when nothing relevant existed. Thresholds are agreed before testing, with evaluation-quality:groundedness-testing from tier 2.

Value measures

Measure answer accuracy and citation correctness against the baseline of how people find the information today, owned by the business owner, and track unanswered questions as a knowledge measure owned by the knowledge owner.

Scale notes

Starter

Ground on one or two well-owned sources with permission trimming and citations, supply small reference content directly, and avoid web grounding unless the use case requires it.

Scale

Reuse indexes and lookup tools across solutions where sources and audiences match, under shared ownership, and keep a register of which solutions ground on which sources.

Enterprise

Treat grounding sources as governed data products with owners, service levels and lineage, and require design review for any solution that grounds on sensitive or cross-business content.

Hand-offs

• To ai-foundry:retrieval-design for index, chunking and ranking design.
• To ai-foundry:foundry-tool-design for live lookup and query tools.
• To knowledge-management:knowledge-readiness-assessment when sources need preparation.
• To data-governance:ai-data-access-model for permission design on data products.
• To evaluation-quality:groundedness-testing for groundedness evidence.

Reviewer gates

From risk tier 2, security-privacy reviews permission enforcement and data exposure, evaluation-quality reviews groundedness evidence, and design-authority checks the approach conforms to the reference grounding patterns. A source with mixed access grounded through an untrimmed service identity is a blocking finding.

Failure modes

• Everything is pushed into one index, and live data is answered from a stale snapshot.
• A service identity indexes content users cannot open, and the solution reveals it to them.
• Obsolete and draft documents sit beside current ones, and the model cites the wrong version confidently.
• The solution answers from general model knowledge when retrieval finds nothing, and users cannot tell.
• A model is fine-tuned on policies that change the next quarter, and keeps repeating the old rules.

Sources

references/sources.md in this skill lists the source records behind this skill, what each is authoritative for, how volatile it is and what you may do with it. Product availability, licensing, limits and preview status change often, so check the current source before stating them, and cite what you used.

Never

• Ground on a source that has no owner or unknown classification.
• Serve content to users who could not open it themselves.
• Use fine-tuning to keep facts current.
• Send organisational or personal data to web grounding without accepted terms and a confirmed data flow.