# Playbook Map v0.1

Status: public orientation map and operating crosswalk
Date: 2026-06-17  
Boundary: field guidance candidate, not final policy

## 1. What this map shows

The Playbook Map explains how the AI Capability Playbook moves from shared vocabulary to doctrine, build-readiness discipline, an applied reference implementation, and prompt packs.

Use it when a reader needs to decide:

- what to read first
- which artifact helps which decision
- how a demo, assistant, prompt, agent, or prototype should move toward governed capability work
- which concepts must stay shared and which details should remain local to a package
- which reader path fits their current role or question
- where future source-grounded assistant answers should link back into stable reader surfaces

## 2. Playbook orientation map

| Playbook surface | What it provides | Use it when |
|---|---|---|
| Shared Capability Foundations | Reusable terms and control concepts: capability, source authority, evidence states, non-inference, readiness, evals, review, capacity, and sustainment. | You need common language before review, build, or operating decisions. |
| AI Capability Discipline | The doctrine and teaching layer for understanding why model access, prompts, agents, and demos are not capability by themselves. | You need the mental model for governed AI capability formation. |
| MLL WESS Development Commitment and Build-Readiness Framework | The operating model for when an idea asks for team capacity, contractor effort, Jira commitment, or operational support. | You need to decide whether work needs feasibility check, preflight, or operationalization discipline. |
| Enterprise Architecture Review Assistant | A concrete reference pattern showing how governed assistant design uses sources, controls, evidence states, evals, and human review. | You need a worked implementation pattern for governed assistant architecture. |
| Prompt Packs | Renderer-ready prompts and communication assets for the playbook family. | You need to explain, visualize, or communicate the playbook consistently. |

The pieces overlap by design, but they should not collapse into one document. Shared primitives stay in Shared Capability Foundations. Teaching stays in AI Capability Discipline. Local capacity rules stay in MLL WESS. Domain-specific assistant architecture stays in the Enterprise Architecture Review Assistant.

## 3. Start Here reader paths

| Reader path | Read first | Use next | Helps answer | Boundary |
|---|---|---|---|---|
| Executive or sponsor | Playbook Map | AI Capability Discipline executive sections and audience briefs | Should AI be used here, what outcome matters, and what proof is needed before funding or scale? | Does not approve broad pilots, production routing, tool access, data use, or supplier paths. |
| Enterprise architect | Shared Capability Foundations | AI Capability Discipline, then Enterprise Architecture Review Assistant | What source authority, evidence, schema, eval, review, and sustainment controls are missing? | Does not approve architecture decisions, data classes, workflow exceptions, or production readiness. |
| Governance, risk, or compliance reviewer | AI Capability Discipline policy-boundary and provenance sections | Grounding rules, claim posture, source maps, and receipts | What is field guidance, what is owner-validated, and what still needs formal review? | Does not approve company policy, regulated use, security posture, privacy posture, or data movement. |
| Product or platform owner | Playbook Map | MLL WESS and product-architecture notes | Is this an idea, prototype, pilot, operational capability, or deferred infrastructure path? | Does not approve hosting, Cloudflare, Supabase, Copilot Studio, backend, or platform deployment work. |
| Builder or implementation lead | Shared Capability Foundations | MLL WESS, Enterprise Architecture Review Assistant, and validation receipts | What contracts, evals, telemetry, review loops, and package checks are needed before build commitment? | Does not approve runtime behavior, provider calls, connector ingestion, private-data workflow, or enterprise integration. |
| Practitioner or learner | AI Capability Discipline | Shared Capability Foundations and worked examples | Why are prompts, agents, evals, and demos only components, and how does capability formation work? | Does not approve use of any AI tool, data class, workflow, or production process. |
| Assistant or AI-consumable package user | Context pack manifest and grounding rules | Source map, glossary, sections, claims, and source-grounded explainer notes | Which package sources may ground future Find, Explain, or Assess answers, and where should cited answers link readers? | Does not approve model-memory answers, runtime chat, provider execution, or generated assessment output as source truth. |

The assistant or AI-consumable path is not a runtime entry point. It is a source-boundary path for future grounded interpretation over the approved package only.

## 4. Source truth, derivative views, and assistant targets

| Surface | Use it for | Do not treat it as |
|---|---|---|
| Canonical source and packages | Source truth, preserved package identity, and owner-reviewable guidance | A generated derivative or runtime approval record |
| Public HTML and portal pages | Human reading, navigation, search, and stable reader targets | The only grounding substrate or product boundary |
| Portable exports | Offline reading and controlled transfer of rendered package views | A replacement for source files, manifests, hashes, or receipts |
| Context pack | AI-consumable package material for grounded reasoning sessions and future assistant citation support | Runtime permission, model memory, external retrieval approval, or provider execution |
| Validation receipts and hash files | Evidence that generated surfaces, mirrors, packages, and exports were checked | Semantic approval, policy approval, or enterprise production authorization |

## 5. Artifact-to-decision matrix

| Artifact | Helps decide | Primary reader |
|---|---|---|
| Playbook Map | Where to start and how the playbook pieces fit together. | First-time readers, leaders, architects, reviewers, builders. |
| Shared Capability Foundations | Which shared terms, control concepts, and architectural primitives should govern the conversation. | Anyone aligning vocabulary before review, build, or operating decisions. |
| AI Capability Discipline | Whether an AI idea is still a component, demo, or prototype, or whether it is becoming real capability. | AI leaders, enterprise architects, governance leaders, practitioners. |
| MLL WESS Development Commitment and Build-Readiness Framework | Whether work should enter feasibility check, preflight, team capacity planning, Jira commitment, or operationalization. | Managers, engineers, service owners, delivery leads. |
| Enterprise Architecture Review Assistant | How a governed assistant should handle source authority, evidence states, controls, evals, review, and implementation boundaries. | Architecture teams, platform engineers, governance reviewers, implementation partners. |
| Prompt Packs | How to render or explain the playbook family consistently for communication and review. | Communicators, facilitators, reviewers, and builders preparing presentation surfaces. |

## 6. What stays shared

| Keep shared | Canonical home | Reason |
|---|---|---|
| Capability equation and readiness language | Shared Capability Foundations | Prevents every package from inventing a different maturity model. |
| Source authority, evidence states, and non-inference rules | Shared Capability Foundations | Keeps assistant, review, and governance language aligned. |
| Human review, eval fixtures, telemetry, sustainment, and retirement concepts | Shared Capability Foundations | Turns the discipline into testable, maintainable operating behavior. |

## 7. What stays local

| Keep local | Package | Reason |
|---|---|---|
| WESS decision rights and preflight thresholds | MLL WESS | They depend on local capacity, service ownership, contractor use, and Jira behavior. |
| Enterprise Architecture review criteria, source catalogs, controls, and decision memory | Enterprise Architecture Review Assistant | They are domain-specific to architecture review and must be owned by the relevant source owners. |
| Broad teaching narrative | AI Capability Discipline | It must remain portable across teams, domains, and use cases. |

## 8. Term alignment

| Shared term | AI Capability Discipline | MLL WESS | Enterprise Architecture Review Assistant |
|---|---|---|---|
| Idea | Level 0: Idea | Sandbox | Concept or intake shaping |
| Sandbox | Prompt artifact or reusable harness candidate | Sandbox | Manual exploration |
| Feasibility check | Discovery or early readiness | Time-boxed feasibility check | Manual harness rehearsal or discovery prototype |
| Preflight-approved proof | Eval-backed assistant or governed pilot candidate | Preflight-approved proof | Controlled evidence-loop implementation proof |
| Operationalized capability | Operational capability | Operationalized capability | Supported review assistant |
| Human-owned decision | Human review and override | Team leader or accountable owner decision | Architect or governance reviewer decision |

## 9. Governance rule for future edits

Any future package update that changes shared terms, evidence states, source authority levels, non-inference rules, readiness levels, or human review semantics must update Shared Capability Foundations first, then propagate to the dependent package.

Any future package update that changes only local decision rights, local approval thresholds, platform-specific implementation detail, or domain-specific controls should stay in the local package.