Start here
What this map shows
The Playbook Map explains how the public playbook moves from shared vocabulary to doctrine, build-readiness discipline, an applied reference implementation, and prompt packs. It helps a reader choose the right page without treating every package as a separate starting point.
How to use it
Pick the question you need to answer
Use this page when you need to decide what to read first, which artifact supports which decision, or how a demo or prototype should move toward governed capability work.
Playbook Map v0.1
Status: public orientation map and operating crosswalk. Field guidance candidate, not final policy.
1. Playbook orientation map
Shared Capability FoundationsReusable terms and control concepts: capability, source authority, evidence states, non-inference, readiness, evals, review, capacity, and sustainment.
AI Capability DisciplineThe doctrine and teaching layer for understanding why model access, prompts, agents, and demos are not capability by themselves.
MLL WESS Build ReadinessThe operating model for when an idea asks for team capacity, contractor effort, Jira commitment, or operational support.
Enterprise Architecture Review AssistantA concrete reference pattern showing how governed assistant design uses sources, controls, evidence states, evals, and human review.
Why the map matters: these 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.
2. What should I read first?
I am new to the playbookStart here, then read Shared Capability Foundations to learn the common terms.
I need the mental modelRead AI Capability Discipline after you understand the map and shared vocabulary.
I need build-readiness disciplineRead MLL WESS when work may need capacity, preflight, contractor effort, Jira commitment, or operating support.
I need a reference implementationRead the Enterprise Architecture Review Assistant to see the discipline applied to governed assistant architecture.
I need communication assetsUse Prompt Packs when the job is explanation, rendering, or stakeholder communication.
I need package boundariesUse this map to keep shared terms shared and local decision rights local.
3. Artifact-to-decision matrix
| Artifact | Use it to 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. |
4. What stays shared and what stays local
| 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. |
| Keep local | Package | Reason |
|---|---|---|
| WESS decision rights and preflight thresholds | MLL WESS | They depend on local capacity, service ownership, contractor use, and Jira behavior. |
| EA 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. |
5. 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. |
6. 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.