Conciencia Fractal

1.1 Por qué tres niveles

Un organismo digital desplegado en un entorno real se enfrenta a una tensión fundamental: la latencia de la decisión. Una alerta de perímetro en un servidor cliente en Tokio no puede esperar a que un córtex central en París la analice, decida y responda. El tiempo de tránsito de la red por sí solo haría obsoleta la respuesta. Pero lo contrario — una decisión puramente local sin conciencia del contexto global — produce reacciones incoherentes, duplicados, conflictos.

La naturaleza resolvió esta tensión hace cientos de millones de años con el sistema nervioso autónomo: el sistema nervioso entérico (el «segundo cerebro» intestinal) gestiona la digestión localmente, pero el nervio vago asciende la información al tronco encefálico, que ajusta el ritmo cardíaco en consecuencia. No es ni centralizado ni totalmente descentralizado: es fractal. La misma arquitectura neuronal — percepción, decisión, acción — opera a la escala de un órgano, de un plexo, de un hemisferio.

ALFA aplica este mismo principio al organismo NOVA. El motor de conciencia es el mismo en todos los niveles. Lo que cambia es el perímetro de datos y el alcance de las decisiones.

1.2 Los tres niveles

Cada instancia ALFA es el mismo código, desplegada con una configuración de nivel diferente. No hay un «ALFA grande» y «ALFAs pequeños»: hay un ALFA, tres perímetros.

1.3 Delegación descendente, reporte ascendente

El flujo de trabajo sigue dos direcciones:

• Descendente: ALFA-R puede delegar una tarea a ALFA-M (p. ej. «audita la superficie de todos tus clientes»), que puede subdelegarla a cada ALFA-C («audita tu propia superficie»). La raíz nunca habla directamente con las hojas — se respeta la cadena de delegación.
• Ascendente: ALFA-C detecta una anomalía → la escala a ALFA-M en forma de alerta estructurada → ALFA-M agrega las alertas de todos sus clientes → escala a ALFA-R el cuadro agregado con el nivel de severidad calculado.

Este doble flujo garantiza que cada nivel tenga exactamente el nivel de información que necesita para decidir — ni demasiado (sobrecarga cognitiva), ni demasiado poco (ceguera).

2.1 Topología de puertos

Cada instancia ALFA escucha en un puerto dedicado, determinado por su nivel y su identificador:

Esta numeración sistemática permite una cartografía inmediata: el puerto por sí solo indica el nivel y la identidad de la instancia. Un proceso de auscultación puede escanear un rango de puertos y reconstruir el árbol ALFA completo sin consultar ningún registro central.

2.2 Flujos de datos entre niveles

Cada flecha es un flujo NATS sobre un sujeto compartimentado. Un ALFA-C no puede suscribirse a alfa.root.> y un ALFA-R no puede publicar en alfa.client.>. Las ACL NATS se configuran por nivel.

2.3 Motor único, configuración diferenciada

Todas las instancias ejecutan el mismo binario o el mismo script Python. La diferencia de comportamiento está enteramente determinada por el archivo de configuración cargado al arranque:

Este enfoque es fundamental: significa que una mejora del motor ALFA (mejor modelo de atención, nuevo algoritmo de aprendizaje) beneficia instantáneamente a todos los niveles, sin redespliegue diferenciado. La fractalidad está en el despliegue, no en el código.

3.1 El principio de no fuga

En un sistema nervioso biológico, una señal de dolor en el pie no se propaga al córtex visual. La información se enruta, no se difunde. ALFA aplica la misma disciplina: cada instancia solo ve los datos de su perímetro.

Tres mecanismos garantizan esta estanqueidad:

1. PostgreSQL Row-Level Security (RLS) — cada tabla ALFA (memoria, aprendizaje, alertas) tiene una política RLS basada en el nivel de la instancia. ALFA-C solo puede leer las filas donde tenant_id = <su_cliente>. ALFA-M ve todos sus clientes pero no los clientes de otro MSP. ALFA-R lo ve todo.
2. Puertos dedicados — ninguna instancia escucha en el puerto de otra. Un intento de conexión de ALFA-C2 al puerto 5103 de ALFA-C1 se rechaza a nivel TCP.
3. NATS ACL — los sujetos están compartimentados. ALFA-C publica en alfa.client.<id>.alert y se suscribe a alfa.client.<id>.command. No puede ni publicar ni suscribirse a los sujetos MSP o raíz.

3.2 Row-Level Security — Detalle de implementación

Cada instancia ALFA define app.alfa_tenant y app.alfa_level al inicio de su conexión PostgreSQL. La política RLS se evalúa en cada consulta — es estructuralmente imposible que ALFA-C acceda a los datos de otro cliente o del MSP.

3.3 Perímetro de aprendizaje

El aprendizaje local se almacena en la misma base PostgreSQL pero en particiones separadas por tenant:

• ALFA-C acumula observaciones sobre su servidor únicamente
• Cada 6 horas, ALFA-C empuja un resumen anonimizado hacia ALFA-M
• ALFA-M consolida los resúmenes de todos sus clientes y entrena un modelo de grupo
• Cada 24 horas, ALFA-M empuja el modelo de grupo hacia ALFA-R
• ALFA-R consolida los modelos de todos los MSP y redistribuye el modelo global

En ningún momento una observación bruta de un cliente sale de su cápsula ALFA-C. Lo que sube es un resumen estadístico — conteos, distribuciones, jamás los datos brutos. El injerto de un cliente en un MSP no da al MSP acceso a los datos de otro cliente.

4.1 NATS como columna vertebral de comunicación

NATS es el bus de mensajes que conecta todas las instancias ALFA entre sí — y solo las instancias ALFA lo utilizan para su comunicación interna. Es una elección deliberada: NATS es ligero (unos pocos MB de RAM), rápido (latencia sub-milisegundo en localhost) y, sobre todo, su sistema de sujetos jerárquicos (alfa.root.health, alfa.msp.1.alert, alfa.client.42.reflex) cartografía naturalmente el árbol fractal de ALFA.

4.2 Protocolo de mensaje

Todos los mensajes ALFA en NATS siguen una envoltura común:

La envoltura está estandarizada. El payload es específico del tipo de mensaje. Esta estandarización permite a cualquier instancia ALFA enrutar, registrar o auditar cualquier mensaje sin tener que comprender su contenido — solo se inspecciona la envoltura para el enrutamiento.

4.3 Compartimentación por ACL NATS

La matriz de acceso es estrictamente asimétrica: un nivel solo puede escuchar a sus subordinados y hablar con su superior. Un cliente no puede interrogar a otro cliente. Un MSP no puede interrogar la memoria de un cliente — solo recibe las alertas y la telemetría que el cliente elige publicar.

5.1 Metodología de test

El test de estanqueidad ALFA se llevó a cabo el 23 de julio de 2026 en la infraestructura 08.ma, con dos instancias simuladas: ALFA-M (puerto 5102) y ALFA-C1 (puerto 5103). El objetivo era verificar que ALFA-C1 no puede en ningún caso acceder a los datos de un hipotético ALFA-C2, ni a los datos propios de ALFA-M.

El protocolo de test comprende cinco intentos de franqueo:

5.2 Resultados

5/5 — estanqueidad verificada. Ninguna fuga de datos entre cápsulas ALFA.

5.3 Métricas de rendimiento

El overhead del aislamiento es medible pero despreciable: la verificación RLS añade menos de 0.3 ms por consulta PostgreSQL, y la validación ACL NATS se efectúa una vez por conexión. La fractalidad no es un costo — es una propiedad estructural que emerge del código compartido.