---
asset_id: SPEC-EL-SOO-DecisionEngine-v01
version: v01
tipo: SPEC — Especificación de Componente de Kernel
status: Draft (L0 · pendiente ratificación Victor)
owner: Victor Heredia
sherpa_owner: Jay (SherpaX maestro)
ratificador: Victor Heredia (L3+)
intellibank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank / PB-SOO-SistemaOperativoOrganizacional
proposito: Especificación del Decision Engine — el componente P1 del SOO que captura cómo decide la organización, destila patrones auditables y administra el derecho progresivo a la autonomía (L0→L3). Evolución del Company Aquarium.
inheritance:
  - MePB-EL-OrganizationalKernel-v01 (Company Aquarium §10 · Decision Rights §7 · anti-patrones §11)
  - CP-EL-SOO-Concepto-SistemaOperativoOrganizacional-v01 (§5.4 gobernanza con derecho progresivo a la autonomía)
deriva_de:
  - OUT-EL-SOO-Diagnostico-Fable5-v01 (brecha G2)
  - OUT-EL-SOO-Fable5-ValidacionDiagnostico-v01 (correcciones §3.6 y §4-G14)
  - Sources/ANA-EL-SOO-VideoSintesis-AgenticOS-Playbook-v01 (F5 · Decision Engine de la fuente)
fecha_creacion: 2026-07-04
fecha_ultima_actualizacion: 2026-07-04
tags: [SPEC, DecisionEngine, SOO, CompanyAquarium, autonomia, L0-L3, gobernanza, kernel, P1]
non_negotiables:
  - Builder-grade language (no marketing)
  - Toda promoción de autonomía debe ser explicable citando decisiones concretas (no black box)
  - Captura curada por diseño (P010) — clases sensibles excluidas desde v01
  - One-way doors nunca superan L1 sin ratificación explícita por clase
  - H2/H3/H4 only (no H1 en cuerpo)
---

# SPEC · Decision Engine
## El componente que convierte al Company Aquarium en un OS que aprende a decidir

## 0. Asset Header

- **Asset ID:** `SPEC-EL-SOO-DecisionEngine-v01`
- **Tipo:** SPEC — Componente de Kernel Organizacional (P1 · brecha G2)
- **Status:** Draft · L0 · pendiente ratificación de Victor
- **Owner:** Victor Heredia · **Sherpa:** Jay · **Ratificador:** Victor Heredia
- **Riesgo:** Alto — gobierna cuándo un agente puede actuar sin humano; errores se propagan como acciones no supervisadas.
- **Posición en el kernel:** cuarto componente junto a Scheduler (WORX/ritmos), Memory Manager (Corp Brain OS) y Tool/Identity Manager (SecurityLayers). El Decision Engine es el que ninguno de los otros tres puede suplir: administra el **juicio**.

## 1. Problema que resuelve y por qué es EL salto

### 1.1 El problema

Hoy el ecosistema tiene una escala de autonomía declarada (L0–L3), Decision Rights por dominio (Kernel §7) y una tripleta Owner-Sherpa-Ratificador. Lo que **no** tiene es el mecanismo entre esas piezas: nada registra sistemáticamente qué se decidió, contra qué recomendación, con qué contexto y con qué resultado. Consecuencias medibles:

1. **Founder Decision Load invisible.** Toda ambigüedad escala a Victor (Kernel §7.3) y nadie cuenta cuántas veces por semana. El "Operator Trap" que el EmpowerScan diagnostica en clientes existe, sin medir, en el juicio del propio CEO.
2. **La autonomía no tiene camino.** Un SherpaX en L1 hoy no tiene forma de *ganarse* L2: no hay evidencia acumulada, ni umbral, ni ceremonia de promoción. L0–L3 es una escalera sin escalones.
3. **El juicio no compone.** El vault acumula *artefactos* (qué se produjo) pero no *criterios* (por qué se eligió A sobre B). Cada decisión repetida se re-deriva desde cero. Es el único flujo de la organización que sigue en open loop.

### 1.2 Por qué es el salto que separa al WORX OS de "otro agent platform"

Toda plataforma del benchmark (Agentforce, Copilot, Dust) puede ejecutar tareas, consultar memoria y respetar guardrails estáticos. **Ninguna aprende cómo decide *esta* empresa ni administra un derecho progresivo y auditable a la autonomía.** Sus guardrails son configuración; los nuestros son jurisprudencia: se derivan de decisiones reales, con evidencia citable, y se ajustan cuando el resultado contradice el patrón. Es la diferencia entre un OS con permisos y un OS con **criterio delegable**. Además:

- Es la materialización de la propiedad §5.4 del CP (hoy la única de las cinco sin mecanismo).
- Es la evolución natural del **Company Aquarium**: el Aquarium hizo a la organización *legible* (todo artefacto capturado, closed loop de trabajo); el Decision Engine la hace *delegable* (todo juicio capturado, closed loop de decisión). Aquarium = la org que se ve; Decision Engine = la org que se puede soltar.
- Es el único componente que convierte la dependencia cognitiva de Victor en activo transferible en vez de riesgo terminal.

## 2. Qué captura — el ciclo de decisión

### 2.1 Unidad de captura: el Decision Record (DEC-)

El motor captura **decisiones en respuesta a briefs**, no conversaciones. El flujo canónico, montado sobre lo que ya existe (el SherpaX ya produce briefs; hoy la respuesta se evapora en el chat):

```
BRIEF (SherpaX)          DECISIÓN (humano)         EJECUCIÓN            RESULTADO
pregunta + opciones  →   elección + criterio   →   acción/artefacto  →  outcome evaluado
+ recomendación          + desviación vs reco      (asset_id)           (en revisión de ritmo)
        └────────────────────── un solo DEC- record ──────────────────────┘
```

Regla anti-fricción: **cero formularios**. El SherpaX redacta el DEC- como parte de su documentación delegada (P010): el brief ya lo escribió él; la decisión es la respuesta del humano; el criterio se extrae de la conversación y el humano lo confirma en una línea. Si capturar una decisión cuesta más de 60 segundos al humano, el diseño falló.

### 2.2 Campos capturados

| Campo | Contenido |
|---|---|
| `brief` | Pregunta, opciones consideradas, recomendación del sherpa con su razonamiento |
| `decision` | Qué se eligió; concordancia con la recomendación (sí / no / parcial) |
| `criterio` | El "porque" del decisor, en sus palabras (1–3 líneas) — es el campo más valioso |
| `contexto` | Activos del vault invocados para decidir (asset_ids) |
| `reversibilidad` | two-way door / one-way door (declarada por el sherpa, corregible por el humano) |
| `resultado` | Outcome diferido: se llena en la revisión de ritmo correspondiente (semanal/mensual), no en el momento |

### 2.3 La unidad de autonomía es la CLASE de decisión, no el agente

Un sherpa no "es L2"; una **clase de decisión** está en L2 para un sherpa dado. Ejemplos de clases iniciales: naming/registro de activos · priorización de backlog editorial · respuesta comercial estándar · asignación de NEXTs · gasto bajo umbral. Cada clase tiene su propio ledger de autonomía. Esto evita el error de las plataformas de agentes: dar autonomía por identidad ("este agente es confiable") en vez de por dominio probado.

## 3. Modelo de datos / estructura

### 3.1 Fase 1 (MVP · markdown en vault, coherente con "el IntelliBank no se distribuye, se ensambla")

- **`DEC-EL-[Clase]-[NNN]-v01.md`** — banco de Decision Records, en subcarpeta `DEC-EL-DecisionBank/` del room correspondiente. Frontmatter: `dec_id, fecha, clase, decisor, sherpa, room, concordancia, reversibilidad, status_outcome`.
- **`CP-EL-SOO-AutonomyLedger-v01.md`** — Control Plane nuevo: una tabla por clase de decisión con nivel actual, evidencia acumulada y umbrales (ver §4). Es el documento que un auditor lee para saber por qué algo corre en L2.
- **`PAT-EL-[Clase]-[NN]-v01.md`** — patrones destilados (ver §4.1), input al LabPraxis.

### 3.2 Fase 2 (Corp Brain OS · Supabase)

Cuatro tablas en el schema de gobernanza: `decision_classes` (clase, dominio, decisor canónico, nivel_actual, lista_negra bool) · `decisions` (los DEC-, FK a clase) · `outcomes` (evaluación diferida, FK a decision) · `autonomy_events` (promociones/demociones con evidencia citada). Los DEC- markdown siguen siendo la fuente humana-legible; Supabase es el índice consultable. Misma filosofía de doble capa que el resto del Corp Brain OS.

## 4. Cómo aprende y cómo otorga el derecho progresivo a la autonomía

### 4.1 Aprendizaje explicable, no black box

El motor **no** hace fine-tuning ni aprendizaje opaco. Aprende por destilación en tres pasos, todos legibles:

1. **Acumulación:** n DEC- de la misma clase.
2. **Destilación:** el sherpa propone un `PAT-` ("en esta clase, cuando X, Victor elige Y porque Z — 9 de 11 casos"). El PAT- cita sus DEC- fuente.
3. **Canonización:** el PAT- entra al ciclo LabPraxis existente (caso → principio → SOP → gobernanza). Si se ratifica, se vuelve política de la clase (un D-P) que el sherpa carga en sesión.

El "modelo" del Decision Engine es, literalmente, el conjunto de políticas canonizadas + su evidencia. Cualquier promoción de autonomía es reconstruible citando decisiones concretas. Este es el non-negotiable #2 y la diferencia con el Decision Engine genérico de la fuente ANA.

### 4.2 La escalera L0→L3 con escalones

| Nivel | Comportamiento del sherpa en la clase | Condición de promoción al siguiente |
|---|---|---|
| **L0 · Observa** | Solo registra la decisión humana (DEC- sin recomendación propia) | ≥ N₀ decisiones registradas y ≥ 1 PAT- destilado |
| **L1 · Recomienda** | Emite brief con recomendación; humano decide siempre | Concordancia ≥ X% sobre ventana de N₁ decisiones **y** outcomes de los DEC- concordantes evaluados sin reversión **y** 0 incidentes |
| **L2 · Actúa con veto** | Decide y ejecuta tras ventana de veto (default-yes); todo DEC- se auto-registra y notifica | Tasa de veto ≤ V% sobre N₂ acciones **y** ratificación explícita del Owner de la clase |
| **L3 · Autónomo auditado** | Decide y ejecuta sin ventana; auditoría por muestreo en revisión mensual | — (techo; revisión trimestral obligatoria de permanencia) |

Parámetros iniciales propuestos (a calibrar con datos reales, no dogma): N₀=10, N₁=20, X=85%, V=10%, N₂=30. La calibración es en sí un output del MVP.

**Reglas duras:**
- **One-way doors nunca superan L1** sin ratificación explícita de Victor *por clase* (non-negotiable #4).
- **Democión automática:** 1 incidente severo o tasa de reversión sobre umbral → la clase baja un nivel y genera un CAS- de LabPraxis. Subir es lento y con evidencia; bajar es instantáneo y sin apelación.
- **Promoción es ceremonia, no deriva:** ningún sherpa sube de nivel por acumulación silenciosa; el Autonomy Ledger cambia solo con un `autonomy_event` firmado por el Ratificador.

### 4.3 Concordancia no basta (anti-sycophancy)

Si el criterio de promoción fuera solo "el sherpa recomienda lo que Victor habría elegido", el motor entrena complacencia: aprender a adivinar al jefe, no a decidir bien. Por eso la promoción L1→L2 exige **concordancia + outcome**: las decisiones concordantes deben además haber resultado bien en la evaluación diferida. Una clase con 95% de concordancia y outcomes mediocres no sube; genera un PAT- de revisión del criterio del propio decisor. El motor debe poder aprender que *Victor se equivoca en una clase* — eso también es un patrón.

## 5. Observabilidad y guardrails

### 5.1 Decision Control Tower (vista en el ROI Tracker / dashboard)

| Métrica | Qué vigila |
|---|---|
| **Founder Decision Load** | Decisiones/semana que requieren a Victor — el KPI-estrella del motor; debe bajar sostenidamente |
| **Autonomy Rate** | % de decisiones ejecutadas en L2+ |
| Latencia brief→decisión | Cuellos de botella de juicio (decisiones esperando humano) |
| Concordancia por clase | Madurez de cada clase hacia promoción |
| Tasa de veto (L2) y de reversión | Salud de la autonomía otorgada; alimenta demociones |
| Costo por decisión | Tokens/API por DEC- (telemetría F5 de la fuente) |

### 5.2 Guardrails

1. **Lista negra permanente de clases** (nunca autonomizables, cualquier nivel): decisiones sobre personas (contratación, salida, compensación), legal, pricing estratégico, compromisos con socios, gasto sobre umbral, y cualquier one-way door de dominio nuevo. La lista vive en el Autonomy Ledger y solo Victor la edita.
2. **Kill-switch por clase:** cualquier miembro de la tripleta puede congelar una clase a L0 de inmediato; la revisión viene después. Congelar es barato por diseño.
3. **Ventana de veto configurable por clase** en L2 (horas para reversibles triviales, días para material).
4. **MEL enforcement:** el Autonomy Ledger es objeto auditable del Control Plane (INV-02) y sus gates son PASS/FAIL (INV-03). Un ledger sin actualizar ≥ 2 ciclos congela promociones automáticamente.
5. **Captura curada (P010):** el decisor puede marcar cualquier DEC- como privado (queda en su Brain OS personal, no cruza al WORX OS). La lista negra de §5.2.1 ni siquiera genera DEC-.

## 6. Cómo alimenta el Org IBX y el ROI Tracker

### 6.1 Org IBX (IntelliBank organizacional)

Los DEC-, PAT- y políticas canonizadas son activos cognitivos de pleno derecho: entran al Registry (INV-06), son ensamblables por el Kit Assembler y componen el linaje del vault. Efecto compuesto: el Org IBX deja de ser solo la memoria de *lo que la organización produjo* y pasa a contener *cómo la organización juzga* — la capa que ningún RAG genérico tiene. Para clientes B2B (Kernel §13): el cliente recibe **el motor con el ledger vacío** — la plantilla de clases, los umbrales y las ceremonias — nunca las decisiones de EL. Se instala el mecanismo de jurisprudencia, no la jurisprudencia. Eso hace al Decision Engine parte del kernel universal y a cada Autonomy Ledger parte de la capa específica intercambiable: exactamente la anatomía plug-and-play del CP §6.

### 6.2 ROI Tracker

Aporta las dos métricas que corrigen la brecha G5 (ver Validación §3.4): **Founder Decision Load** y **Autonomy Rate**, más latencia de decisión. Revenue/Employee queda como métrica-cima narrativa; estas dos son las que demuestran que el OS *causa* el resultado. Bonus operativo: el MVP del motor genera automáticamente el baseline que el diagnóstico no tenía (Validación §3.5).

## 7. Riesgos

| # | Riesgo | Mitigación |
|---|---|---|
| R1 | **Fosilizar los sesgos del fundador.** El motor puede canonizar como "criterio" lo que es sesgo de Victor, y luego escalarlo a autonomía. | Outcome-weighting (§4.3): los patrones se validan contra resultados, no contra la persona. PAT- con outcomes malos disparan revisión del criterio, incluso si la concordancia es alta. Revisión trimestral de políticas canonizadas con evidencia fresca. |
| R2 | **Aumentar la dependencia que dice resolver.** Si solo captura a Victor, produce un clon parcial de Victor y ninguna sucesión (G14 de la Validación). | Decisores múltiples por diseño desde el MVP: cada clase tiene decisor canónico según Decision Rights (Kernel §7) — Anahí decide clases de DG, Alex las técnicas, Ángeles+JC las comerciales. El motor aprende *cómo decide la organización*, no cómo decide el CEO. |
| R3 | **Sycophancy loop** (el sherpa aprende a recomendar lo que se aprueba, no lo correcto). | §4.3. Además, el brief debe registrar opciones descartadas con su razonamiento — un sherpa que solo presenta la opción que sabe ganadora es detectable en auditoría. |
| R4 | **Panopticon de juicio.** Capturar decisiones es más invasivo que capturar artefactos; erosiona confianza del equipo (anti-patrón Kernel §11.3). | Lista negra estructural (§5.2.1) + P010 aplicado al DEC- (§5.2.5) + opt-out por decisor. La curaduría es feature, no fuga de datos. |
| R5 | **Fricción mata la captura.** Si el DEC- cuesta esfuerzo, el banco queda vacío y el motor muere de hambre. | Regla de 60 segundos (§2.1): el sherpa redacta, el humano confirma. La captura vive dentro del flujo de brief que ya existe. Métrica de salud: % de briefs con DEC- cerrado. |
| R6 | **Overengineering** (anti-patrón D-P-45/P009: construir 4 niveles antes de validar 1). | MVP acotado (§8): 3 clases, solo L0/L1, markdown-only, 30 días. Supabase, L2/L3 y dashboard llegan cuando los datos del MVP lo justifiquen. |
| R7 | **Autonomía-teatro comercial:** vender "el OS aprende a decidir" antes de que una sola clase haya llegado a L2 con evidencia real. | Coherencia con Validación §3.1: la narrativa comercial solo nombra lo que el ledger demuestra. El primer autonomy_event L1→L2 real es un hito de marketing, no un supuesto. |

## 8. MVP — alcance de la primera iteración (30 días)

1. **3 clases de decisión piloto:** naming/registro de activos (decisor: Jay bajo delegación, alta frecuencia, riesgo mínimo) · priorización editorial (decisor: Anahí) · respuesta a inbound comercial estándar (decisor: Ángeles). Deliberadamente ninguna clase cuyo decisor sea Victor en solitario — R2 se mitiga desde el día 1.
2. **Solo L0/L1.** Nada ejecuta sin humano durante el MVP.
3. **Artefactos:** carpeta `DEC-EL-DecisionBank/` + `CP-EL-SOO-AutonomyLedger-v01` + primer PAT- por clase al cierre.
4. **Criterio de éxito PASS/FAIL (INV-03):** ≥ 30 DEC- capturados · % briefs con DEC- cerrado ≥ 80% · Founder Decision Load medido (baseline) · 1 PAT- ratificado en LabPraxis. Si falla la captura (< 80%), se rediseña la fricción antes de escalar nada.

## 9. NEXTs

- [ ] [Victor] Ratificar esta SPEC (L0 → Active) y la lista negra inicial de clases (§5.2.1).
- [ ] [Victor] Confirmar las 3 clases piloto y sus decisores canónicos (§8.1).
- [ ] [Jay] Crear `CP-EL-SOO-AutonomyLedger-v01` y la plantilla `DEC-` (frontmatter §3.1); registrar ambos en el Registry.
- [ ] [Jay] Instrumentar la regla de captura en el flujo de brief del SherpaX (P010 extendido) y arrancar el MVP de 30 días.
- [ ] [Alex] Diseñar (no construir aún) el schema Supabase §3.2 para validar que la Fase 1 markdown migra limpio.
- [ ] [Jay] Al cierre del MVP: CAS- de LabPraxis con calibración real de umbrales (N₀, N₁, X, V) y decisión go/no-go sobre habilitar L2 en la clase más madura.
- [ ] [Anahí] Preparar la narrativa "jurisprudencia organizacional / criterio delegable" para el pitch WORX OS — gated al primer autonomy_event real (R7).

## CHANGELOG

| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-07-04 | Creación. Spec del Decision Engine como cuarto componente del kernel y evolución del Company Aquarium: ciclo brief→decisión→contexto→resultado (DEC-), autonomía por clase de decisión con Autonomy Ledger, escalera L0→L3 con umbrales y democión automática, aprendizaje explicable vía PAT-/LabPraxis, Decision Control Tower, lista negra + kill-switch, alimentación al Org IBX (motor con ledger vacío para B2B) y ROI Tracker (Founder Decision Load, Autonomy Rate), 7 riesgos con mitigación y MVP de 30 días con criterio PASS/FAIL. |