## Asset Header

- **Asset ID:** ARQ-XX-BMF-MPB-Kernel-v01
- **Version:** v01
- **Status:** Draft
- **Owner:** Victor Heredia
- **IntellBank:** IB-XX-Maestro
- **Tipo:** ARQ — Architecture
- **Propósito:** Big Meta Factory Meta Playbook — Kernel v0.1
- **Última actualización:** 2026-04-11

---

# Big Meta Factory Meta Playbook — Kernel v0.1

## 0. Human Introduction and Index

### 0.1 Human Introduction

This MetaPlaybook is the **kernel** of the Big MetaFactory: a constitutional, builder-grade manual that governs a system of MetaFactories. Its job is to keep the ecosystem coherent under scale by defining the hierarchy of layers, the minimal invariants that must not break, and the governance rules that prevent scope contamination.

This document does **not** teach execution workflows. It defines *where* execution belongs and *what must be true* for any factory or MetaFactory to be considered valid.

### 0.2 Index

1. Orientation
2. Canonical Definitions (Overrides)
3. Layered Architecture (L0–L4)
4. Ecosystem Invariants (Global Laws)
5. Governance and Authority Model
6. QA Philosophy at System Level
7. Evolution and Promotion Rules
8. Control Plane (Ecosystem Observability)
9. Interoperability and Interfaces
10. Anti-Patterns (Ecosystem Failure Modes)
11. Boundaries and Out-of-Scope
12. Appendices

---

## 0. Asset Header

### 0.1 Asset ID

BMF-MPB-Kernel-v01

### 0.2 Title

Big MetaFactory MetaPlaybook — Ecosystem Kernel (System of MetaFactories)

### 0.3 Version

v0.1

### 0.4 Status

Draft (Skeleton)

### 0.5 Owner

Victor Heredia

### 0.6 Project Class

BIG METAFACTORY (L0)

### 0.7 Purpose

Define the constitutional structure, invariants, governance, and evolution rules for the Big MetaFactory: a system that builds and governs many MetaFactories and their instances.

### 0.8 Scope

**In scope:**
- Canonical definitions that override all lower layers
- Layer model (L0–L4) and allowed relationships
- Global invariants (what must never break)
- Governance + authority rules across layers
- System-level QA philosophy and promotion rules
- Ecosystem observability (Control Plane at macro level)
- Interoperability rules (interfaces between factories)

**Out of scope:**
- How to operate a specific MetaFactory (belongs to L2)
- How to run a Factory Instance day-to-day (belongs to L3)
- How to produce books/playbooks/assets (belongs to L4)

### 0.9 Non-Negotiables

- Builder-grade language (no marketing)
- Layer separation is enforced
- Invariants are explicit and minimal
- Everything must be auditable and transferable
- Use H2/H3/H4 only (no H1)

---

## 1. Orientation

### 1.1 What the Big MetaFactory Is

The Big MetaFactory is a **system for manufacturing and governing MetaFactories**. It is not a single factory. It is the architecture that makes it possible to create, operate, and replicate many factories without each one becoming a bespoke project with unique rules, fragile prompts, and hero-operator dependencies.

Think of it as the governance layer above all production. The Big MetaFactory does not produce books, playbooks, or diagnostics — those are produced by factories inside it. The Big MetaFactory produces the **conditions under which factories can exist reliably**.

A Big MetaFactory exists when: (a) factories can be added without breaking other factories, (b) every factory operates under the same governance laws, and (c) the system can be transferred to operators who were not present at its design.

### 1.2 What This MetaPlaybook Is (and Is Not)

This MetaPlaybook is the **ecosystem's constitution**. It defines structure, laws, and interfaces. It does not teach execution.

It does NOT contain:
- Step-by-step how-to instructions for running factories
- Writing prompts, content templates, or publishing tactics
- Project management procedures for specific teams

It DOES contain:
- The layer model and what each layer is responsible for
- The invariants that every factory, instance, and asset must respect
- The governance and authority model that resolves conflicts
- The rules for adding new MetaFactories to the ecosystem
- The interfaces through which factories communicate

Reading this document gives an architect a complete mental model of how the ecosystem is structured. Reading it does not tell them how to run Tuesday's production cycle — that belongs to L3.

### 1.3 Why a Kernel Is Necessary

Without a kernel, every new factory reinvents its own definitions and governance rules. Over time:
- "Factory" means different things in different parts of the system
- QA standards diverge until some gates are enforced and others are advisory
- New team members cannot navigate the ecosystem without a guide who explains the implicit rules
- Conflicts between layers have no resolution mechanism — whoever is loudest wins

The kernel eliminates these failure modes by establishing one authoritative source of definitions, one layer model, and one conflict resolution policy. It is the minimum structure required for the system to remain coherent as it scales.

### 1.4 The Three Project Classes (Scope Firewall)

All work in the ecosystem belongs to exactly one of three project classes. Confusion disappears when these are explicit.

**Builder (Meta level):**
Work that designs or modifies the architecture itself — layers, invariants, templates, MetaPlaybooks, Factory Builders. Builder work produces governance artifacts, not market-facing content. Audience: architects and system stewards.

**Operations (Instance level):**
Work that runs a specific factory instance according to its governing MetaPlaybook — executing runs, logging, QA cycles, defect handling. Operations work produces run logs, QA results, and operational assets. Audience: operators.

**Production (Asset level):**
Work that produces market-facing outputs inside a running factory — books, playbooks, diagnostics, reports, content. Production work delivers assets with IDs, versions, and QA stamps. Audience: publishers and end clients.

**Rule:** No work product may belong to more than one class. When in doubt, assign the class and restrict scope accordingly. Cross-class contamination is an architectural defect.

---

## 2. Canonical Definitions (Overrides)

### 2.1 Core Terms

The following definitions are **authoritative**. If any lower-layer playbook uses a term differently, this section overrides it. Disputes are resolved by referring to this section; if this section is unclear, the kernel must be updated.

**Big MetaFactory:** The complete system of MetaFactories, governed by this kernel. It exists as an architecture, not as any single session or document.

**MetaFactory:** A governed family of factories within a defined domain (e.g., AI Publishing, Consulting, HR). A MetaFactory defines station archetypes, artifact contracts, module registries, and delegation rules — it does not run factories directly.

**Factory Builder:** The system (person, team, or AI-assisted process) responsible for instantiating concrete factory templates from MetaFactory blueprints. Factory Builders operate at L1; they build factories, they do not define domain laws.

**Template:** A reusable, versioned factory blueprint that has passed QA and can be instantiated to create a Factory Instance. Templates live at L1/L2 and must be registered in the Control Plane.

**Instance:** A running factory — a specific deployment of a Template for a specific domain, client, or purpose. Instances execute runs and produce assets. They live at L3.

**Asset:** Any output produced by a Factory Instance — books, playbooks, diagnostics, reports, cards, newsletters. Assets must carry: Asset ID, version, owner, status, and QA result.

**Station:** A defined processing step within a factory pipeline. Each station has a name, purpose, required inputs, required outputs, and a QA gate. Stations are archetypes at L2; they become concrete steps at L3.

**Run:** A single execution cycle through a factory pipeline, from the first station to the last. Runs must be logged with a Run_ID, operator, date, outputs produced, and QA result.

**Defect:** A failure to meet the Definition of Done at any station gate. Defects are classified by severity (Critical, Major, Minor) and resolved through patch-only repair, never through redefinition.

**Change:** Any modification to a Template, MetaPlaybook, or factory definition. Changes require a version bump, ChangeLog entry, and authority approval from the governing layer.

**Control Plane:** The registry and logging system that tracks the state of all MetaFactories, Templates, Instances, and Assets across the ecosystem. The Control Plane is the single source of truth. If it is not in the Control Plane, it does not exist.

**Invariant:** A rule that cannot be broken under any circumstances at any layer. Invariants are few, absolute, and explicitly enumerated. If a rule allows exceptions, it is not an invariant — it is a module or policy.

**Module:** A configurable component of a factory that can vary across instances without breaking ecosystem integrity. Modules are replaceable; invariants are not.

### 2.2 Definition Discipline

Definitions must meet four criteria: (1) short enough to state in two sentences, (2) operational — the definition enables a decision, (3) enforceable — a QA check can verify compliance, and (4) stable under pressure — the definition does not bend when execution becomes inconvenient.

If a proposed definition fails any of these four criteria, it is not ready to be canonical. Draft it, test it against edge cases, then promote it.

---

## 3. Layered Architecture (L0–L4)

### 3.1 Layer Model

The Big MetaFactory uses a five-layer architecture. Each layer has a single job. Mixing responsibilities between layers creates architectural debt that compounds over time.

**L0 — Big MetaFactory Kernel (this document):**
The constitution of the ecosystem. Defines global laws, canonical terms, the layer model itself, invariants, governance authority, and interoperability contracts. L0 governs all other layers. Nothing in L1–L4 may contradict L0.

**L1 — Factory Builder:**
The system for creating and validating factory templates and MetaPlaybooks. L1 defines protocols and schemas for building L2 MetaFactories and L3 instance kickoffs. L1 produces artifacts that other layers consume — it does not produce market-facing outputs.

**L2 — MetaFactories (Domain Families):**
Each L2 MetaFactory governs a domain (AI Publishing, Consulting, HR, Coaching, etc.). L2 defines station archetypes, artifact contracts, module registries, and delegation rules for all factories in that domain. L2 does not run factories — it defines what factories in its domain must look like.

**L3 — Factory Operations:**
The execution layer. L3 contains running Factory Instances — specific deployments of L2 templates for specific purposes or clients. L3 operators execute runs, manage WIP, log results, handle defects, and enforce QA gates. L3 must follow the rules defined at L2 and above.

**L4 — Production Lines:**
The output layer. L4 is where market-facing assets are produced — books, playbooks, diagnostics, newsletters, cards, reports. L4 assets are produced by L3 instances, governed by L2 standards, audited by the L0/L1 Control Plane. L4 does not invent rules; it follows them.

### 3.2 Allowed Relationships

Higher layers govern; lower layers execute. The allowed flow of authority is strictly top-down:

- L0 governs L1–L4: all layers must comply with kernel invariants
- L1 manufactures L2 templates and L3 instance kickoffs: the Factory Builder produces the blueprints that L2 and L3 use
- L2 governs families of L3 instances: each MetaFactory defines the operating rules for its factory instances
- L3 produces L4 assets: only running Factory Instances produce market-facing outputs

The allowed flow of information is bottom-up for *reporting only*:
- L3 logs run data into the Control Plane (L0 observability)
- L4 asset quality feeds back into L2 QA standards through the ChangeLog protocol

### 3.3 Prohibited Relationships

Some shortcuts destroy coherence and are permanently forbidden:

- **L4 must not modify L0–L2 rules.** An asset production need never justifies changing governance architecture. If L4 constraints create a need, it must go through the ChangeLog protocol at L0.
- **L3 must not invent templates.** Operators run instances; they do not design factory architectures. If an operator identifies a needed template, they submit it as a proposal — they do not self-authorize creation.
- **L1 must not produce market assets.** The Factory Builder produces governance artifacts (schemas, protocols, starter kits). Producing a market-facing asset from L1 is scope contamination.
- **L2 must not include execution procedures.** Station archetypes define *what* a station does, not *how* an operator runs it minute-by-minute.

Any violation of these rules is a structural defect, logged and repaired through the standard defect protocol.

---

## 4. Ecosystem Invariants (Global Laws)

### 4.1 Minimal Global Invariants

Invariants must be few and absolute. The following rules apply to every entity in the ecosystem — every factory, instance, asset, run, and agent — without exception and without override.

**INV-01 — Pipeline Required:**
Every factory must have a named pipeline with defined stations. A factory without a pipeline is not a factory; it is an informal workflow and must not be registered as a factory.

**INV-02 — Control Plane Required:**
Every run must be auditable through the Control Plane. Run_ID, operator, date, outputs, and QA result are mandatory fields. A run that is not logged does not exist for governance purposes.

**INV-03 — QA Must Be Able to Fail:**
QA at any station must be capable of outputting FAIL. A gate that can only produce PASS is not a gate; it is theater. Any factory or instance where QA cannot stop work is in violation of this invariant.

**INV-04 — Authority Discipline:**
Every claim in an asset must be traceable to a declared source. Invented facts, fabricated quotes, and unverified statistics are structural defects, not editorial choices. Authority discipline is a production constraint, not a style preference.

**INV-05 — WIP Limits Enforced:**
Every factory instance must operate under declared WIP limits. When limits are exceeded, new work stops. Resolution (complete, kill, or merge) precedes resumption. WIP limit violations are critical defects.

**INV-06 — Asset Identity Required:**
No asset may leave the production pipeline without: Asset ID, version number, owner, and status. An asset without identity cannot be governed, tracked, versioned, or retired.

**INV-07 — Track Discipline:**
Every change to an asset must be classified as Track A (changes meaning or structure) or Track B (changes only format or presentation). Track A changes require authority approval. Applying Track B classification to a Track A change is a critical defect.

### 4.2 Modular Components (Allowed Variability)

The following components may vary across factories and instances without violating ecosystem integrity. They are modules, not invariants:

**Writer OS profiles:** The specific voice, tone, and writing style used in a factory's production layer. Each instance may have its own profile without affecting other instances.

**Format profiles:** Output format specifications (PDF, DOCX, MD, carousel, newsletter). Factories may use different format profiles; the pipeline structure remains constant.

**Insight depth profiles:** The level of research and synthesis required for production assets. Depth may vary by content type and audience without breaking governance.

**Optional agents:** AI models, automation tools, and integrations that supplement factory operation. Agents are modules — they assist; they do not govern.

**Run cadence:** The frequency and scheduling of production runs. Cadence is an L3 operational decision within L2 constraints.

---

## 5. Governance and Authority Model

### 5.1 Decision Rights by Layer

Governance fails when decision rights are ambiguous. The following assignments are non-negotiable.

**L0 (Kernel):** Defines global laws, canonical definitions, invariants, and the layer model itself. Authority: System Architect / Owner. Decisions at L0 require explicit ChangeLog entries and version bumps. No other layer may modify L0 artifacts.

**L1 (Factory Builder):** Defines protocols, schemas, and validation tables for building MetaFactories and templates. Authority: MetaFactory Architect. L1 decisions must comply with L0 laws but may define build protocols freely within those laws.

**L2 (MetaFactories):** Defines domain-level station archetypes, artifact contracts, and module registries. Authority: Domain Owner. L2 decisions govern all L3 instances in their domain. L2 may not override L0/L1 invariants.

**L3 (Factory Operations):** Enforces execution protocols, logs all runs, manages WIP, handles defects. Authority: Factory Operator. L3 decisions are operational and do not modify templates or domain rules. Operators who identify needed changes submit proposals upward.

**L4 (Production):** Produces assets under constraints defined by L0–L3. Authority: Content Producer / Publisher. L4 decisions are asset-level: topic selection, content choices within the factory's scope. L4 never modifies governance.

### 5.2 Track A vs Track B (Global Policy)

Track A and Track B are the two lanes for handling changes to in-progress assets. They apply across all layers and all factory types.

**Track A (Governed Lane):** Required when a change affects meaning, structure, factual claims, framework definitions, or source attribution. Track A changes require: (a) authority approval from the layer owner, (b) explicit version bump, (c) ChangeLog entry documenting what changed and why. Track A is the default lane for any change that a reader would notice as substantive.

**Track B (Fast Lane):** Permitted when a change affects only presentation — formatting, layout, punctuation, visual styling, length adjustments that preserve all meaning. Track B changes can proceed without authority approval. They do not require version bumps unless bundled with a Track A change. Track B is the exception lane, not the default.

**The critical rule:** Misclassifying a Track A change as Track B to bypass authority review is a Critical defect. It invalidates the asset's QA status and requires reversion to the pre-change state.

### 5.3 Authority Discipline (Global)

Trust is a production constraint. The Big MetaFactory treats authority discipline with the same rigor as pipeline discipline — because an ecosystem that produces unverified claims destroys its own credibility more efficiently than any competitor could.

The global authority discipline rules:

1. Every factual claim requires a declared source (author, study, data, or first-hand observation).
2. No quotes may be attributed to real people unless directly sourced from verifiable records.
3. Statistical claims require recency declaration (year of data) and source type (primary/secondary).
4. When a source cannot be verified, the claim must be framed as estimate, opinion, or hypothesis — never stated as fact.
5. AI-generated content that introduces claims (not just structure) is subject to authority discipline. AI assists; the human operator owns the authority verification.

---

## 6. QA Philosophy at System Level

### 6.1 QA Is Binary

QA at the ecosystem level has one output: **PASS** or **FAIL**. There is no "mostly done," "almost ready," "soft pass," or "pass with notes." These intermediate states are governance illusions — they allow defects to accumulate until they become critical failures in production.

Binary QA means: a station gate either certifies that the output meets its DoD fully, or it stops the work and requires a fix. Partial certification is not certification.

The discipline required to maintain binary QA under time pressure is the single most important governance skill in the ecosystem. When operators feel pressure to pass imperfect work, the binary gate is the mechanism that forces an honest choice: fix it now, or log a critical defect and declare the pipeline stopped.

### 6.2 Defects and Patch Rules

Defects are classified by severity:

**Critical:** The output cannot be used or published without causing serious problems — false claims, missing core sections, broken pipeline invariants, QA gate bypassed. Critical defects stop the pipeline immediately (stop-the-line). No new work starts until the defect is resolved.

**Major:** The output is significantly incomplete or flawed but does not cause immediate harm. Major defects block promotion to the next stage but do not stop all pipeline work. They must be resolved before the asset advances.

**Minor:** The output has presentational or non-structural issues. Minor defects may be bundled and resolved in the next Track B pass. They do not block promotion.

**Patch rule:** When a defect is logged, the repair must be patch-only. A patch fixes the specific defect without introducing new scope, new claims, or new structure. Patch-and-expand is Track A — it requires authority approval and a new QA cycle.

### 6.3 Promotion Depends on QA

Nothing in the ecosystem becomes canonical without passing QA. The promotion states for any asset, template, or MetaPlaybook are:

**Draft → QA_Pass → Hardened → Canonical**

- **Draft:** Under construction. May not be used operationally.
- **QA_Pass:** Has passed all required QA gates. May be used operationally.
- **Hardened:** Has been used successfully in at least one production run. Considered stable.
- **Canonical:** Authoritative reference. Changes require full ChangeLog protocol.

Skipping promotion states is forbidden. A document cannot be declared Canonical without having been Hardened. Urgency does not override this sequence.

---

## 7. Evolution and Promotion Rules

### 7.1 How New MetaFactories Are Added

New domains require explicit entry criteria to prevent ecosystem sprawl. A new MetaFactory may be added to the ecosystem only when all of the following are true:

1. **Domain is declared and bounded:** The domain has a name, a defined scope (what factories it governs), and a declared out-of-scope (what it does not govern). Overlap with existing MetaFactories must be explicitly resolved.
2. **Factory Builder assignment:** A Factory Builder is assigned and confirmed as the entity responsible for building the first template in this domain.
3. **Minimal viable Type D MetaPlaybook exists:** The domain MetaFactory has at least a skeleton Type D MetaPlaybook with Asset Header, station archetypes, and delegation contracts. It does not need to be Canonical, but it must exist and pass structural QA.
4. **Control Plane registration:** The new MetaFactory is registered in the MetaFactory Registry before any instances are created.
5. **No orphan instances:** If instances already exist in the domain (created before the MetaFactory was formal), they must be reconciled — either brought under the new MetaFactory's governance or formally retired.

### 7.2 Template Promotion Rules

Templates must prove two things before promotion: reusability (the same template produces consistent results across different runs or operators) and operability (an operator who was not present at the template's design can run it without improvising).

Promotion criteria for Templates:
- **Draft → QA_Pass:** Template passes structural QA gate (all required sections present, station archetypes complete, artifact contracts declared).
- **QA_Pass → Hardened:** Template has been used in at least one real production run that reached packaging. Run log exists and is complete.
- **Hardened → Canonical:** Template has been used successfully by at least one operator who was not the template's author. Proves transferability.

### 7.3 Deprecation Rules

Old templates and factories must be cleanly retired when they are superseded, become incompatible with updated governance, or fail to prove operability.

Deprecation protocol:
1. Owner proposes deprecation with a written rationale and identifies any dependencies (instances or assets that reference the deprecated item).
2. Dependencies are resolved: either migrated to the replacement, explicitly grandfathered, or retired.
3. The deprecated item receives status "Deprecated" in the Control Plane with a deprecation date and pointer to the replacement (if one exists).
4. Deprecated items are never deleted — they are retained for audit trail purposes. They may not be used for new production.
5. A ChangeLog entry documents the deprecation with: item ID, deprecation date, reason, and dependency resolution notes.

---

## 8. Control Plane (Ecosystem Observability)

### 8.1 Macro Control Plane Model

The ecosystem needs a registry of factories and templates, not just individual assets. The Control Plane operates at two levels:

**Macro level (L0 responsibility):** Tracks the structure of the ecosystem — which MetaFactories exist, which templates are active, which instances are running, and what the canonical definition of every registered term is.

**Micro level (L3 responsibility):** Tracks the execution state within each factory instance — run logs, WIP status, defect lists, QA results per asset.

The two levels must be consistent. If an instance is running, it must be registered at the macro level. If an asset exists, it must appear in both the macro registry (as a class of output from its MetaFactory) and the micro log (as a specific produced item).

### 8.2 Minimum Registries

At L0, the Control Plane tracks systems, not manuscripts. The following registries are mandatory:

**MetaFactory Registry:** One row per MetaFactory. Fields: ID, domain, layer, version, status, owner, Type D MetaPlaybook pointer, instance count.

**Template Registry:** One row per Template. Fields: ID, MetaFactory parent, version, status, QA level, last run date, instance count.

**Instance Registry:** One row per running Factory Instance. Fields: ID, template parent, operator, start date, status (active/suspended/closed), run count, WIP current.

**Canonical Definitions Registry:** The authoritative list of all terms defined in this Kernel. Updated only through the Kernel Change Protocol.

**ChangeLog (Kernel):** Append-only log of all changes to L0 documents. Fields: change date, changed item, change type (Track A/B), authority who approved, summary of change.

### 8.3 Versioning Across Layers

Versioning prevents silent drift — the condition where a template or MetaPlaybook is modified informally without a version bump, creating invisible inconsistencies between what different operators believe the current rules are.

**Versioning rules:**
- Every registered artifact carries a version (format: vN.N, where the left digit is major and the right is minor).
- Major version increments (e.g., v0.1 → v1.0) indicate structural or scope changes. Require authority approval.
- Minor version increments (e.g., v1.0 → v1.1) indicate refinements, corrections, or Track B changes. Require ChangeLog entry.
- v0.x indicates a draft or pre-production artifact. v1.0+ indicates operational status.
- When an artifact is updated, all dependent artifacts that reference it must be reviewed and either updated to reference the new version or explicitly documented as still compatible with the older version.

---

## 9. Interoperability and Interfaces

### 9.1 Interface Contracts

Factories interoperate through **declared interface contracts**, not through assumptions or shared implicit understanding. An interface contract specifies:

- **Producer:** which factory or station produces the output
- **Consumer:** which factory or station receives the input
- **Artifact type:** the class of artifact being transferred (Transfer Packet, Insight Pack, QA Result, etc.)
- **Required fields:** minimum fields the artifact must contain to be valid at the receiving station
- **Version compatibility:** which versions of the artifact schema the consumer accepts

Interface contracts must be declared in both the producing MetaFactory's Type D MetaPlaybook and the consuming MetaFactory's Type D MetaPlaybook. Any interface that is assumed but not declared is an architectural liability.

### 9.2 Standard Artifact Types

The following artifact types are recognized ecosystem-wide. Any factory may produce or consume these types, and all instances of the same type share a common schema.

**Transfer Packet (TP):** The handoff artifact between the requesting entity (human or upstream factory) and the receiving factory. Contains: topic/scope, audience, objective, constraints, track declaration, and raw inputs. TPs are produced before work begins; they define what will be produced, not how.

**Insight Pack (IP):** The research and synthesis artifact produced after initial analysis and before drafting. Contains: key insights (5–10 actionable items), framework outline, source list, and authority notes. IPs may be produced at L3 (factory operations) or obtained from external research stations.

**QA Result:** The output of any QA hard gate. Contains: Run_ID, asset ID, gate ID, PASS/FAIL, defect list (if FAIL), severity classification, operator, and timestamp. QA Results are append-only records.

**Asset Package:** The final bundled output of a production run. Contains: the asset(s), Asset ID(s), version(s), QA Result reference, format specification, and packaging checklist completion record.

**Run Log:** The complete execution record for a single factory run. Contains: Run_ID, Instance_ID, operator, start/end timestamps, stations completed, QA Results per station, assets produced, defects opened, defects closed.

### 9.3 Data and Knowledge Flow

Knowledge lives in specific layers and must be transferred through declared artifacts — not through shared memory, informal context, or assumed understanding.

**Principle of explicit handoff:** Every transfer of knowledge between stations, between factories, or between sessions must happen through a registered artifact. If knowledge is being transferred but no artifact captures it, the transfer is invisible and unauditable.

**Contamination prevention:** A factory's internal knowledge (its Voice Pack, its specific domain research, its operator context) must not leak into other factories' outputs without an explicit interface. Shared knowledge must be factored into a shared artifact type with declared scope.

**Session persistence:** Because cognitive production often spans multiple work sessions, all artifacts that must persist across sessions must be registered in the Control Plane. An artifact that exists only in a single session's context is ephemeral and cannot be governed.

---

## 10. Anti-Patterns (Ecosystem Failure Modes)

### 10.1 Prompt-Driven Architecture

**Pattern:** The system's "governance" consists of a collection of long prompts that different operators have written over time. Each prompt encodes different implicit rules. When prompts conflict, the most recent one wins by default.

**Why it fails:** Prompts are ephemeral, non-versioned, and non-auditable. They cannot be QA'd. They cannot be transferred reliably. When the person who wrote the prompt leaves, the knowledge encoded in it is lost or misinterpreted. Prompt-driven systems scale to exactly one skilled person — the one who wrote the prompts.

**The cure:** Replace prompts with declared interfaces, registered templates, and versioned MetaPlaybooks. Prompts become inputs to governed pipelines, not the pipeline itself.

### 10.2 Factory Sprawl

**Pattern:** New factories are created faster than they can be governed. After 6 months, the ecosystem has 30 "factories" that are actually informal workflows, each with its own naming convention, its own QA standard (or none), and its own registry (or none).

**Why it fails:** Sprawl makes the ecosystem unnavigable. Operators cannot tell which factory to use for a given task. Quality becomes inconsistent. Maintenance cost grows faster than productive output.

**The cure:** WIP limits apply to factories, not just assets. No new factory may be created until its MetaFactory registration is complete. Existing informal workflows must be audited and either formalized or retired before new ones are added.

### 10.3 Governance Theater

**Pattern:** The system has elaborate governance documentation — layer descriptions, QA checklists, approval protocols — but none of it actually stops bad work from advancing. Gates are always passed. Stop-the-line is theoretically possible but never invoked.

**Why it fails:** Documentation that does not change behavior is not governance; it is aesthetic. Operators learn quickly that the gates are performative and stop engaging with them seriously. QA results become checkbox exercises.

**The cure:** Governance that cannot stop work is not governance. The test of governance is whether it has ever caused work to stop. If a gate has never produced FAIL, the gate is not functioning. Audit and repair.

### 10.4 Hero-Operator Dependency

**Pattern:** The system works, but only because one specific person knows all the implicit rules, resolves all the ambiguities, and is always available to answer "how does this work?" questions. When that person is unavailable, production stops.

**Why it fails:** This pattern looks like a functioning system but is actually a talented individual operating without a system. The moment the hero operator is unavailable — vacation, illness, departure — the system reveals that it never existed.

**The cure:** The Pilot Cycle test: if a qualified operator who was not involved in the factory's design can run a complete production cycle without improvising or asking questions, the factory is real. If they cannot, it is a hero-operator dependency disguised as a factory.

---

## 11. Boundaries and Out-of-Scope

### 11.1 What This MetaPlaybook Does Not Do

This document explicitly excludes the following to protect the kernel from scope contamination.

**No step-by-step operating procedures:** How operators execute daily production cycles belongs to L3 Operations MetaPlaybooks. Including execution procedures here would make this document impossible to maintain and would couple governance tightly to operational details that change frequently.

**No writing instructions:** How to write books, playbooks, newsletters, or any other content belongs to L4 Production Playbooks, informed by Writer OS profiles at L3. Writing instructions at L0 would contaminate governance with production preferences.

**No publishing tactics:** Platform-specific guidance (how to format for a specific marketplace, how to build an email sequence, when to publish) belongs to L4 or below. These tactics change with platforms and audiences; governance does not.

**No tooling specifications:** Which AI model, automation platform, or software to use for specific tasks is an implementation decision that belongs to L3. The kernel must remain implementation-agnostic.

### 11.2 Where Those Topics Belong

- Step-by-step operations → L1 Factory Builder MetaPlaybook, L3 Operations Playbooks
- Writing instructions and Voice OS → L3 Operations Playbooks, L4 Production Playbooks
- Publishing and platform tactics → L4 Production Playbooks
- Tooling and automation specs → L3 instance configuration, not MetaPlaybooks

---

## 12. Appendices

### 12.1 Example Ecosystem Map

```
BIG METAFACTORY (L0 — this document)
│
├── L0.5 — MetaPlaybook of MetaPlaybooks
│        (classification + inheritance rules for all MPBs)
│
├── L1 — Factory Builder
│        (protocols to create MetaFactories and Templates)
│
├── L2 — MetaFactories
│        ├── AI Publishing MetaFactory
│        │     └── Victor Publishing Factory (VPF)
│        ├── Tu Sherpa IA MetaFactory (MF-DIA)
│        └── [Future: Consulting, HR, Coaching...]
│
├── L3 — Factory Operations (Instances)
│        ├── FI-SHA-VICTOR (active)
│        └── [Future: per-client instances]
│
└── L4 — Production Lines (Assets)
         ├── SHA-VICTOR-Prompt-v01
         ├── SHA-VICTOR-Ritual-v01
         ├── SHA-VICTOR-Manual-v01
         └── SHA-VICTOR-Assessment-v01

L6 — Platform & Governance (MEL)
     (enforcement layer across all tiers)
```

### 12.2 Glossary Expansion Protocol

New terms are proposed through the following process:

1. **Proposal:** Any team member may propose a new canonical term. The proposal must include: the term, a two-sentence operational definition, the layer it primarily belongs to, and a rationale for why the existing vocabulary does not cover it.
2. **Review:** The Owner (Victor Heredia) reviews the proposal against existing definitions for overlap and conflict. If conflict exists, the proposal is revised or the conflicting term is updated.
3. **Drafting:** The proposed definition is added to this Kernel as Draft status. It may be used operationally with Draft status.
4. **Promotion:** After the term has been used in at least two governed production contexts without ambiguity, it is promoted to Canonical.
5. **Registration:** The Canonical Definitions Registry is updated with the finalized definition.

### 12.3 Kernel Change Protocol

L0 changes are the highest-risk changes in the ecosystem because they affect all layers simultaneously. The protocol:

1. **Proposal:** Change request submitted with: item to change, current version, proposed change, reason (which anti-pattern or gap does it fix), and estimated impact on dependent layers.
2. **Impact analysis:** Identify all artifacts in L1–L4 that reference the item being changed. Document which will need updating.
3. **Review and approval:** Owner reviews. For structural changes (layer model, invariant list, canonical definitions), a waiting period of 48 hours is required before approval to prevent reactive changes.
4. **Versioning:** The Kernel receives a minor version bump (Track B) or major version bump (Track A) as appropriate.
5. **ChangeLog entry:** Append-only. Fields: date, change type (Track A/B), changed item, summary, authority, impact notes.
6. **Cascade update:** All dependent artifacts are updated or explicitly documented as still compatible.

---

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