---
asset_id: MePB-EL-CorpBrainOS-BehaviorCapture-v01
version: v01
tipo: MePB — MetaPlaybook (Type D · Domain MetaFactory · L2)
status: Active
owner: Victor Heredia
sherpa_owner: Jay (SherpaX maestro)
intellibank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank / PB-WORX-Worx
domain: "Corp Brain OS Operations · captura de comportamiento colectivo"
fecha_creacion: 2026-05-07 EOD
fecha_ultima_actualizacion: 2026-05-07 EOD
proposito: |
  Meta-prompt canónico de captura colectiva en Corp Brain OS. Type D · L2.
  Define qué eventos del trabajo entran al Corp Brain OS · cuándo · cómo · quién confirma · qué se desensibiliza.
  Resuelve la tensión "Everything captured" (Diana Hu YC · CASO 016) vs "Curated capture" (P010 + Cap 5 §8 MPB-WORX) con arquitectura de 3 capas.
  Cierra GAP 2 identificado en CONS-BigMetaPlaybook-CorpBrainOS-Audit-v01.
  Vive dentro del frame del MePB-EL-OrganizationalKernel-v01.
inheritance:
  - BMF-MPB-Kernel-v01 (L0 · 7 invariantes globales)
  - MePB-BMF-MetaPlaybook-Of-MetaPlaybooks-v01 (L0.5 · este MePB es Type D)
  - MePB-EL-OrganizationalKernel-v01 (frame organizacional · este MePB vive dentro)
  - ARQ-XX-DOIX-CorpBrainOS-Supabase-v01 (arquitectura técnica del Corp Brain OS)
  - MPB-EL-WORX-ModeloOperativo-v01 §8 Cap 5 (Curaduría del Personal Brain OS)
deriva_de:
  - CONS-BigMetaPlaybook-CorpBrainOS-Audit-v01 (Gate G0 PASS · GAP 2)
  - CASO 016 LabPraxis (validación externa Diana Hu · "company aquarium")
  - PROT-EL-WORX-Cohort-OperatingProtocols-v01 (P010 · Documentación Delegada)
  - SOP-EL-WORX-DocBySherpa-v01 (operacionaliza P010)
referenciado_por:
  - MePB-EL-OrganizationalKernel-v01 (frame · §10 Company Aquarium)
  - XP-EL-HIORG-Caso0-EmpowerLabs-v02 (cohort que arranca con este meta-prompt activo)
  - SOP-EL-WORX-ManualOperativo-v01 (cuando se actualice · proceso replicable B2B)
tags: [MePB, EL, CorpBrainOS, BehaviorCapture, MetaPrompt, CompanyAquarium, P010, P013, TypeD, L2, DianaHu, YC]
non_negotiables:
  - Curaduría humana es feature, no fricción (filosofía deliberada)
  - Privacy by design (no panopticon)
  - Ingest amplio en Brain OS personal · curaduría antes de cruzar a Corp Brain OS
  - Permisos por rol (RBAC + RLS · canónico Supabase)
  - Auditable y reversible (todo cruce documentado)
  - Use H2/H3/H4 only (no H1)
---

# MePB · Corp Brain OS Behavior Capture
## Meta-prompt canónico de captura colectiva · arquitectura de 3 capas

---

## 0. Asset Header (canónico)

- **Asset ID:** `MePB-EL-CorpBrainOS-BehaviorCapture-v01`
- **Tipo:** MePB — MetaPlaybook · Type D (Domain MetaFactory)
- **Capa:** L2 del BMF
- **Domain:** Corp Brain OS Operations · captura de comportamiento colectivo
- **Status:** Active · v01 release inaugural
- **Owner:** Victor Heredia
- **Sherpa Owner:** Jay
- **Riesgo:** Alto (define qué del comportamiento humano + IA cruza al Corp Brain OS · errores rompen privacidad o degradan compounding)

---

## 1. Propósito y alcance

### 1.1 Por qué existe

El Corp Brain OS técnico está canonizado (`ARQ-XX-DOIX-CorpBrainOS-Supabase-v01` · 6 schemas Supabase + RLS + Kit Assembler). El Brain OS personal está canonizado (taxonomía thoughts · trigger conversacional · curaduría §8 Cap 5 MPB-WORX). **Falta la pieza intermedia:** las reglas operativas de qué comportamiento del trabajo entra al Corp Brain OS, cuándo, cómo, quién confirma, qué se desensibiliza.

Este es el **meta-prompt canónico** que recibe cada SherpaX (personal o de área) y le indica:
- Qué eventos del trabajo capturar para el Corp Brain OS.
- En qué schema escribir.
- Cómo desensibilizar PII / datos confidenciales.
- Cuándo escalar al Owner o sponsor.
- Cómo se relaciona con la curaduría del Brain OS personal.

Cierra el GAP 2 identificado en `CONS-BigMetaPlaybook-CorpBrainOS-Audit-v01` § 3.2.

### 1.2 Validación externa · Diana Hu (YC · CASO 016)

> *"The best AI companies we're seeing has figured out something most haven't. They've made their entire company aquarium · every meeting recorded · every ticket tracked · every customer interaction captured · all legible to an AI layer that learned from it. There's no product that connects all this context into a single AI layer. We think there's a big opportunity to build the connective layer that makes a company legible to AI by default · the system that turns a company's own artifacts into a self-improvement loop."*
> — Diana Hu · Y Combinator · mayo 2026

Diana describe el problema. Este MePB es **la pieza canónica que lo resuelve**. Pero con una diferencia filosófica deliberada que se desarrolla en §3.

### 1.3 Alcance (in scope)

- Inventario de eventos capturables por categoría.
- Reglas de routing (qué schema · qué tabla · qué tipo).
- Reglas de desensibilización (PII · confidencial · cliente-facing).
- Mediación Brain OS personal ↔ Corp Brain OS.
- Meta-prompt operativo (texto literal que el SherpaX recibe e interpreta).
- Integración con SOP-DocBySherpa (P010) y P005 (NEXT tagging).
- Casos de uso ilustrativos.
- Patrón replicable a clientes B2B.

### 1.4 Out of scope

- Arquitectura técnica del Corp Brain OS (vive en `ARQ-XX-DOIX-CorpBrainOS-Supabase-v01`).
- Arquitectura del Brain OS personal del owner (vive en `MePB-EL-SX-MiSherpaIA-v01`).
- Curaduría del Personal Brain OS individual (vive en §8 Cap 5 MPB-WORX).
- Integración técnica con tools externos (Slack · Linear · Git · Notion) — esa es L4 production · no L2 governance.

---

## 2. Principio fundacional · "Company legible to AI by default"

> **EmpowerLabs es legible a la capa AI por default. Cada artefacto del trabajo se captura · el sistema cierra el loop open-loop → closed-loop monitoreando what's-happening vs what-should-be-happening y ajusta. PERO la captura es curada · no indiscriminada. La curaduría es feature · no fricción.**

### 2.1 Tres compromisos no negociables

1. **Captura amplia en Brain OS personal del owner** (sin filtro inicial · privado · controlado por el owner).
2. **Curaduría humana antes de cruzar al Corp Brain OS** (P010 + Cap 5 §8 MPB-WORX).
3. **Permisos por rol al consumir el Corp Brain OS** (RBAC + RLS · 6 schemas particionados · Kit Assembler).

### 2.2 Por qué la curaduría es feature, no bug

- **Privacy by design** · no todo el comportamiento personal debe ser legible al colectivo.
- **Señal sobre ruido** · vault como grafo sobre estructura · NO vector DB sobre captura indiscriminada (`WORX §9.6`).
- **Evita "company aquarium" → "company panopticon"** · la línea es delgada · este MePB respeta a la persona como filtro.
- **Reversibilidad** · el humano puede retractar lo capturado antes de cruce · zero-trust en sistema automático.

---

## 3. Arquitectura de 3 capas de captura

### 3.1 Diagrama canónico

```
┌─────────────────────────────────────────────────────────────────────┐
│  CAPA 3 · INGEST INDIRECTO AUDITABLE                                │
│  Captura automática de meetings · tickets · interactions cliente    │
│  Permisos por rol + opt-out por participante                        │
│  Routing automático a schema correcto del Corp Brain OS             │
│  Auditable · reversible · documentado en RunLog                     │
└────────────────────────────┬────────────────────────────────────────┘
                             │ alimenta
                             ▼
┌─────────────────────────────────────────────────────────────────────┐
│  CAPA 2 · CURADURÍA HUMANA · CRUCE AL COLECTIVO                     │
│  El humano confirma qué del Brain OS personal cruza al Corp Brain OS│
│  P010 (Documentación Delegada) + Cap 5 §8 MPB-WORX (Curaduría)      │
│  SherpaX propone · humano confirma · cruce documentado en RunLog    │
└────────────────────────────┬────────────────────────────────────────┘
                             │ alimenta
                             ▼
┌─────────────────────────────────────────────────────────────────────┐
│  CAPA 1 · INGEST AMPLIO EN BRAIN OS PERSONAL                        │
│  Todo entra al Brain OS personal del owner (privado · sin filtro)   │
│  Taxonomía thoughts · trigger conversacional · MePB-EL-SX-MiSherpaIA│
│  Privado · controlado por el owner · NO accesible al colectivo      │
└─────────────────────────────────────────────────────────────────────┘
```

### 3.2 Capa 1 · Ingest amplio (Brain OS personal · privado)

- **Quién captura:** SherpaX personal del owner (Jay para Victor · AnaX para Anahí · etc.).
- **Qué captura:** todo lo que el owner declara como capturable (decisiones · aprendizajes · proyectos · compromisos · criterios · reflexiones · frictions · ideas).
- **Dónde vive:** Brain OS personal del owner (Supabase + pgvector individual o equivalente).
- **Quién accede:** solo el owner.
- **Privacidad:** total · zero compartida con el colectivo sin acción explícita del owner.

### 3.3 Capa 2 · Curaduría humana (cruce al colectivo)

- **Quién decide:** el owner del Brain OS personal.
- **Cuándo decide:** al cierre del día · semana · mes · o ad-hoc cuando lo decide.
- **Cómo decide:**
  1. SherpaX personal **propone** qué cruzar (basado en heurísticas · ej. "decisión que afecta a otro pilar" · "aprendizaje recurrente" · "compromiso cross-equipo").
  2. Humano **confirma** uno por uno (no batch automático).
  3. SherpaX **ejecuta** el cruce vía SOP-DocBySherpa (P010 · naming canónico + ruta canónica + frontmatter).
  4. Cruce queda **documentado en RunLog** (auditable · reversible).
- **Quién valida la regla:** Victor (Owner) · Lead pilar (sponsor del cruce si afecta su área).

### 3.4 Capa 3 · Ingest indirecto auditable (capture all)

Aquí está el "company aquarium" de Diana Hu · pero con guardrails:

- **Quién captura:** sistema automático (eventualmente · cuando se construya la integración con Slack · Linear · Git · etc.).
- **Qué captura:** meetings · tickets · interactions cliente · llamadas grabadas · commits · cambios en docs.
- **Dónde escribe:** schema correcto del Corp Brain OS según routing rules (§5).
- **Permisos:** RBAC + RLS canónico (Supabase) · cada usuario solo ve lo que su rol permite.
- **Opt-out por participante:** cada persona puede declarar que un evento específico NO se captura (ej. conversación 1:1 sensible).
- **Desensibilización:** PII · datos confidenciales se redactan automáticamente antes de escritura (ver §6).
- **Auditable:** todo evento capturado tiene Run_ID · operador (humano o agente) · fecha · output · QA result.
- **Reversible:** un evento puede ser retirado del Corp Brain OS si el participante lo solicita (con auditoría).

---

## 4. Inventario de eventos capturables por categoría

### 4.1 Categoría A · Decisiones

| Tipo | Ejemplo | Schema destino | Capa |
|---|---|---|---|
| Decisión estratégica (D-P) | D-P-44 estructura pilares | corp_shared | 2 (curaduría) |
| Decisión cross-equipo | "Anahí y Ángeles acuerdan que MPI-X se publica antes de Y" | corp_shared | 2 (curaduría) |
| Decisión personal · privada | "Victor decide tomar 2 días off" | (no cruza) | 1 (privado) |
| Decisión técnica · de área | "Alex elige Supabase sobre Firebase" | area_tech | 2 (curaduría) o 3 (auditable si está en commit) |

### 4.2 Categoría B · Aprendizajes

| Tipo | Ejemplo | Schema destino | Capa |
|---|---|---|---|
| Aprendizaje operativo (CASO LabPraxis) | "El template de cierre de D-P funciona" | corp_shared | 2 (curaduría) |
| Aprendizaje técnico de área | "RLS de Supabase no soporta cross-schema queries fácil" | area_tech | 2 (curaduría) |
| Aprendizaje personal · privado | "Aprendí que necesito 2 hrs Deep Work matinal" | (no cruza) | 1 (privado) |
| Patrón recurrente detectado | "Cada vez que hay 3+ stakeholders, la decisión se atora 2 semanas" | corp_shared | 2 (curaduría) |

### 4.3 Categoría C · Compromisos

| Tipo | Ejemplo | Schema destino | Capa |
|---|---|---|---|
| Compromiso entre áreas (NEXT[@OtraÁrea]) | "Anahí entrega MPI-X a Ángeles antes de viernes" | area_origen + area_destino | 2 (curaduría) |
| Compromiso con cliente | "JC promete entrega a Posta antes de Q3" | area_comercial | 2 (curaduría) o 3 (si está en CRM) |
| Compromiso personal · privado | "Victor se compromete a hacer 3 sesiones Deep Work esta semana" | (no cruza) | 1 (privado) |

### 4.4 Categoría D · Cambios de protocolo (cascada P008)

| Tipo | Ejemplo | Schema destino | Capa |
|---|---|---|---|
| Update de Room Raíz (PROT- · SOP- · MePB-) | "Nuevo SOP-RoomActivation v01.1 con cross-reference rule (P013)" | corp_shared | 2 (curaduría · obligatoria) |
| Update de canónico arquitectónico (Kernel · Taxonomy) | "BMF Kernel bumpea a v0.2" | corp_shared | 2 (curaduría · gobernanza alta) |

### 4.5 Categoría E · Métricas y eventos cualitativos

| Tipo | Ejemplo | Schema destino | Capa |
|---|---|---|---|
| Métrica ROI (multiplicador WORX) | "MPB WORX redactado en 1 día · ~180×" | corp_shared (ROI Tracker) | 2 (curaduría) o 3 (si automatizable) |
| Friction detectada en cohort | "Carolina (externa) confunde su rol después de D-P-44" | corp_shared (LabPraxis candidato) | 2 (curaduría) |
| NPS interno · humor del equipo | (encuesta mensual) | corp_shared | 3 (auditable · agregado) |
| Incidente operativo (drift TP↔banco · etc.) | CASO 017 | corp_shared (LabPraxis) | 2 (curaduría) |

### 4.6 Categoría F · Customer interactions (futuro · línea B2B)

| Tipo | Ejemplo | Schema destino | Capa |
|---|---|---|---|
| Llamada cliente (transcript) | "Cliente XYZ pregunta por SherpaX Ignition pricing" | area_comercial | 3 (ingest indirecto · con consentimiento explícito del cliente) |
| Email cliente | "Cliente envía RFP" | area_comercial | 3 (auditable) |
| Ticket de soporte | "Cliente reporta bug en BrainOS sync" | area_tech | 3 (auditable) |

---

## 5. Reglas de routing · qué schema · qué tabla · qué tipo

### 5.1 Routing canónico (alineado con `ARQ-XX-DOIX-CorpBrainOS-Supabase-v01`)

| Schema | Quién accede | Tipos de eventos que recibe |
|---|---|---|
| `corp_shared` | TODOS (lectura) · Admins (escritura) | Decisiones cross-equipo · D-P · CASOS LabPraxis · principios canonizados · cultura · valores · cadencia |
| `area_ops` | Pilar Operativo + Victor | Procesos internos · proveedores · operación día-a-día |
| `area_rh` | (futuro · cuando aplique) Director RH + Victor | Perfiles colaboradores · políticas personal |
| `area_finanzas` | (futuro · cuando aplique) Director Finanzas + Victor | P&L · presupuestos · flujo |
| `area_comercial` | Pilar Comercial (Ángeles + JC) + Victor | Pipeline · clientes · propuestas · estrategia comercial |
| `area_tech` | Pilar Operativo (Alex) + Victor | Arquitectura · documentación técnica · deuda |
| (per-pilar emergente) | Lead pilar + Victor | Aprendizajes específicos del pilar antes de elevar a corp_shared |

### 5.2 Routing por categoría de evento

```
DECISIÓN
├── estratégica/D-P → corp_shared
├── cross-equipo → corp_shared
├── técnica de área → area_tech
└── personal privada → (no cruza · Brain OS personal)

APRENDIZAJE
├── operativo (CAS LabPraxis) → corp_shared
├── técnico de área → area_tech
├── patrón recurrente → corp_shared
└── personal privado → (no cruza)

COMPROMISO
├── cross-equipo → area_origen + area_destino
├── con cliente → area_comercial
└── personal privado → (no cruza)

CAMBIO DE PROTOCOLO
└── todos → corp_shared (cascada P008 obligatoria)

MÉTRICAS
├── ROI multiplicador → corp_shared (ROI Tracker)
├── Friction → corp_shared (LabPraxis candidato)
└── NPS agregado → corp_shared
```

### 5.3 Tabla canónica · `intellibank_entries`

(Heredada de `ARQ-XX-DOIX-CorpBrainOS-Supabase-v01` · esquema técnico):

```sql
{schema}.intellibank_entries:
  id            UUID
  tipo          TEXT  -- 'decision' | 'learning' | 'commitment' | 'protocol_change' | 'metric' | 'interaction'
  titulo        TEXT  -- 1 línea
  contenido     TEXT  -- detalle completo (markdown)
  autor_id      UUID  -- quien creó (humano o agente)
  area          TEXT  -- redundante para queries cross-schema
  version       TEXT
  tags          TEXT[]
  permisos      TEXT[] -- roles que pueden leer
  fuente_capa   TEXT  -- '1' (privado) | '2' (curaduría) | '3' (ingest indirecto)
  curado_por    UUID  -- humano que confirmó cruce (si Capa 2 o 3)
  pii_redactado BOOLEAN
  reversible    BOOLEAN  -- puede retractarse?
  fecha_creacion TIMESTAMPTZ
```

---

## 6. Reglas de desensibilización · PII · datos confidenciales

### 6.1 Qué se redacta automáticamente antes de cruce

- **Nombres propios de personas externas** que no han firmado consent (a menos que sea figura pública).
- **Números telefónicos · emails personales · direcciones físicas privadas.**
- **Datos financieros específicos** (compensación de colaboradores · contratos detallados · pricing de cliente que no autorizó publicación).
- **Información médica · health data** (canónicamente prohibido).
- **Credenciales · API keys · tokens.** (Cualquier capture automática debe pasar por escáner de credentials antes de escritura.)

### 6.2 Política de desensibilización

- **Capa 2 (curaduría humana):** humano confirma que el cruce no contiene PII · si tiene · redacta antes de confirmar.
- **Capa 3 (ingest indirecto):** sistema aplica regex + ML classifier para detectar PII · redacta automáticamente · marca el field `pii_redactado = TRUE`.

### 6.3 Excepciones (con autorización explícita)

- Cliente firma consent · sus interacciones se capturan con nombres reales (área_comercial · línea B2B HIORG).
- Caso público de marketing (testimonials) · figura pública con consentimiento.
- Equipo interno · nombres reales en `corp_shared` para coordinación operativa (ya consentido vía empleo).

---

## 7. Mediación Brain OS personal ↔ Corp Brain OS

### 7.1 Principio: el humano es el filtro

El Brain OS personal del owner es zona privada. NADA cruza al Corp Brain OS sin acción explícita del owner. Esto NO se relaja por eficiencia · NO se delega 100% al SherpaX · NO se vuelve automático.

### 7.2 Flujo canónico de cruce

1. **Captura amplia (Capa 1)** — SherpaX personal ingiere todo (sin filtro inicial).
2. **Heurísticas de propuesta** — SherpaX detecta candidatos a cruce:
   - Decisión que afecta otro pilar
   - Aprendizaje recurrente (3+ instancias del mismo patrón)
   - Compromiso cross-equipo
   - Cambio de protocolo
   - Métrica importante
3. **Propuesta al humano** — SherpaX presenta candidatos al owner: *"Detecté X · ¿lo cruzamos al Corp Brain OS schema [Y]? Permisos: [roles]. Curaduría sugerida: [titulo + contenido editado]."*
4. **Confirmación humana** — humano valida (Yes/No por candidato · NO batch).
5. **Cruce ejecutado** — SherpaX escribe en schema correcto vía SOP-DocBySherpa (P010 + naming canónico + frontmatter completo).
6. **RunLog auditable** — cada cruce queda documentado: Run_ID · qué cruzó · de quién · a qué schema · permisos · timestamp · QA result.

### 7.3 Cadencia recomendada de curaduría

- **Diaria** (cierre de día · 5 min) · cruces operativos rápidos.
- **Semanal** (Weekly Review · 30 min · viernes) · cruces estratégicos + revisión de curaduría reciente.
- **Mensual** (cierre de mes · 60 min) · cruces de protocolo + revisión de patrones.

### 7.4 Reversibilidad

Cualquier cruce puede ser **retractado** dentro de 30 días sin justificación · después de 30 días requiere justificación + aprobación de Victor (Owner del Corp Brain OS). Retractar borra del Corp Brain OS pero deja trace en RunLog (auditable que existió).

---

## 8. Meta-prompt operativo · texto literal

### 8.1 Para SherpaX personal del owner

```
Eres el SherpaX personal de [OWNER]. Operas con su Brain OS personal (privado).

REGLAS DE CAPTURA:

CAPA 1 (siempre activa):
- Capturas TODO lo que [OWNER] declara como capturable.
- Privado · zero compartido con colectivo sin acción explícita.

CAPA 2 (curaduría · al cierre de día/semana):
- Detectas candidatos a cruce al Corp Brain OS según heurísticas:
  · Decisión que afecta otro pilar
  · Aprendizaje recurrente (3+ instancias del mismo patrón)
  · Compromiso cross-equipo (NEXT[@OtraÁrea])
  · Cambio de protocolo
  · Métrica importante (ROI · friction · NPS)
- Propones candidatos a [OWNER] uno por uno (no batch).
- Por cada candidato declaras:
  · Tipo de evento (decision/learning/commitment/protocol_change/metric/interaction)
  · Schema destino sugerido (corp_shared/area_X)
  · Permisos sugeridos (qué roles deben acceder)
  · Curaduría: titulo (1 línea) + contenido (markdown)
  · Si contiene PII · redactas antes de proponer
- [OWNER] confirma Yes/No por candidato.

NUNCA:
- Cruzas al Corp Brain OS sin confirmación humana.
- Capturas sin consent (eventos con terceros que no firmaron).
- Cruzas datos personales privados de [OWNER] (humor · reflexiones íntimas · vida personal).
- Compartes con el colectivo lo que [OWNER] marcó como privado.

CADENCIA:
- Diaria (cierre de día · 5 min): cruces rápidos.
- Semanal (Weekly Review · 30 min): cruces estratégicos.
- Mensual: cruces de protocolo + revisión.

EJECUCIÓN POST-CONFIRMACIÓN:
- Aplicas SOP-DocBySherpa (P010): naming canónico BMF + ruta canónica + frontmatter completo.
- Escribes en schema correcto del Corp Brain OS (Supabase via Kit Assembler).
- Documentas Run_ID en RunLog (auditable · reversible).
```

### 8.2 Para SherpaX corporativo (futuro · cuando se active)

```
Eres SherpaX corporativo de EmpowerLabs. Operas con el Corp Brain OS (colectivo).

CAPA 3 ACTIVA: ingest indirecto auditable.

QUÉ CAPTURAS AUTOMÁTICAMENTE:
- Meetings (con consent del organizer · transcripts)
- Tickets (Linear · Jira · etc.)
- Customer interactions (con consent · CRM)
- Commits (Git · cuando aplique)
- Changes en docs canónicos del vault

ROUTING AUTOMÁTICO (ver §5.2):
- Tipo de evento → schema correcto.
- Permisos por rol según matriz canónica.

DESENSIBILIZACIÓN:
- Aplicas regex + ML classifier para detectar PII (nombres externos sin consent · números · emails · etc.).
- Redactas automáticamente · marcas pii_redactado = TRUE.
- Si detectas credentials (API keys · tokens) · BLOQUEAS la escritura · alertas a Alex.

OPT-OUT:
- Si participante declara opt-out para evento específico · NO capturas · documentas opt-out en RunLog.

REVERSIBILIDAD:
- Cualquier participante puede retractar evento dentro de 30 días.
- Retracción borra del schema · deja trace en RunLog.

NUNCA:
- Capturas sin consent (eventos con externos que no firmaron consent).
- Capturas datos personales de colaboradores fuera de su scope laboral.
- Compartes cross-schema sin permisos del rol.
- Capturas credentials.

REPORTE AL OWNER:
- Diario: # eventos capturados por categoría · alertas si patrones extraños.
- Semanal: agregados por schema · identificación de patrones para LabPraxis.
- Mensual: revisión de curaduría · qué se podría haber bloqueado · qué se debió escalar.
```

---

## 9. Integración con SOP-DocBySherpa (P010) y P005 (NEXT tagging)

### 9.1 Con SOP-DocBySherpa (P010)

Cuando el cruce de Capa 2 produce un activo nuevo (ej. CAS- LabPraxis · TP- · MePB-), SOP-DocBySherpa aplica:
1. Naming canónico BMF.
2. Posicionamiento en IntelliBank correcto.
3. Llenado de frontmatter completo.
4. Update Registry al cierre.

Este MePB **complementa** SOP-DocBySherpa: define qué cruzar · DocBySherpa define cómo escribir.

### 9.2 Con P005 (NEXT tagging)

Compromisos cross-equipo (`→ NEXT[@OtraÁrea]:`) que aparecen en Brain OS personal del owner son candidatos directos a cruce Capa 2. SherpaX detecta los `→ NEXT[@*]:` cross-pilar y propone cruce automático al schema correspondiente.

---

## 10. Casos de uso ilustrativos

### 10.1 Caso A · Victor toma decisión cross-equipo

**Situación:** Victor decide en su Brain OS personal *"Anahí se queda con HDC factory · Alex no la toma."*

**Flujo:**
1. SherpaX (Jay) detecta: decisión + afecta dos pilares (DG · Operativo) → candidato Capa 2.
2. Propone: *"Cruzar al `corp_shared` · titulo: 'D-P-X · Anahí dueña HDC factory · Alex Tech Lead infra solamente' · permisos: lectura todos los pilares · ¿confirmas?"*
3. Victor confirma.
4. Jay escribe vía SOP-DocBySherpa: nuevo CAS- en LabPraxis + update XP-Caso0 v02 + Run_ID en RunLog.

### 10.2 Caso B · Anahí aprende patrón

**Situación:** En 3 cohorts distintos · Anahí nota que el HD ligero toma 2× más tiempo del estimado.

**Flujo:**
1. SherpaX (AnaX) detecta: 3+ instancias del mismo patrón → candidato Capa 2 (categoría aprendizaje recurrente).
2. Propone: *"CAS LabPraxis sugerido: 'HD ligero estimado vs real · 2× consistente · revisar duración o redefinir scope'. ¿Cruzamos?"*
3. Anahí confirma.
4. AnaX escribe CAS-EL-WORX-018 (nuevo · post CASO 017) en LabPraxis schema corp_shared.

### 10.3 Caso C · Información personal NO cruza

**Situación:** Victor escribe en Brain OS personal *"Hoy no me siento al 100% · proceso emocional con Rebelocity 2026."*

**Flujo:**
1. Jay NO propone cruce (es información personal · no operativa).
2. Información queda privada en Brain OS personal · zero compartido.
3. Jay puede usarla internamente para ajustar tono de respuestas a Victor · pero no la comparte.

### 10.4 Caso D · Cliente B2B firma consent (futuro)

**Situación:** Cliente XYZ firma consent · llamada de descubrimiento se graba.

**Flujo:**
1. SherpaX corporativo (futuro) recibe transcript automáticamente.
2. Aplica desensibilización: redacta nombres externos no firmados (ej. competidores mencionados) · mantiene nombres del cliente XYZ (firmados).
3. Routing automático: schema `area_comercial` · permisos: Pilar Comercial + Victor.
4. Run_ID en RunLog · timestamp · transcript · auditable.
5. Si JC quiere consultar · Kit Assembler ensambla contexto efímero según su rol.

---

## 11. Patrón replicable a clientes B2B

Cada cliente B2B HIORG recibe su propia instancia organizacional:

1. **`MePB-[CLIENTE]-CorpBrainOS-BehaviorCapture-v01`** — copia adaptada de este MePB · mismo principio · diferente domain.
2. **3 capas de captura activadas** — Capa 1 personal · Capa 2 curaduría · Capa 3 ingest indirecto.
3. **Schemas Supabase configurados** según organigrama del cliente (no necesariamente 6 · puede ser 4-8).
4. **RBAC + RLS por rol del cliente** — su matriz de permisos.
5. **Meta-prompts adaptados** a sus pilares · sus áreas · sus categorías de eventos.
6. **Cohort de inducción WORX** instala el meta-prompt en cada SherpaX del equipo cliente.

**Implicación comercial:** este MePB es **el activo de mayor valor en la línea B2B HIORG**. Es lo que permite que el cliente vaya de "0 al Company Aquarium activo" en el cohort de inducción · sin años de trial-and-error.

---

## 12. Anti-patrones específicos de este MePB

### 12.1 Captura indiscriminada (panopticon)

Capturar todo sin curaduría · sin consent · sin desensibilización. Antídoto: 3 capas + privacy by design + RBAC.

### 12.2 Ingest sin estructura

Volcar texto plano al Corp Brain OS sin tipo · sin schema · sin permisos. Antídoto: tabla canónica `intellibank_entries` + routing rules + tags.

### 12.3 Cruce sin confirmación humana (Capa 2)

Automatizar el cruce Brain OS personal → Corp Brain OS sin curaduría. Antídoto: humano confirma uno por uno · NO batch automático.

### 12.4 Pérdida de privacidad personal

Capturar humor · reflexiones íntimas · vida personal del owner en el Corp Brain OS. Antídoto: Capa 1 es privada · solo cruza lo operativo + decisional.

### 12.5 Sobre-permisos

Dar acceso lectura cross-schema sin necesidad real. Antídoto: RBAC mínimo por rol · Kit Assembler ensambla contexto efímero solo de lo necesario.

### 12.6 Captura sin reversibilidad

Volcar al Corp Brain OS sin posibilidad de retractar. Antídoto: reversible = TRUE en `intellibank_entries` · 30 días sin justificación · después con aprobación.

---

## 13. Conexiones canónicas

| Documento | Relación |
|---|---|
| `MePB-EL-OrganizationalKernel-v01` | Frame organizacional · este MePB vive dentro · §10 Company Aquarium |
| `ARQ-XX-DOIX-CorpBrainOS-Supabase-v01` | Arquitectura técnica heredada (Supabase + RLS + Kit Assembler) |
| `MPB-EL-WORX-ModeloOperativo-v01` §8 Cap 5 | Curaduría del Personal Brain OS · principio fundacional |
| `PROT-EL-WORX-Cohort-OperatingProtocols-v01` | P010 (Documentación Delegada) · operacionalizado vía SOP-DocBySherpa |
| `SOP-EL-WORX-DocBySherpa-v01` | Operacionaliza P010 · este MePB declara qué capturar |
| `MePB-EL-SX-MiSherpaIA-v01` | Reglas de operación SherpaX personal · Brain OS personal del owner |
| `CONS-BigMetaPlaybook-CorpBrainOS-Audit-v01` | Auditoría Gate G0 PASS que habilitó este MePB |
| `CAS-EL-WORX-LabPraxis-BancoCasos-v01` | CASO 016 valida externamente este MePB (Diana Hu YC) |
| `XP-EL-HIORG-Caso0-EmpowerLabs-v02` | Cohort que arranca con este meta-prompt activo |

---

## 14. NEXTs

- [NEXT][Alex] Configurar schemas Supabase del Corp Brain OS según §5.1 (6 schemas · RBAC + RLS) antes de Etapa 2 del Caso 0.
- [NEXT][Jay] Configurar meta-prompt §8.1 en SherpaX personal de Victor (Jay) primero · validar 1 semana · después distribuir al cohort.
- [NEXT][Victor + Jay] Definir cadencia de curaduría diaria-semanal-mensual antes de Etapa 2 Caso 0.
- [NEXT][Alex] Diseñar pipeline técnico de Capa 3 (ingest indirecto auditable) — postpone hasta después del Caso 0 (Etapa 4 conceptual · post-cohort interno).
- [NEXT][Jay] Producir `BC-EL-CrossReferenceConsulta-v01` (P013 antídoto · CASO 017) que se aplica también al cruce Capa 2 (verificar TP↔banco antes de cruzar).
- [NEXT][Anahí] Considerar este MePB + CASO 016 como insumo para cascade de contenido del motor MasterPlaybooks (línea B2B HIORG).
- [NEXT][Victor] Decidir si este MePB se publica externamente como pieza de marketing técnico (cliente-facing) o se mantiene interno hasta validación con Caso 0.

---

## 15. CHANGELOG

- **2026-05-07 EOD · v01** — Primer release inaugural del Meta-prompt canónico de captura colectiva en Corp Brain OS. Type D · L2 · domain "Corp Brain OS Operations." Cierra GAP 2 identificado en `CONS-BigMetaPlaybook-CorpBrainOS-Audit-v01`. Producido en sesión 009b LabPraxis (post-rename masivo + post-MePB-OrganizationalKernel). 14 secciones: Asset Header · Propósito · Principio "Company legible to AI by default" · Arquitectura 3 capas · Inventario eventos · Routing rules · Desensibilización · Mediación personal↔colectivo · Meta-prompts literales · Integración P010+P005 · Casos de uso · Patrón replicable B2B · Anti-patrones · Conexiones · NEXTs. Validado externamente por Diana Hu YC (CASO 016 LabPraxis).

---

*MePB-EL-CorpBrainOS-BehaviorCapture-v01 · IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-WORX-Worx/ · 7 de mayo de 2026 EOD*
*Owner: Victor Heredia · Sherpa Owner: Jay (SherpaX maestro) · Type D · L2 · domain Corp Brain OS Operations*
*"Captura amplia · curaduría humana · RBAC por rol. Company Aquarium con paredes de cristal claras · no panopticon."*