## Asset Header

- **Asset ID:** DC-XX-BMF-MEL-ActivationProfile-v01
- **Version:** v01
- **Status:** Draft
- **Owner:** Victor Heredia
- **IntellBank:** IB-XX-Maestro
- **Tipo:** DC — Document Canónico
- **Propósito:** BMF MEL Activation Profile — Stage 1 (Solo / Lean) v0.1
- **Última actualización:** 2026-04-11

---

# BMF MEL Activation Profile — Stage 1 (Solo / Lean) v0.1


---

## 1. Current Stage Declaration

**Active Stage: Stage 1 — Solo / Lean Operations**

**Context:** Victor Heredia operates as the single primary operator. Active factories: FI-SHA-VICTOR (L3, active). Architecture documents in Draft/Skeleton → QA_Pass promotion phase. No concurrent Build Rooms. No multi-operator contributions to canonical assets.

**Stage 1 activation criteria (all met):**
- ✅ Single operator
- ✅ One or two active factories (FI-SHA-VICTOR is the only active instance)
- ✅ Early asset production phase
- ✅ No concurrent Build Room sessions

**Trigger for Stage 2 transition:**
Stage 2 activates when any of the following occurs:
- A second operator (Ángeles, Anaí, Juan Carlos) begins contributing to canonical assets
- Two or more factory instances are simultaneously active and in production
- Concurrent Build Room sessions are running for different MetaFactories
- Assets begin moving through formal promotion gates (Draft → QA_Pass) in the shared registry

When the Stage 2 trigger is met, a Stage Transition Artifact must be created before Stage 2 mechanisms are activated.

---

## 2. Active Mechanisms — Stage 1

The following MEL mechanisms are ACTIVE now. They must be applied in every session, for every asset, without exception.

### 2.1 Artifact Philosophy (Active)

**Rule:** If it is not an artifact, it does not exist.

**Applied to every session:**
- Any decision made during a session must be captured in an artifact before the session ends
- Insights, plans, and conclusions that exist only in the session's context window are ephemeral and ungoverned
- The minimum artifact at session close is a logged output in the Control Plane or a registered document update

**Enforcement:** At session close, ask: "What artifact captures the work done in this session?" If none exists, one must be created before the session is considered complete.

### 2.2 Naming Governance (Active)

**Rule:** All assets must comply with BMF-NamingConvention.

**Applied to every asset:**
- Pattern: `[PREFIX]-[Description]-vNN.md`
- Core rule: Asset ID = Filename (no extension) = [[Wiki Link]]
- Asset Header must be present and Asset ID must match filename

**Enforcement:** Any asset that does not comply with naming convention is non-compliant and must be corrected before being registered. Non-compliant assets may not be cited as authoritative references.

**Reference:** See `BMF-NamingConvention` for full rules and rename protocol.

### 2.3 Asset Registry (Active)

**Rule:** Every asset requires a registry entry in `BMF-Registry-Activos-v01` before it can be used externally or cited as authoritative.

**Applied to every new asset:**
1. Create the document with a proper Asset Header
2. Register it in `BMF-Registry-Activos-v01` with correct fields
3. Only after registration may the asset be referenced from other documents

**Enforcement:** An asset that is not in the registry does not exist for governance purposes (per INV-06).

### 2.4 Session Closure Hook (Active)

**Rule:** Every work session must produce at least one artifact before closing.

**At every session close:**
- [ ] At least one artifact created, updated, or logged
- [ ] If any decision was made, it is captured in a registered document
- [ ] If any ProtoGate was identified, it is documented in the registry or a Learning Log

**What counts as an artifact:**
- A new or updated .md file registered in BMF-Registry-Activos-v01
- A new entry in a Run Log
- A resolved registry alert (DA-XXX)
- A new ProtoGate entry

**What does NOT count:** "I thought about it" or "I discussed it." Only registered artifacts count.

### 2.5 Transfer Pack Gate (Active)

**Rule:** No Build Room activates without a Transfer Pack.

**Applied before any architecture or design session:**
- The correct TP must be present before work begins
- For architecture work: use `BMF-TP-Architecture`
- For factory production: use the factory's own TP (e.g., `Re100X-TP-SherpaIA-v01`)
- For new factory design: use `MFB-MPB-MetaFactoryBuilder-v01` as the governing document

**Enforcement:** Starting work without a TP is a Proto-Gate violation (Stage 1) that becomes a Block (Stage 2). Document it as a Proto-Gate when it occurs.

### 2.6 Version Control (Active)

**Rule:** No canonical asset may be modified without a version increment.

**Applied to every asset modification:**
- Track B change (format only) → minor version bump (v01 → v02) + ChangeLog entry
- Track A change (meaning/structure) → major version bump (v01 → v10 or v10 → v20) + ChangeLog entry + Owner approval
- ChangeLog entry minimum fields: date, version before/after, change type, what changed, why

**Enforcement:** An asset that shows modification evidence (different content from what was last registered) without a version bump is in violation. The ChangeLog must be updated retroactively before the asset can be used as authoritative.

### 2.7 `#mastery.check` (Active)

**Purpose:** Evaluate the current session or artifact for governance readiness.

**When to run:**
- At the start of any architecture session
- Before promoting any asset from Draft → QA_Pass
- When unsure whether a governance rule applies to the current work

**Output format:**
```
MASTERY CHECK — [Date] — [Asset or Session]

Governance readiness: [READY / NOT READY / GAPS DETECTED]

Active invariants status:
  INV-01 (Pipeline): [PASS / N/A / GAP]
  INV-02 (Control Plane): [PASS / N/A / GAP]
  INV-03 (QA PASS/FAIL): [PASS / N/A / GAP]
  INV-04 (Authority): [PASS / N/A / GAP]
  INV-05 (WIP Limits): [PASS / N/A / GAP]
  INV-06 (Asset Identity): [PASS / N/A / GAP]
  INV-07 (Track A/B): [PASS / N/A / GAP]

Primary blocking gap: [Description, or NONE]
Recommendation: [What to do before proceeding]

Proto-Gates detected: [List or NONE]
```

### 2.8 `#mastery.harden` (Active)

**Purpose:** Convert a detected governance gap into an enforceable artifact.

**When to run:**
- When `#mastery.check` identifies a gap
- When a repeated problem surfaces in sessions (same issue 2+ times)
- When informal rules are being applied without documentation

**Output:** Must produce one of:
- An invariant added to the relevant MetaPlaybook
- A governance rule added to the relevant document
- A QA gate specification
- A Proto-Gate entry in the registry (if activation is deferred to Stage 2/3)

If the output is a Proto-Gate, it must be formally documented and logged. Proto-Gates are not optional — they are real artifacts with lower activation priority.

### 2.9 M1 — Inform (Active)

**Purpose:** Non-blocking awareness of governance gaps. Logging and early detection.

**At Stage 1, M1 is the primary enforcement mechanism.** When a governance issue is detected:
1. Log the issue (in the registry, a session log, or a document note)
2. Classify it as: Proto-Gate / Minor Defect / Major Defect / Critical Defect
3. Assign a resolution priority
4. Do not block current work unless it is a Critical Defect (in which case, stop-the-line manually)

**M1 does not block work** — but every M1 event is a formal record. Repeated M1 events for the same issue trigger `#mastery.harden`.

---

## 3. Deferred Mechanisms — Stage 2+

The following mechanisms are NOT active at Stage 1. They are documented as Proto-Gates — real governance intentions that will be activated when Stage 2 criteria are met.

| Mechanism | Activation Stage | Activation Condition |
|---|---|---|
| M2 — Block | Stage 2 | Second operator OR parallel factories active |
| M3 — Stop-the-Line (auto) | Stage 2/3 | Full MEL Runtime OR multi-operator canonical work |
| `#mel.block` | Stage 2 | Block command executable in any Build Room |
| `#mel.audit` | Stage 2 | Parallel factories exist |
| `#mel.stopline` | Stage 3 | Highest enforcement — requires System Steward |
| `#mel.stage` | Stage 2 | Stage identification command |
| MEL Runtime Agent | Stage 3 | Automated governance agent deployed |
| System Steward Assignment | Stage 3 | Named steward for stop-the-line resolution |
| Cross-Factory Promotion Gate | Stage 3 | Assets promoted to multi-factory canonical status |
| Frozen Asset Protection (auto) | Stage 3 | Mutation of frozen assets triggers automatic stop |

**Proto-Gate record:** These are registered as pending enforcement in `BMF-Registry-Activos-v01` under the Alertas Activas section.

---

## 4. Stage 1 Operating Rules (Daily Practice)

These are the practical day-to-day applications of Stage 1 MEL for the BMF ecosystem.

### Before starting any session:
1. Confirm which Build Room is being activated
2. Confirm the Transfer Pack is present (or create it)
3. Run `#mastery.check` if starting architecture work

### During any session:
1. Apply Track A/B discipline to all content changes
2. Maintain Asset Identity on all outputs (ID + version + owner + status)
3. Log any governance gap as M1 (inform) — never ignore
4. Document any Proto-Gate immediately when detected

### At session close:
1. Confirm at least one artifact was created or updated
2. Confirm the artifact is registered in BMF-Registry-Activos-v01
3. Confirm any modified asset has a version bump and ChangeLog entry
4. List any Proto-Gates detected during the session

### When a governance gap is critical:
1. Stop current production work
2. Document the defect with: what was violated, which asset, what the impact is
3. Apply the patch (fix only what is broken — do not expand scope)
4. Re-verify the asset before resuming

---

## 5. Proto-Gate Log

Active Proto-Gates for Stage 2 activation (as of v0.1, 2026-03-22):

| Proto-Gate ID | Mechanism | Condition for Activation | Status |
|---|---|---|---|
| PG-001 | M2 — Block | Second operator joins OR second factory activates | Deferred — Stage 2 |
| PG-002 | `#mel.block` | Same as PG-001 | Deferred — Stage 2 |
| PG-003 | `#mel.audit` | Parallel factories exist | Deferred — Stage 2 |
| PG-004 | Build Room Activation Gate (formal) | Stage 2 active | Deferred — Stage 2 |
| PG-005 | Promotion Gate (formal) | Assets moving through lifecycle regularly | Deferred — Stage 2 |

---

## 6. Stage Transition Artifact Template

When Stage 2 criteria are met, create the following artifact before activating Stage 2 mechanisms:

```
STAGE TRANSITION ARTIFACT

Date: [YYYY-MM-DD]
Transitioning from: Stage 1 → Stage 2
Owner: Victor Heredia

Trigger condition met:
  [ ] Second operator joining canonical work
  [ ] Two+ active factory instances
  [ ] Concurrent Build Room sessions
  [ ] Other: [describe]

Proto-Gates being promoted to active enforcement:
  PG-001: M2 — Block → ACTIVATED
  PG-002: #mel.block → ACTIVATED
  PG-003: #mel.audit → ACTIVATED
  PG-004: Build Room Activation Gate → ACTIVATED
  PG-005: Promotion Gate → ACTIVATED

Remaining deferred (Stage 3):
  PG-006: M3 — Stop-the-Line (auto)
  PG-007: MEL Runtime Agent
  PG-008: System Steward Assignment
  PG-009: Cross-Factory Promotion Gate
  PG-010: Frozen Asset Protection (auto)

Signed: Victor Heredia
Registry update: BMF-Registry-Activos-v01 updated with Stage 2 declaration
```

---

*Asset ID: BMF-MEL-ActivationProfile | Version: v0.1 | Status: Active | Owner: Victor Heredia*