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. Start Here reader paths
Executive or sponsorFirst: Playbook Map.Next: AI Capability Discipline executive sections and audience briefs.Helps answer whether AI should be used, 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 architectFirst: Shared Capability Foundations.Next: AI Capability Discipline, then Enterprise Architecture Review Assistant.Helps identify missing source authority, evidence, schema, eval, review, and sustainment controls.Does not approve architecture decisions, data classes, workflow exceptions, or production readiness.
Governance, risk, or compliance reviewerFirst: AI Capability Discipline policy-boundary and provenance sections.Next: grounding rules, claim posture, source maps, and receipts.Helps separate field guidance, owner validation, and formal review needs.Does not approve company policy, regulated use, security posture, privacy posture, or data movement.
Product or platform ownerFirst: Playbook Map.Next: MLL WESS and product-architecture notes.Helps classify 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 leadFirst: Shared Capability Foundations.Next: MLL WESS, Enterprise Architecture Review Assistant, and validation receipts.Helps identify contracts, evals, telemetry, review loops, and package checks before build commitment.Does not approve runtime behavior, provider calls, connector ingestion, private-data workflow, or enterprise integration.
Practitioner or learnerFirst: AI Capability Discipline.Next: Shared Capability Foundations and worked examples.Helps explain why prompts, agents, evals, and demos are only components.Does not approve any AI tool, data class, workflow, or production process.
Assistant or AI-consumable package userFirst: context-pack manifest and grounding rules.Next: source map, glossary, sections, claims, and source-grounded explainer notes.Helps identify which package sources may ground future Find, Explain, or Assess answers and where cited answers should 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.
3. 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. |
4. 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. |
5. 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. |
6. 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. |
7. 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.