# Microsoft-Native Internal Grounding Pilot

## Decision

The first internal deployment path for the AI Capability Playbook should separate the reader site, grounding corpus, and interpretation surface.

```text
Internal static site = human reading surface
Approved playbook package = grounding corpus
Copilot Studio or approved Microsoft-native agent = chat / semantic explainer surface
External pulse check = separately labeled mode, not source truth
```

The site is for readers.
The corpus is for grounding.
The agent is for interpretation.
The model is not the source of truth.

This is an architecture and pilot-planning note only. It does not deploy anything, configure Copilot Studio, move source files, or create runtime behavior.

## Candidate MVP Architecture

```text
Azure/internal static web endpoint
  -> hosts generated AICD static site for readers

SharePoint or controlled document library
  -> stores approved source corpus and context-pack files if governance prefers Microsoft-native document control

Copilot Studio or approved Microsoft-native agent surface
  -> uses approved source corpus for Find / Explain / Assess
  -> cites package sources
  -> refuses when not grounded
  -> links to internal static site pages
```

The assistant should reason over canonical package files and generated context-pack files. It should not rely on scraping rendered HTML as the only grounding source.

## Internal Static-Site Options

The human reading surface needs a stable internal URL, ordinary browser access, and predictable links from assistant answers.

| Option | Fit | Boundary |
|---|---|---|
| Azure Static Web Apps or equivalent internal static endpoint | Good fit when enterprise hosting permits static artifacts, access controls, and stable internal URLs. | Requires platform and security approval. This note does not provision it. |
| Azure Storage static website or equivalent static hosting behind approved network controls | Good fit when static files can be served without app runtime behavior. | Must be reviewed for authentication, network exposure, logging, and content approval. |
| Internal web server or managed intranet static endpoint | Good fit when an existing internal publishing lane can host generated HTML, CSS, JS, and downloads faithfully. | Must preserve route, asset, download, and browser behavior. |
| SharePoint page or document library | Potentially useful for document access and governance workflow. | Do not assume it faithfully hosts the generated static HTML site, routes, scripts, downloads, and portable exports. |

## Approved Grounding Corpus

The grounding corpus should prefer repo-controlled, approved package files:

- `source/*.md`
- `packages/**/*.md`
- `docs/product-architecture/*.md`
- `context-pack/*.md`
- `context-pack/*.json`
- `context-pack/*.jsonl`
- `docs/artifact-manifest.json`
- source maps
- grounding rules
- glossary
- claim and source-boundary files
- validation receipts where assessment or provenance depends on them

Rendered HTML may be linked for human reading. It should not be the only grounding substrate.

## SharePoint Role

SharePoint may be acceptable as:

- a controlled source/document library
- a review and approval location for approved corpus files
- a Microsoft-native access-control surface
- a place to store approved source packages, context-pack files, receipts, or exported review packets

SharePoint should not be assumed to be:

- a faithful static HTML hosting surface
- the canonical source of truth merely because files are uploaded there
- a substitute for source maps, manifests, hashes, or validation receipts
- evidence that a tool, data class, workflow, production use, or policy is approved

If SharePoint becomes the governed document location, it should preserve package identity, file hashes where practical, approval status, source path lineage, and clear separation between canonical corpus files and generated derivatives.

## Microsoft-Native Agent Surface

Copilot Studio or another approved Microsoft-native agent front end can be evaluated as the first interpretation surface if enterprise governance permits it.

The pilot surface should support:

- Find: locate matching artifacts and sections
- Explain: explain approved playbook concepts in plain language
- Assess: evaluate proposals against AICD criteria
- citations to package sources
- not-found behavior when the corpus is silent
- clear approval-boundary language
- links back to internal static-site reader pages

The pilot surface should not:

- use model memory as authority
- silently use external sources in Playbook-grounded mode
- imply company approval
- mutate source files
- create durable memory
- trigger workflow actions
- replace human review

## Linking Back To Reader Pages

Assistant answers should link back to stable internal reader pages when a corresponding page exists.

Minimum link behavior:

- cite source path, artifact ID, section ID, or context-pack reference as the grounding source
- include an internal static-site URL for human reading when available
- keep source citation and reader link distinct
- state when only source citation is available and no stable reader link exists

Reader links help humans navigate the site. They do not replace source citations.

## Playbook-Grounded Mode

Default mode should be Playbook-grounded.

```text
Answer only from approved corpus.
Cite source sections.
Refuse when not found.
Do not use model memory as authority.
Do not imply company approval.
```

Playbook-grounded mode should treat the approved corpus as the only source of answer authority. If the approved corpus does not support an answer, the assistant should refuse or mark the gap.

## External Pulse-Check Mode

External pulse-check mode must be explicit and separately labeled.

```text
Use current external sources only when explicitly requested.
Label output as external context.
Do not overwrite or silently modify playbook guidance.
Do not treat external findings as approved corpus guidance.
```

External pulse-check output is not source truth. It can inform future review, update candidates, or issue creation, but it must not silently modify the playbook, override source boundaries, or become approved guidance without a governed update.

## Proposal Artifact Path

Later proposal assessment can use a controlled intake pattern:

```text
requester proposal artifact
  -> controlled intake location
  -> source-grounded assessment against AICD criteria
  -> review memo / missing-info checklist / approval-conditions note / email draft
```

Architecture-level requirements:

- the proposal artifact must be treated as user-submitted evidence, not approved playbook source
- assessment findings must cite AICD criteria and package sources
- missing proposal evidence should be labeled as missing evidence
- output packets should be generated derivatives
- human reviewers retain approval, rejection, escalation, and risk-acceptance authority

This note does not implement upload, intake, workflow routing, email generation, review packet generation, or enterprise integration.

## Deferred Unless Proven Necessary

Keep these out of the MVP architecture:

- custom API marketplace model path
- custom chat backend
- vector database
- graph database
- hosted retrieval service
- connector ingestion
- durable memory
- enterprise workflow integration
- autonomous agent workflow
- infrastructure-as-code
- output schema automation beyond documented review-output candidates

## Relationship To Existing Issues

| Issue | Relationship |
|---|---|
| #150 | Builds on the product architecture decision that the playbook is the active governed knowledge package. |
| #153 | Provides a Microsoft-first internal pilot path for the semantic explainer and proposal assessment contract. |
| #78 | Informs the source-grounded assistant prototype by identifying a practical enterprise pilot surface. |
| #79 | Keeps backend and graph evaluation deferred until Microsoft-native corpus grounding proves insufficient. |
| #88 | Should inform reader orientation because assistant answers need stable internal reader targets. |
| #151 | Does not supersede DOCX rebuild idempotence, which remains a separate follow-up. |

## Non-Goals

This note does not:

- deploy anything
- configure Copilot Studio
- implement a chatbot
- add infrastructure-as-code
- build a custom backend
- add a database or vector store
- add provider/model execution
- add connector ingestion
- create durable memory
- create enterprise workflow integration
- change published public-site behavior
- move source content into SharePoint or Azure