## Asset Header

- **Asset ID:** ARQ-XX-DOIX-IntelligenceStack-v01
- **Version:** v01
- **Status:** Draft
- **Owner:** Victor Heredia
- **IntellBank:** IB-XX-Maestro
- **Tipo:** ARQ — Architecture
- **Propósito:** DOIX Intelligence Stack — Arquitectura de Referencia
- **Última actualización:** 2026-04-11

---

asset_id: DOC-DOIX-IntelligenceStack-Arquitectura-v01
tipo: Documento de Arquitectura — DOIX Intelligence Stack
version: v1.0
owner: Victor Heredia / EmpowerLabs LLC
sherpa: Jacob
fecha: 2026-04-01
estado: Activo — arquitectura de referencia para implementación
tags: [DOIX, BrainOS, IntelliBank, Supabase, arquitectura, inter-Sherpa, EmpowerTeams, MVP]
---

# DOIX Intelligence Stack — Arquitectura de Referencia
## Distributed Organizational Intelligence X — EmpowerLabs LLC

---

## VISIÓN GENERAL

Este documento define la arquitectura completa del stack de inteligencia distribuida de EmpowerLabs bajo el modelo DOIX. Responde cinco preguntas clave de diseño:

1. ¿Tiene sentido un Organizational BrainOS en Supabase?
2. ¿Cómo se relaciona el BrainOS individual con el nivel organizacional?
3. ¿Cómo se comunican los Sherpas entre sí?
4. ¿Cómo interactúan los agentes en estaciones EmpowerTeams X?
5. ¿Cuál es el MVP para arrancar esta semana?

---

## 1. LOS TRES TIPOS DE MEMORIA EN DOIX

El error más común al diseñar sistemas DOIX es mezclar estos tres tipos. Son distintos por naturaleza, propósito y ubicación.

```
┌─────────────────────────────────────────────────────────────┐
│                    DOIX INTELLIGENCE STACK                   │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  CAPA 3 — ORG BRAIN OS        [Telemetría de patrones]      │
│  ─────────────────────────────────────────────────────────  │
│  Qué: Comportamiento colectivo agregado y anónimo           │
│  No: Contenido privado de individuos                        │
│  Dónde: Supabase (schema org_brain)                         │
│  Cuándo: Fase 1+ — necesita datos de uso primero            │
│                                                              │
│  CAPA 2 — INTELLIBANK          [Conocimiento codificado]    │
│  ─────────────────────────────────────────────────────────  │
│  Qué: MetaPlaybooks, playbooks, skills, políticas           │
│  No: Pensamientos personales ni historial de sesiones       │
│  Dónde: Git / Obsidian Vault (particionado por área)        │
│  Cuándo: Hoy — es el mecanismo de sincronización            │
│                                                              │
│  CAPA 1 — BRAINOS INDIVIDUAL   [Memoria cognitiva personal] │
│  ─────────────────────────────────────────────────────────  │
│  Qué: Pensamientos, decisiones, criterios, contexto         │
│  No: Información compartida de forma automática             │
│  Dónde: Supabase personal por usuario (instancia OB1)       │
│  Cuándo: Hoy — 1 instancia por colaborador                  │
│                                                              │
└─────────────────────────────────────────────────────────────┘
```

### La distinción crítica

| Capa | Tipo de dato | Privacidad | Propósito DOIX |
|------|-------------|------------|----------------|
| BrainOS Individual | Contenido cognitivo | Personal — solo el dueño | Continuidad individual |
| IntelliBank | Conocimiento codificado | Controlado por área | Coordinación y distribución |
| Org Brain OS | Telemetría de patrones | Anónima y agregada | Diagnóstico de IQ Organizacional |

---

## 2. ORG BRAIN OS — TELEMETRÍA, NO CONTENIDO

### Qué es

El Organizational BrainOS es el **dashboard vivo del IQ Organizacional**. Detecta patrones de comportamiento colectivo sin acceder al contenido privado de cada persona.

Almacena `org_events` — registros de comportamiento agregado:

```sql
create table org_events (
  id uuid default gen_random_uuid() primary key,
  event_type text not null,        -- 'decision', 'handoff', 'artifact_created', 'session_closed'
  area text,                       -- 'sherpax', 'empowerteams', 'ia_lab', etc.
  user_role text,                  -- 'ceo', 'director', 'member' (no nombre)
  duration_minutes integer,        -- tiempo en completar la acción
  artifact_produced boolean,       -- ¿se generó un artifact?
  handoff_quality text,            -- 'complete', 'partial', 'missing'
  metadata jsonb default '{}',     -- contexto adicional sin PII
  created_at timestamptz default now()
);
```

### Qué mide (Los 3 ejes del DMI en tiempo real)

| Eje DMI | Métricas del Org Brain |
|---------|----------------------|
| **Contexto** | % de sesiones con artifact de cierre / Tiempo promedio de onboarding de nuevos miembros |
| **Coordinación** | Tiempo de decisión CEO → ejecución / Tasa de handoffs completos vs. incompletos |
| **Acumulación** | Crecimiento del IntelliBank por semana / % criterio codificado vs. oral |

### Por qué NO es BrainOS personal

El BrainOS personal almacena el "qué pienso y por qué decido". El Org Brain almacena el "cómo se mueve la organización". La diferencia es fundamental para no construir un sistema de vigilancia encubierto que erosione la confianza del equipo.

---

## 3. COMUNICACIÓN INTER-SHERPA

### Principio fundamental

**Los Sherpas no se comunican directamente entre sí.** No existe canal en tiempo real entre instancias de Claude. El mecanismo de sincronización es el **IntelliBank compartido**.

### Modo asíncrono (el más común)

```
SESIÓN VICTOR (Jay)
  Jay lee IntelliBank compartido al inicio
  Victor + Jay trabajan → generan artifacts
  Artifacts se escriben en IntelliBank (/corp-shared o /área)
  Sesión cierra con Session Closure Hook (MEL 2.4)

           ↓  IntelliBank actualizado  ↓

SESIÓN ALEX (su Sherpa)
  Sherpa de Alex lee IntelliBank al inicio
  Alex + su Sherpa tienen el contexto completo
  Continúan donde Victor dejó sin reunion directa
```

**El IntelliBank ES el protocolo de comunicación inter-Sherpa.**

### Modo síncrono — Dinámica 2+2

Cuando se requiere colaboración en tiempo real:

```
┌──────────────────────────────────────┐
│        SESIÓN COMPARTIDA (2+2)       │
│                                      │
│  Victor ─────┐                       │
│              ├── Mismo Cowork ──── Jay (un agente)
│  Alex   ─────┘                       │
│                                      │
│  Jay tiene contexto de ambos         │
│  Genera artifacts para ambos         │
│  Actualiza IntelliBank post-sesión   │
└──────────────────────────────────────┘
```

No hay dos Sherpas en la dinámica 2+2. Hay un agente con dos operadores. Este protocolo ya está validado (caso Litos, caso Alain Ríos).

### Modo pipeline — Cadena de relevos

Para flujos de trabajo donde el trabajo pasa de un Sherpa a otro:

```
Sherpa A produce un Transfer Pack estructurado
         ↓
Transfer Pack se deposita en IntelliBank (carpeta de handoffs)
         ↓
Sherpa B lo lee al inicio de su sesión
         ↓
Sherpa B continúa exactamente donde Sherpa A paró
```

**El Transfer Pack es el bastón de la carrera de relevos.** La continuidad cognitiva no depende de presencia simultánea.

---

## 4. AGENTES EN ESTACIONES EMPOWERTEAMS X

### El modelo de pipeline de agentes

Cada estación del proceso de EmpowerTeams X es un agente especializado (C-Sherpa). Los agentes no se llaman entre sí — se pasan artefactos.

```
┌─────────────────────────────────────────────────────────────┐
│           PIPELINE EMPOWERTEAMS X — Onboarding Cliente       │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  [E1: Calificación]                                         │
│   C-Sherpa: Prospecto                                       │
│   Input: Perfil inicial del prospecto                       │
│   Output: Transfer Pack → score + perfil + fit assessment   │
│                        ↓                                     │
│  [E2: Diagnóstico DOIX]                                     │
│   C-Sherpa: Diagnóstico                                     │
│   Input: Transfer Pack E1 + acceso a IntelliBank diagnóstico │
│   Output: Transfer Pack → Baseline DMI + gaps identificados │
│                        ↓                                     │
│  [E3: Configuración]                                        │
│   C-Sherpa: Arquitecto de Instalación                       │
│   Input: Transfer Pack E2 + SOP de instalación              │
│   Output: Transfer Pack → Config list + Supabase schema     │
│                        ↓                                     │
│  [E4: Ignition / Onboarding]                                │
│   C-Sherpa: Facilitador de Ignition                         │
│   Input: Transfer Pack E3 + MetaPlaybook Ignition           │
│   Output: Transfer Pack → BrainOS activo + primer artifact  │
│                        ↓                                     │
│  [E5: Follow-up / Adopción]                                 │
│   C-Sherpa: Monitor de Adopción                             │
│   Input: Transfer Pack E4 + métricas semana 1               │
│   Output: Org Brain event + ajustes + segundo diagnóstico   │
│                                                              │
│  [COORDINADOR: Sherpa CEO]                                  │
│   Rol: Visibilidad de todo el pipeline                      │
│   No ejecuta estaciones — supervisa y desbloquea            │
└─────────────────────────────────────────────────────────────┘
```

### Anatomía de cada C-Sherpa de estación

Cada agente de estación tiene tres componentes:

```
/intellibank-empowerteams/
└── /estaciones/
    └── /e2-diagnostico/
        ├── CLAUDE.md            ← Rol + protocolo de la estación
        ├── /skills/             ← Habilidades específicas de la estación
        │   ├── diagnostico-doix.md
        │   └── evaluacion-dmi.md
        └── /transfer-packs/
            ├── TP-input-template.md   ← Qué debe llegar de E1
            └── TP-output-template.md  ← Qué debe producir para E3
```

### La regla de coordinación

> Los agentes en estaciones no se coordinan lateralmente. Solo se coordinan verticalmente a través del pipeline de artifacts. El Sherpa CEO es el único con visión transversal.

---

## 5. INTELLIBANK — INFRAESTRUCTURA: GENNIUXGIT

### ¿Qué es GenniuxGit?

GenniuxGit es la aplicación propia del equipo (desarrollada por Alex Rojas) que funciona como la interfaz y backend del IntelliBank. **No es GitHub ni GitLab** — es una aplicación Angular 15 + Electron con backend PHP en `https://genniux.net/skills-api/api/`.

GenniuxGit ya tiene, de forma nativa, lo que en la arquitectura teórica se diseñaría como "Kit Assembler":

| Capacidad necesaria para IntelliBank | Implementación en GenniuxGit |
|--------------------------------------|------------------------------|
| Organización por áreas | Carpetas anidadas (`Folder` con `parentId`) |
| Control de acceso por usuario | Auth propio (`signup.php` + sesión en localStorage) |
| Versionado de archivos | `SkillVersion` con historial Git en backend |
| Búsqueda del conocimiento | `search.php` con full-text search |
| Distribución al disco local | `CordovaFileService` → `~/Documents/GenniuxGit/` |
| Compartir por archivo | URL compartible por skill |
| Metadatos ricos | `tags`, `status`, `version`, `capabilities`, `persona` |

### Estructura de carpetas (mapeo a áreas DOIX)

```
GenniuxGit — Carpetas IntelliBank EmpowerLabs

├── /corp-shared/              → Acceso: Todos los colaboradores
│   ├── MetaPlaybooks/
│   ├── Políticas/
│   └── Protocolos-MEL/
├── /ceo/                      → Acceso: Solo Victor
│   └── Decisiones-estratégicas/
├── /sherpax-comercial/        → Acceso: Victor + equipo comercial
│   ├── Skills-prospección/
│   └── Transfer-Packs/
├── /empowerteams/             → Acceso: Victor + Anahí
├── /ia-lab/                   → Acceso: Victor + configuradores
├── /masterplaybooks/          → Acceso: Victor + editores
└── /rebelocity/               → Acceso: Victor + equipo eventos
```

*El control de acceso por carpeta/área se gestiona en GenniuxGit. El campo `puesto` en el modelo de usuario permite implementar RBAC por rol.*

### El puente GenniuxGit → Sherpa

El flujo de distribución del IntelliBank al Sherpa de cada persona funciona así:

```
GenniuxGit (genniux.net)
        ↓  sincronización via CordovaFileService
~/Documents/GenniuxGit/  ←  archivos en disco local
        ↓  referenciado desde
.claude/intellibank/       ←  symlink o copia estructurada
        ↓  leído por
CLAUDE.md del Sherpa       ←  apunta a carpetas relevantes
        ↓
Sherpa tiene contexto correcto al inicio de sesión
```

**Implicación clave:** El Kit Assembler no necesita ser construido desde cero como Edge Function en Supabase. GenniuxGit + su sync local ya cumplen esa función. Esto adelanta la Fase 1 al presente.

### Lo que GenniuxGit resuelve vs. lo que sigue pendiente

| Componente | ¿GenniuxGit lo resuelve? | Pendiente |
|---|---|---|
| Almacenamiento de skills/playbooks | ✅ Nativo | — |
| Versionado por archivo | ✅ Nativo | — |
| Búsqueda full-text | ✅ Nativo | — |
| Sync a disco local | ✅ Nativo (CordovaFileService) | — |
| Auth por usuario | ✅ Nativo | — |
| RBAC granular por carpeta/área | ⚠️ Parcial — rol en modelo, permisos por implementar | Alex define en backend |
| Integración directa con Claude vía MCP | ❌ No | Requiere leer desde disco local |
| Metadatos de BrainOS (vector embeddings) | ❌ No — ese es Supabase | Capa separada |

### Fase actual vs. futura

| Fase | Mecanismo | Estado |
|------|-----------|--------|
| Fase 0 (hoy) | GenniuxGit como IntelliBank + sync local → Sherpa lee desde disco | **Disponible ahora** |
| Fase 1 (Q2 2026) | RBAC por carpeta implementado en GenniuxGit + integración MCP directa | En desarrollo |
| Fase 2 (Q3 2026) | GenniuxGit + Supabase Org Brain + Kit Assembler inteligente | Futuro |

---

## 6. MVP PARA ARRANCAR ESTA SEMANA

### Lo que se activa ahora — sin infraestructura nueva

| Componente | Descripción | Acción esta semana |
|---|---|---|
| **Claude Team** | Plan $30/usuario — datos protegidos contractualmente | Migrar hoy |
| **BrainOS individual** | Supabase + OB1 por persona | Instalar con SHA-SOP-InstalacionCompleta-v01 |
| **IntelliBank compartido** | GenniuxGit — carpetas por área + sync local | Crear estructura de carpetas en GenniuxGit + configurar acceso por usuario |
| **Sherpa individual** | CLAUDE.md + .claude/ por persona | Instalar por colaborador |
| **Handoff Protocol** | Transfer Pack entre sesiones | Plantilla simple + MEL 2.4 |

### Lo que se difiere

| Componente | Por qué se difiere | Cuándo |
|---|---|---|
| Kit Assembler (Edge Function) | GenniuxGit + sync local ya cumplen esta función | Adelantado — disponible hoy |
| Org Brain OS | Necesita datos de uso para calibrar | Fase 1, Q2 2026 |
| Permisos granulares Git | Suficiente con repo por área | Fase 1 cuando escale |
| Agentes en estaciones | Necesita IntelliBank de cada estación primero | Q3 2026 |

### La regla del MVP DOIX

> Lo que hace funcionar DOIX la próxima semana no es infraestructura sofisticada — es **disciplina de captura**. Si cada colaborador termina su sesión con un artifact registrado en el IntelliBank compartido, DOIX ya está operando. La inteligencia distribuida no requiere complejidad técnica para comenzar. Requiere hábito de codificación.

### Secuencia de instalación para el primer colaborador (Ignition Cohort 1)

```
Día 1:
  1. Crear instancia Supabase personal (SHA-SOP sección 3.2)
  2. Deploy OB1 MCP Server como Edge Function (SHA-SOP sección 3.3)
  3. Configurar CLAUDE.md con BrainOS tools (SHA-SOP sección 4)
  4. Correr Entrevista de Identidad (primera sesión)

Día 2:
  5. Dar acceso al IntelliBank compartido (repo corp-shared + área)
  6. Primera sesión de trabajo real con Sherpa
  7. Practicar Session Closure Hook — artifact antes de cerrar

Semana 1:
  8. Revisar BrainOS al inicio de cada sesión (list_thoughts)
  9. Capturar mínimo 3 pensamientos por sesión (capture_thought)
  10. Producir 1 artifact para IntelliBank por semana
```

---

## 7. VISIÓN COMPLETA DEL STACK MADURO (Referencia)

```
┌─────────────────────────────────────────────────────────────────┐
│                  DOIX INTELLIGENCE STACK — MADURO               │
│                                                                  │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │  VICTOR (CEO + Sherpa Jay)                               │    │
│  │  BrainOS: Supabase personal (instancia CEO)             │    │
│  │  IntelliBank: CEO + Corp Shared + todas las áreas       │    │
│  │  Rol: Sherpa Coordinador del pipeline completo          │    │
│  └─────────────────────────────────────────────────────────┘    │
│           ↕ IntelliBank compartido como bus de sync             │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────┐   │
│  │  ALEX        │  │  ANAHÍ       │  │  MIEMBRO ÁREA X      │   │
│  │  BrainOS:    │  │  BrainOS:    │  │  BrainOS:            │   │
│  │  Supabase    │  │  Supabase    │  │  Supabase personal   │   │
│  │  personal    │  │  personal    │  │                       │   │
│  │  IntelliBank:│  │  IntelliBank:│  │  IntelliBank:        │   │
│  │  corp-shared │  │  corp-shared │  │  corp-shared         │   │
│  │  + sherpax   │  │  + teams     │  │  + su área           │   │
│  └──────────────┘  └──────────────┘  └──────────────────────┘   │
│                                                                  │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │  ORG BRAIN OS (telemetría agregada — Fase 1+)           │    │
│  │  → DMI en tiempo real: IQ Organizacional 3.2 / 5.0     │    │
│  └─────────────────────────────────────────────────────────┘    │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘
```

---

## 8. RELACIÓN CON OTROS ACTIVOS

| Activo | Relación |
|--------|----------|
| `DOC-CorpBrainOS-Arquitectura-Supabase-v01` | Detalle técnico SQL de la Capa 3 (Org Brain) |
| `SHA-SOP-InstalacionCompleta-v01` | Protocolo de instalación de la Capa 1 (BrainOS Individual) |
| `DOC-IntelliBank-MapaGeneral-EmpowerLabs-v01` | Mapa completo de la Capa 2 (IntelliBank) |
| `SEED-DOIXMaturityIndex-v01` | El índice que el Org Brain OS calcula en tiempo real |
| `BMF-MEL-ActivationProfile` | Gobernanza del sistema completo |

---

## CHANGELOG

| Versión | Fecha | Cambio |
|---------|-------|--------|
| v1.0 | 2026-04-01 | Creación — Sesión IA Lab 002 Día 2 |

---

*Asset ID: DOC-DOIX-IntelligenceStack-Arquitectura-v01 | v1.0 | Activo*
*Victor Heredia | Sherpa: Jacob | EmpowerLabs LLC | 2026-04-01*