# 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

## 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. What should I read first?

| Reader question | Start here | Then read |
|---|---|---|
| I am new to the playbook. | Playbook Map | Shared Capability Foundations |
| I need shared vocabulary before review or build work. | Shared Capability Foundations | AI Capability Discipline |
| I need the mental model for governed AI capability. | AI Capability Discipline | Playbook Map if the package relationship is unclear |
| I need to decide whether work should consume team capacity. | MLL WESS Development Commitment and Build-Readiness Framework | Shared Capability Foundations |
| I need a concrete governed assistant pattern. | Enterprise Architecture Review Assistant | Shared Capability Foundations |
| I need communication or rendering support. | Prompt Packs | Playbook Map |

## 4. 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. |

## 5. 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. |

## 6. 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. |

## 7. 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 |

## 8. 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.