## Asset Header

- **Asset ID:** MePB-BMF-MetaPlaybook-Of-MetaPlaybooks-v01
- **Version:** v01
- **Status:** Draft
- **Owner:** Victor Heredia
- **IntellBank:** IB-XX-Maestro
- **Tipo:** MePB — MetaPlaybook
- **Propósito:** MetaPlaybook of MetaPlaybooks — Taxonomy, Inheritance, and Governance v0.1
- **Última actualización:** 2026-04-11

---

# MetaPlaybook of MetaPlaybooks — Taxonomy, Inheritance, and Governance v0.1

## 0. Human Introduction and Index

### 0.1 Human Introduction

This MetaPlaybook defines the **taxonomy, boundaries, inheritance rules, and interfaces** for all MetaPlaybooks in the ecosystem. Its job is to prevent duplication and drift by making it unambiguous:

- What kinds of MetaPlaybooks exist
- What each kind is allowed to contain
- What layer it belongs to (L0–L4)
- What it can and cannot modify
- What it must inherit from the Big MetaFactory Kernel

This is builder-grade documentation. It is a classification and governance specification — not an execution guide.

### 0.2 Index

1. Orientation
2. Canonical Definitions and Classification
3. MetaPlaybook Types (Taxonomy)
4. Inheritance and Override Rules
5. Required Sections (Per Type)
6. QA and Promotion Rules (For MetaPlaybooks)
7. Control Plane for MetaPlaybooks
8. Interoperability (References and Interfaces)
9. Anti-Patterns
10. Boundaries and Out-of-Scope
11. Appendices

---

## 0. Asset Header

### 0.1 Asset ID

MPB-OF-MPB-MetaPlaybookOfMetaPlaybooks-v01

### 0.2 Title

MetaPlaybook of MetaPlaybooks — Taxonomy, Inheritance, and Governance

### 0.3 Version

v0.1

### 0.4 Status

Draft (Skeleton)

### 0.5 Owner

Victor Heredia

### 0.6 Project Class

BIG METAFACTORY (L0.5)

### 0.7 Purpose

Define the classification system for MetaPlaybooks, including what each type must contain, what it is forbidden to contain, and how MetaPlaybooks inherit from the Big MetaFactory Kernel.

### 0.8 Scope

**In scope:**
- MetaPlaybook types and their boundaries
- Inheritance and override rules
- Required sections per type
- QA and promotion standards for MetaPlaybooks
- Control Plane registries for MetaPlaybooks

**Out of scope:**
- Building factories (belongs to MetaPlaybook Builder)
- Operating specific factories (belongs to Ops playbooks)
- Producing market assets (belongs to Production playbooks)

### 0.9 Non-Negotiables

- Builder-grade language (no marketing)
- Layer separation enforced
- Inheritance from the kernel is explicit
- QA can fail (PASS/FAIL)
- Everything is auditable and versioned
- Use H2/H3/H4 only (no H1)

---

## 1. Orientation

### 1.1 Why a MetaPlaybook Taxonomy Exists

Without a classification system, every team creates its own "playbook style" — some are constitutional, some are how-to guides, some are strategic frameworks, some are checklists. These all get called "playbooks" but they perform completely different governance functions. The result is duplication (multiple documents saying the same thing in different places), conflicting definitions (two playbooks use "station" to mean different things), and governance leakage (tactical instructions appear in constitutional documents, diluting their authority).

A MetaPlaybook taxonomy eliminates these problems by assigning each document a **type** that determines its purpose, allowed content, required sections, authority level, and inheritance obligations. When someone creates a new MetaPlaybook, they are not writing a document — they are instantiating a class. The class determines the structure.

### 1.2 What a MetaPlaybook Is

A MetaPlaybook is a **canonical operating constraint system at a defined layer**. It is not documentation in the conventional sense. Its job is to shape future behavior — to make certain actions required, certain actions forbidden, and certain outcomes predictable — across any operator, session, or team that engages with the system.

A MetaPlaybook does this through four mechanisms:
1. **Definitions:** Canonical terms that override informal usage
2. **Invariants:** Rules that cannot be violated without invalidating the work product
3. **Protocols:** Repeatable procedures for specific situations (building, QA, promotion, deprecation)
4. **Artifact contracts:** Declared inputs and outputs that enable interoperability

A document that does not include at least some of these mechanisms is documentation, not a MetaPlaybook.

### 1.3 Relationship to the Kernel (L0)

The Big MetaFactory Kernel defines the global laws of the ecosystem. Every MetaPlaybook, regardless of type, must:
1. Explicitly declare which Kernel section(s) it inherits from
2. Comply with all seven global invariants (INV-01 through INV-07)
3. Not redefine any canonical term from the Kernel without authority approval and a ChangeLog entry
4. Not override Track A/B policy, QA binary rule, or authority discipline
5. Include a pointer to the Kernel as the highest authority in any conflict

The Kernel wins in all conflicts with lower-layer MetaPlaybooks. If a Type D (Domain MetaFactory) MetaPlaybook defines a term differently from the Kernel, the Kernel's definition applies. The Type D MetaPlaybook must be updated.

---

## 2. Canonical Definitions and Classification

### 2.1 Canonical Term: MetaPlaybook

A MetaPlaybook is a **governed, versioned constraint document** assigned to a specific layer and type. It constrains behavior at its layer through definitions, invariants, protocols, and artifact contracts. It does not describe what people already do — it prescribes what they must do and what they must not do.

A MetaPlaybook is NOT:
- A tutorial or how-to guide (those are Production or Ops documents)
- A project plan (those are Ops-level run plans)
- A collection of prompts (those are implementation tools, not governance)
- A slide deck or executive summary (those are communication artifacts, not constraint systems)

### 2.2 Classification Axes

Every MetaPlaybook must be classifiable along five axes. Ambiguity on any axis is a structural defect that must be resolved before the MetaPlaybook can advance beyond Draft status.

**Layer (L0–L4):** The layer of the Big MetaFactory architecture where this MetaPlaybook has authority. L0 governs all; L4 is governed by all above it. A MetaPlaybook cannot have authority at multiple layers — if it does, it must be split.

**Domain (Publishing / Consulting / HR / etc.):** The specific domain this MetaPlaybook applies to, or "Ecosystem" if it applies globally (as L0 does). Domain-specific MetaPlaybooks may not impose rules on other domains.

**Function (Kernel / Builder / MetaFactory / Ops / Production):** The functional role this MetaPlaybook plays. Function determines which Type (A–F) the MetaPlaybook belongs to.

**Audience (Architect / Operator / Publisher):** The primary user of this MetaPlaybook. Audience determines writing style and level of abstraction. Architects work with laws and interfaces; operators work with procedures and checklists; publishers work with templates and output specs.

**Risk level (Low / Medium / High):** The risk of incorrect use. High-risk MetaPlaybooks (e.g., Kernel documents) require more rigorous QA and promotion gates. Low-risk MetaPlaybooks (e.g., specific format templates) may be promoted faster.

---

## 3. MetaPlaybook Types (Taxonomy)

### 3.1 Type A — Kernel MetaPlaybook (L0)

A Type A MetaPlaybook is the **constitutional law of the ecosystem**. There is exactly one Type A MetaPlaybook: the Big MetaFactory Kernel. It defines everything that all other MetaPlaybooks must comply with.

**Allowed content:**
- Canonical definitions that override all layers
- Global invariants (the "must never break" rules)
- The layer model and allowed relationships
- Governance and authority model
- QA philosophy at ecosystem level
- Evolution, promotion, and deprecation rules
- Control Plane model (macro level)
- Interoperability contracts
- Anti-patterns and failure modes

**Forbidden content:**
- Step-by-step procedures for any specific task
- Domain-specific rules or exceptions
- Tooling or implementation specifications
- Marketing, sales, or publishing tactics

**Required sections:** Asset Header, Layer Model, Invariants, Governance Model, QA Philosophy, Evolution Rules, Control Plane, Anti-Patterns, Boundaries.

**Authority:** Highest. Cannot be overridden by any other MetaPlaybook.

### 3.2 Type B — Taxonomy MetaPlaybook (L0.5)

A Type B MetaPlaybook defines the **classification and inheritance rules for MetaPlaybooks themselves**. This document is the sole Type B MetaPlaybook. It sits at L0.5 — below the Kernel but above all builder and domain MetaPlaybooks.

**Allowed content:**
- MetaPlaybook type definitions and boundaries
- Classification axes (Layer, Domain, Function, Audience, Risk)
- Inheritance and override rules
- Required sections per type
- QA and promotion standards for MetaPlaybooks
- Control Plane for MetaPlaybook registry

**Forbidden content:**
- Building or operating factories
- Domain-specific content
- Execution procedures

**Authority:** Below Kernel (L0). Governs how all other MetaPlaybooks are structured and classified.

### 3.3 Type C — Builder MetaPlaybook (L1)

A Type C MetaPlaybook defines the **protocols and artifacts** used to build and validate MetaFactories, Templates, and other MetaPlaybooks. The primary Type C is the MetaFactory Builder MetaPlaybook.

**Allowed content:**
- Build lifecycle definitions (phases, gates, required outputs per phase)
- Required sections for the artifact type being built (e.g., required sections for Type D MetaPlaybooks)
- Delegation contracts and interfaces
- Structural and semantic QA gates (machine-readable)
- Promotion and release protocols
- Control Plane hooks for built artifacts
- Anti-patterns specific to the build process

**Forbidden content:**
- Domain-specific content (which factories or industries to build in)
- Execution or operating procedures
- Production or publishing tactics
- Market-facing content

**Authority:** Below Kernel and Taxonomy. Governs how MetaFactories and Templates are created. Does not govern how they are operated.

### 3.4 Type D — Domain MetaFactory MetaPlaybook (L2)

A Type D MetaPlaybook is the **constitutional blueprint for a Domain MetaFactory**. One Type D exists per domain (AI Publishing, Consulting, HR, Coaching, etc.). It defines the domain's factory architecture without specifying how operators run factories day-to-day.

**Allowed content:**
- Domain declaration (name, scope, in/out of scope)
- Explicit inheritance stack (which L0/L1 rules this domain inherits)
- Station archetypes (names, purposes, required inputs/outputs)
- Artifact registry (artifact types produced in this domain)
- Module registry (configurable components for domain factories)
- Template registry (references to domain-specific templates)
- Delegation contracts to Factory Builders
- QA model extensions for the domain
- Control Plane hooks

**Forbidden content:**
- Step-by-step execution procedures
- Prompts, instructions, or tactics
- Run cadence, WIP rules, defect handling (those belong to L3)
- Packaging or marketing specifics (those belong to L4)

**Authority:** Below L0, L0.5, L1. Governs all L3 instances in its domain.

### 3.5 Type E — Operations MetaPlaybook (L3)

A Type E MetaPlaybook defines how to **run a specific factory instance reliably**: how to execute runs, manage WIP, handle defects, log results, and maintain quality through repetition.

**Allowed content:**
- Run cadence and scheduling
- Station-level operating procedures (how operators work each station)
- WIP limits and stop-the-line triggers
- Defect handling procedures
- QA checklists per station
- Role definitions and responsibilities
- Logging and reporting templates
- Daily/weekly rituals

**Forbidden content:**
- Domain architecture (those belong to L2)
- Template creation or modification (those belong to L1)
- Market-facing content or publishing decisions (those belong to L4)

**Authority:** Below L0–L2. Governs a specific factory instance or family of instances.

### 3.6 Type F — Production MetaPlaybook (L4)

A Type F MetaPlaybook defines how to **produce specific market-facing output types** within the constraints set by all upper layers.

**Allowed content:**
- Output format specifications
- Voice and style guidelines (Writer OS profiles)
- Content structure templates
- Packaging and delivery instructions
- Platform-specific formatting rules
- Launch and distribution protocols

**Forbidden content:**
- Governance or architecture definitions (those belong to L0–L2)
- Factory design or template creation (those belong to L1)
- Operating procedures (those belong to L3)

**Authority:** Below all upper layers. Governs how specific assets are produced. May not modify governance.

---

## 4. Inheritance and Override Rules

### 4.1 Inheritance Stack

The inheritance stack flows strictly from higher layers to lower layers. Each MetaPlaybook inherits all invariants and constraints from every layer above it.

```
L0   → Type A (Kernel MetaPlaybook)            — establishes all global laws
L0.5 → Type B (Taxonomy MetaPlaybook)           — inherits L0; classifies all MPBs
L1   → Type C (Builder MetaPlaybook)             — inherits L0, L0.5
L2   → Type D (Domain MetaFactory MetaPlaybook)  — inherits L0, L0.5, L1
L3   → Type E (Operations MetaPlaybook)          — inherits L0, L0.5, L1, L2
L4   → Type F (Production MetaPlaybook)          — inherits L0, L0.5, L1, L2, L3
```

Every MetaPlaybook must declare its inheritance stack explicitly in its Asset Header or Orientation section. Undeclared inheritance is considered non-compliant.

### 4.2 Override Policy

Overrides are rare, explicit, and governed. The default assumption is that higher-layer rules apply without modification.

**What can be overridden:**
- Domain-specific terminology (a Type D may define terms that are specific to its domain, provided they do not conflict with Kernel terms)
- Format preferences at L3/L4 (an Ops or Production MetaPlaybook may specify formatting conventions that are more specific than what L2 defines)
- Module configurations (the specific Writer OS profile, format profile, or agent selection is always overridable)

**What can NEVER be overridden (invariants from INV-01 through INV-07):**
- The requirement for a named pipeline with stations
- Control Plane auditability of all runs
- Binary QA (PASS/FAIL only)
- Authority discipline
- WIP limits
- Asset identity requirements
- Track A/B discipline

Any MetaPlaybook that attempts to override an invariant is structurally invalid and must be rejected at QA.

### 4.3 Conflict Resolution

When two MetaPlaybooks conflict, the resolution is deterministic: **the higher layer wins**.

Resolution order (highest to lowest authority):
1. L0 Kernel
2. L0.5 Taxonomy (this document)
3. L1 Builder MetaPlaybook
4. L2 Domain MetaFactory MetaPlaybook
5. L3 Operations MetaPlaybook
6. L4 Production MetaPlaybook

If two MetaPlaybooks at the same layer conflict, the conflict must be escalated to the layer above for resolution. Same-layer conflicts cannot be self-resolved — doing so creates circular authority.

When a conflict is discovered, the lower-layer MetaPlaybook must be updated to comply with the higher-layer authority. The update is documented in the ChangeLog of both the updated document and the Control Plane.

---

## 5. Required Sections (Per Type)

### 5.1 Universal Required Sections

Every MetaPlaybook, regardless of type, must include the following sections. Absence of any required section causes QA FAIL.

1. **Asset Header:** ID, Title, Version, Status, Owner, Project Class, Purpose, Scope (in/out), Non-Negotiables.
2. **Orientation:** What this MetaPlaybook is, what it is not, and why it exists.
3. **Canonical Definitions:** Key terms used in this MetaPlaybook, with explicit notation if they override or extend Kernel definitions.
4. **Scope and Boundaries:** Explicit in-scope and out-of-scope with references to which other MetaPlaybooks own the out-of-scope items.
5. **QA Standard:** The specific QA criteria for this MetaPlaybook's outputs, or a pointer to the governing QA standard.
6. **Control Plane Pointers:** References to which registries track the artifacts governed by this MetaPlaybook.
7. **Inheritance Declaration:** Which MetaPlaybooks at higher layers this document inherits from, and any explicit constraints inherited.

### 5.2 Type-Specific Required Sections

In addition to universal sections, each type has required sections that reflect its specific governance function.

**Type A (Kernel):** Layer model, Global invariants (explicit list), Governance and authority model by layer, Evolution and deprecation rules, Control Plane macro model.

**Type B (Taxonomy):** MetaPlaybook type taxonomy (all types defined), Classification axes, Inheritance stack, Override policy, Conflict resolution.

**Type C (Builder):** Build lifecycle (phases and gates), Required artifact sections for each artifact type built, QA tables (structural + semantic, machine-readable), Delegation contracts, Promotion states.

**Type D (Domain MetaFactory):** Domain declaration (name + scope), Station architecture (archetypes with required fields), Artifact registry, Module registry, Template registry, Delegation contracts to Factory Builder.

**Type E (Operations):** Run cadence, Station procedures, WIP limits and stop-the-line triggers, Defect handling, Role definitions, Logging templates.

**Type F (Production):** Output format specifications, Voice/style guidelines, Content structure templates, Packaging and delivery instructions.

---

## 6. QA and Promotion Rules (For MetaPlaybooks)

### 6.1 QA Hard Gate for MetaPlaybooks

MetaPlaybooks govern behavior — which means they must be QA'd with the same rigor as any production output. A MetaPlaybook that has not passed QA is a Draft and may not be used as an authoritative reference.

The QA hard gate for MetaPlaybooks checks two categories:

**Structural QA (can be verified by inspection):**
- All universal required sections are present
- All type-specific required sections are present
- Asset Header is complete with all mandatory fields
- Inheritance stack is explicitly declared
- Scope and out-of-scope are both defined

**Semantic QA (requires judgment):**
- No cross-layer leakage (e.g., execution procedures in a Kernel document)
- Definitions do not conflict with higher-layer canonical terms
- Invariants are stated as absolutes (no hedging language like "usually" or "in most cases")
- Forbidden content categories are respected
- Override claims are explicit and justified

Any single FAIL in either category blocks promotion.

### 6.2 DoD for MetaPlaybooks

A MetaPlaybook is considered "Done" when it is **trainable and enforceable**:

**Trainable:** A qualified person who reads this MetaPlaybook can understand what they must do and what they must not do at this layer without needing to ask clarifying questions. If they need to ask questions, the MetaPlaybook is incomplete.

**Enforceable:** The rules in this MetaPlaybook can produce PASS or FAIL decisions on real work. If a rule cannot be applied to a concrete piece of work and produce a binary result, the rule is either too vague to be a rule or it belongs in guidance documentation, not a MetaPlaybook.

### 6.3 Promotion States

MetaPlaybooks follow the same promotion states as all assets in the ecosystem, with additional checkpoints specific to governance documents.

**Draft:** Under development. May be shared for review. May not be cited as authoritative.

**QA_Pass:** Has passed both structural and semantic QA. May be used operationally. Other MetaPlaybooks may reference it.

**Hardened:** Has been applied in at least one real governance context (e.g., used to evaluate another MetaPlaybook, used to govern a factory instance) without producing ambiguity or requiring improvisation.

**Canonical:** Recognized as the authoritative reference for its type and layer. Changes require full ChangeLog protocol and authority approval. Lower-layer MetaPlaybooks must comply.

Promotion sequence is **strictly linear**: Draft → QA_Pass → Hardened → Canonical. No skipping. No reversal except under formal deprecation.

---

## 7. Control Plane for MetaPlaybooks

### 7.1 MetaPlaybook Registry

All MetaPlaybooks in the ecosystem are tracked in the MetaPlaybook Registry, which is part of the Control Plane. The registry is the authoritative list of what MetaPlaybooks exist, what their current status is, and where they live.

**Required fields for each registry entry:**

| Field | Description |
|---|---|
| Asset ID | Unique identifier (= filename without extension) |
| Type | A through F |
| Layer | L0 through L4 |
| Domain | Ecosystem / Publishing / Consulting / etc. |
| Version | Current version (vN.N) |
| Status | Draft / QA_Pass / Hardened / Canonical |
| Owner | Person responsible for this MetaPlaybook |
| Inherits From | List of higher-layer MetaPlaybooks this one inherits |
| Governs | What this MetaPlaybook has authority over |
| Last QA Date | Date of most recent QA gate pass |
| Location | File path or wiki link |

A MetaPlaybook that is not in the Registry does not exist for governance purposes. Creating a MetaPlaybook without registering it is the same as creating an orphan asset — it violates INV-06 (Asset Identity Required).

### 7.2 ChangeLog Policy

Every change to a MetaPlaybook — including minor edits that do not affect meaning — must be recorded. MetaPlaybooks that govern others must themselves be auditable.

**ChangeLog entry required fields:**
- Date
- Version (before and after)
- Change type (Track A or Track B)
- Changed section(s)
- Summary of what changed and why
- Authority who approved (for Track A)
- Impact on dependent MetaPlaybooks (if any)

ChangeLog entries are append-only. Previous entries are never modified or deleted. The ChangeLog lives at the end of the MetaPlaybook document.

---

## 8. Interoperability (References and Interfaces)

### 8.1 Allowed References

MetaPlaybooks may reference other MetaPlaybooks at higher or equal layers. References create explicit dependencies that must be maintained when either document is updated.

**Allowed reference directions:**
- A MetaPlaybook may reference higher-layer MetaPlaybooks (inheritance references)
- A MetaPlaybook may reference equal-layer MetaPlaybooks in the same domain for cross-references
- A MetaPlaybook may reference lower-layer MetaPlaybooks only as pointers ("this topic belongs to L3 — see [MPB-ID]")

**Forbidden reference patterns:**
- Circular references: A references B, B references A as an authority. Circular authority is undefined — it must be resolved by declaring which one governs the other.
- Forward authority: A lower-layer MetaPlaybook citing a higher-layer document as evidence for an override. The lower layer must comply; it cannot use the higher layer's authority to justify deviating from the higher layer.

### 8.2 Interface Contracts

MetaPlaybooks interoperate through **declared interfaces** — explicit statements of what artifact a MetaPlaybook produces that other MetaPlaybooks consume.

Every MetaPlaybook that produces artifacts consumed by other layers must declare:
- The artifact type produced (e.g., "Type D MetaPlaybook skeleton")
- The required fields in that artifact
- The version schema
- Which MetaPlaybook(s) consume it

This prevents hidden dependencies — situations where a change to one MetaPlaybook breaks another MetaPlaybook because the dependency was never documented.

---

## 9. Anti-Patterns

### 9.1 MetaPlaybook Sprawl

**Pattern:** New MetaPlaybooks are created for every project, every client, and every new idea. After six months, the ecosystem has 40 MetaPlaybooks, most of them overlapping, many of them contradicting each other.

**Why it fails:** MetaPlaybooks are governance artifacts, not working documents. Creating too many makes the governance system ungovernable. Operators cannot determine which MetaPlaybook applies to their situation. Contradictions multiply. Maintenance cost becomes prohibitive.

**The cure:** Before creating a new MetaPlaybook, check whether an existing one of the same type and layer already covers the domain. If it does, extend or update the existing one rather than creating a parallel document. If it does not, register the new MetaPlaybook immediately upon creation.

### 9.2 Cross-Layer Leakage

**Pattern:** A Kernel document (Type A, L0) accumulates how-to instructions because they are convenient to include. A Domain MetaFactory document (Type D, L2) starts specifying day-to-day operating procedures. A Production MetaPlaybook (Type F, L4) starts making claims about factory architecture.

**Why it fails:** Each MetaPlaybook type has its specific governance function. When content from a lower layer contaminates a higher-layer document, the higher-layer document becomes harder to maintain (it changes at two different cadences) and loses authority (readers cannot determine which sections are constitutional and which are tactical).

**The cure:** Every section of every MetaPlaybook must pass the type-appropriateness test: "Does this content belong at this layer?" If the answer is no, move the content to the correct layer and add a pointer ("See [MPB-ID] for execution procedures").

### 9.3 Un-QA'd Governance

**Pattern:** MetaPlaybooks are written and immediately treated as canonical. They are cited in other documents, used to make decisions, and referenced in training materials — all without passing a QA gate.

**Why it fails:** Governance that has not been QA'd may contain contradictions, undefined terms, unenforced invariants, or scope leakage. When people cite these documents as authoritative and the documents are flawed, the flaws propagate throughout the ecosystem. Fixing the original document does not automatically fix all the decisions made under it.

**The cure:** All MetaPlaybooks must pass QA before being cited as authoritative. Draft MetaPlaybooks may be used provisionally with explicit notation that they have not yet achieved QA_Pass status.

---

## 10. Boundaries and Out-of-Scope

### 10.1 What This MetaPlaybook Does Not Do

This playbook defines classification and inheritance only. It does not:
- Provide step-by-step instructions for building factories (that belongs to the Type C Builder MetaPlaybook)
- Define the content that factories should produce (that belongs to L2 Type D MetaPlaybooks)
- Specify how factories are operated (that belongs to L3 Type E MetaPlaybooks)
- Describe what market-facing outputs look like (that belongs to L4 Type F MetaPlaybooks)

### 10.2 Where Those Topics Belong

| Topic | Where It Belongs |
|---|---|
| How to build a factory | Type C Builder MetaPlaybook (L1) |
| What a specific domain's factories look like | Type D Domain MetaFactory MetaPlaybook (L2) |
| How to run a factory instance | Type E Operations MetaPlaybook (L3) |
| How to produce a specific content format | Type F Production MetaPlaybook (L4) |
| What the ecosystem's global laws are | Type A Kernel MetaPlaybook (L0) |

---

## 11. Appendices

### 11.1 MetaPlaybook Type Cards (Quick Reference)

| Type | Name | Layer | Governs | Primary Audience |
|---|---|---|---|---|
| A | Kernel MetaPlaybook | L0 | Entire ecosystem | System Architect |
| B | Taxonomy MetaPlaybook | L0.5 | All MetaPlaybooks | System Architect |
| C | Builder MetaPlaybook | L1 | MetaFactory/Template creation | MetaFactory Architect |
| D | Domain MetaFactory MetaPlaybook | L2 | Domain factory families | Domain Owner |
| E | Operations MetaPlaybook | L3 | Running factory instances | Factory Operator |
| F | Production MetaPlaybook | L4 | Asset production | Content Producer |

### 11.2 MetaPlaybook Creation Checklist (Pointer)

The creation of a new MetaPlaybook is governed by the Type C Builder MetaPlaybook. Before creating any new MetaPlaybook:

1. Confirm the type (A–F) using the taxonomy in Section 3
2. Verify no existing MetaPlaybook at the same type and layer already covers the domain
3. Declare the full inheritance stack
4. Use the type-specific required sections (Section 5.2) as the document skeleton
5. Register the new MetaPlaybook in Draft status in the MetaPlaybook Registry before sharing it
6. Do not cite it as authoritative until it achieves QA_Pass status

### 11.3 Glossary Expansion Protocol (Reference)

New terms specific to MetaPlaybook governance follow the Kernel's Glossary Expansion Protocol (see BMF-MPB-Kernel-v01, Section 12.2). Terms proposed in this document that are not yet in the Kernel must be flagged as "Proposed — pending Kernel incorporation" until they are formally added.

---

*Asset ID: MPB-OF-MPB-MetaPlaybookOfMetaPlaybooks-v01 | Version: v0.1 | Status: Draft | Owner: Victor Heredia*