Catalogue › AI Architecture › grounding-patterns

Grounding patterns

Chooses how an AI solution grounds on organisational data - Microsoft 365 work context, curated SharePoint knowledge, Graph connectors, Dataverse or structured data, or a custom retrieval index - judged on permissions, freshness, data movement and ownership. Use when a solution's knowledge spans several stores, when content would be copied or indexed outside its source, or when teams build overlapping indexes of the same data.

Department

AI Architecture

Lifecycle

Envision, Deliver, Improve

Maturity

adopter, builder, scaler, ai-enterprise

Risk tiers

1, 2, 3, 4

Platforms

m365-copilot, m365-agents, copilot-studio, ai-foundry, sharepoint, purview, fabric, azure

Editions

starter, scale, enterprise

Reviewers

design-authority, security-privacy

Status

draft

Copilot Cowork

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

Licence

CC BY 4.0, by Simon Foote

Purpose

Most AI quality and exposure problems are grounding problems. This skill chooses, at architecture level, how a solution reaches the organisational data it answers from: in place through Microsoft 365 work context, from a curated knowledge source, through a connector that indexes another system, through queries on structured data, or through a custom retrieval index. Each pattern has different consequences for permissions, freshness, data movement and ownership. The work goes wrong when content is copied into a new index that ignores source permissions, when several teams index the same data in different ways, and when nobody owns the copy.

When to use

• A solution needs knowledge from more than one store, or from a system outside Microsoft 365.
• A design proposes copying or indexing content outside its source system.
• Several teams are building their own indexes or knowledge stores over the same data.
• A reference architecture needs a standard grounding pattern.
• An agent's answers are stale or surprising and the grounding route is suspected.

When not to use

• Configuring the knowledge sources of a specific agent - use m365-agents:agent-grounding.
• Designing knowledge sources for a Copilot Studio agent - use copilot-studio:studio-knowledge-architecture.
• Choosing grounding approaches inside a Foundry build - use ai-foundry:foundry-grounding-strategy.
• Designing indexing, chunking and search for custom retrieval - use ai-foundry:retrieval-design.
• Setting the content standards sources must meet - use knowledge-management:knowledge-grounding-standards.
• Assessing whether a source is owned, current and permissioned correctly - use m365-agents:knowledge-source-readiness.

Questions to ask first

1. What questions must the solution answer, and which stores hold the authoritative answers?
2. Do people already have the right access to those stores, and should the solution respect exactly those permissions?
3. How fresh must answers be - live, daily or whenever the owner publishes?
4. Would any pattern copy data outside its source, region or tenant, and who would own the copy?
5. Is the data unstructured content, structured records or both?

Required inputs

• The solution brief with the questions it must answer and its audience.
• An inventory of candidate sources with owners and condition, ideally from knowledge-management:knowledge-inventory.
• Sensitivity classification of the sources.
• The platform decision from ai-architecture:platform-selection.

If a source has no owner, record it as a precondition rather than designing around it; an unowned source makes every pattern fragile.

Decision framework

Prefer patterns that leave data where it is and keep source permissions intact. Move down the table only when the row above cannot meet the need.

For every chosen pattern record: source, owner, permission model, freshness, where any copy lives, retention of the copy, and the trigger for review.

Practitioner approach

Start from the questions, not the stores. Collect a short list of real questions the solution must answer and trace each to where the authoritative answer lives. This often shows that two of the five proposed sources are never needed, and that the most important answer is in a system nobody mentioned.

Classify each needed source as content or records. Content suits retrieval; records usually suit a live query that returns the exact value. Grounding a model on exported spreadsheets of records produces confident, out-of-date numbers.

Prefer in-place patterns. Microsoft 365 grounding respects the user's existing permissions, which is a strength and a risk: it means any oversharing in the source becomes easy to find. The fix is to correct permissions at source with security-privacy:data-exposure-review, not to copy content somewhere else.

When content must move, design the copy as a governed asset. A connector or custom index is a new store with its own permissions, retention, region and owner. Ask how source permissions are mapped, how quickly deletions and permission changes reach the index, and who answers when it is wrong. If nobody can answer, the pattern is not ready.

Look across the portfolio. Where several solutions need the same source, offer one shared, owned grounding asset rather than many private indexes. This is often the largest saving the architecture function can make.

Choose custom retrieval last. It is right when specialist ranking, hybrid search or complex document structures are genuinely needed and an engineering team will operate it. Hand the detailed design to ai-foundry:retrieval-design.

Record the decision with freshness and permission tests attached, so evaluation can check that a user without access gets no answer and that a changed document is reflected in time.

Outputs

• A grounding design for the solution: questions traced to sources, chosen pattern per source, permission model, freshness, copies and owners.
• An architecture decision record on the architecture-decision-record template for any pattern that copies or indexes data.
• Preconditions for knowledge owners and for permission fixes at source.

Microsoft platform considerations

Microsoft 365 grounding, Agent Builder knowledge, Copilot Studio knowledge sources, connectors and Foundry retrieval each support different source types, permission handling and freshness. Check ms-copilot-privacy for how permission-trimmed grounding works and ms-agents-extensibility and ms-agent-builder for current knowledge options before fixing a pattern.

Adoption considerations

Users trust answers they can trace. Prefer patterns that cite the source, and tell knowledge owners how their content is used so they keep it current.

Knowledge considerations

This skill depends on knowledge-management for ownership, quality and review cycles. Every pattern needs a named knowledge owner per source, and poor sources are a precondition, not something architecture can fix.

Security and privacy considerations

Copies and indexes are where exposure grows. Record region, retention and permission mapping for every copy, and send the design to the security-privacy review, with personal data in sources routed to security-privacy:privacy-assessment.

Responsible AI considerations

Answers grounded on incomplete or biased sources can disadvantage people. Where outputs inform decisions about people, record source limitations and route the case to the responsible-ai review through risk classification.

Evaluation requirements

Include permission tests (users with and without access), freshness tests (a changed or deleted document) and groundedness tests in the solution's evaluation, consistent with evaluation-quality:groundedness-testing.

Value measures

At portfolio level, track the number of duplicate indexes over the same data, shared grounding assets in use, and grounding-related defects found in evaluation and operation. The AI solution architect owns these, with the knowledge manager, and takes the baseline from the first portfolio review.

Scale notes

Starter

Ground on curated, owned Microsoft 365 content wherever possible, fix permissions at source and avoid custom indexes.

Scale

Publish standard grounding patterns, maintain a list of grounding assets and their owners, and require a recorded decision for any copy.

Enterprise

Offer shared, owned grounding assets per major data domain, aligned with data governance and data products, and review indexes for duplication and freshness on a set cycle.

Hand-offs

• To m365-agents:agent-grounding, copilot-studio:studio-knowledge-architecture or ai-foundry:foundry-grounding-strategy for build.
• To ai-foundry:retrieval-design when custom retrieval is chosen.
• To knowledge-management:knowledge-grounding-standards for source preconditions.
• To security-privacy:data-exposure-review for the security gate.

Reviewer gates

From risk tier 2 the grounding design is reviewed by security-privacy (blocking) for exposure and copies, and by design-authority for conformance and duplication. Tier 3 and above also need evidence for evaluation-quality.

Failure modes

• Content is copied into a custom index that ignores source permissions, and restricted content reaches everyone.
• Records are grounded as exported documents and the solution gives confident, stale numbers.
• Several teams index the same system separately, and their answers disagree.
• Deleted or corrected content remains in an index for weeks because freshness was never designed.

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

• Copy content into a new store without recording its permissions, retention, region and owner.
• Fix oversharing by moving content instead of correcting permissions at source.
• Choose custom retrieval when an in-place pattern meets the need.
• Assume a connector maps source permissions correctly without testing it.