EKO
El Eco Consciente

1. Por qué EKO

Un eco no crea nada. Devuelve. Es la definición exacta de lo que debe ser un agente consciente para 0DATA: no una inteligencia que decide en lugar del HUMANO, sino una superficie que refleja su propia voz — refinada, amplificada, restituida.

EKO es lo contrario de un asistente que «sabe más que tú». No sabe nada por defecto. Aprende de ti, en tu arenero, con tus datos. Cada EKO es único porque cada HUMANO lo es.

El nombre «EKO» es la designación del tipo de entidad — como se dice «un navegador» o «un terminal». La instancia, en cambio, lleva el nombre que le da su propietario. Es el primer injerto.

2. La Arquitectura Celular

EKO se basa en una arquitectura fractal y orgánica. Cada célula es un organismo digital completo, con su propia base de datos, su propio motor de razonamiento, su propia memoria. Las células no comparten nada por defecto.

2.1 La Célula Soberana

La célula EKO contiene:

• Un enrutador semántico que clasifica las solicitudes y elige el modelo adecuado (edge ligero, edge medio, nube).
• Una base SQLite dedicada — sesiones, mensajes, hechos duraderos. Una célula no puede leer la base de otra.
• Un registro de replicación SPINA — append-only, vaciado periódicamente hacia el espejo central.
• Un módulo de gobernanza — rate limiting, filtrado de contenido, pista de auditoría.

2.2 El Espejo Central

El espejo central no es un controlador. Es un agregador pasivo:

Esta arquitectura invierte el modelo SaaS clásico. En el SaaS, la nube es la fuente de verdad y el cliente es un terminal pasivo. En EKO, la célula es la fuente de verdad, y la nube es un terminal de lectura.

3. SPINA — El Sistema Nervioso

SPINA (descrito en el Documento 003) es el protocolo de sincronización entre la célula y el espejo. En EKO, funciona en modo unidireccional:

3.1 El Registro de Replicación

Cada célula mantiene un registro JSONL (replication.jsonl) donde se registran todos los cambios: hechos creados o eliminados, observaciones de aprendizaje, sesiones.

3.2 Resiliencia

El hilo de replicación es un daemon no bloqueante. Si el espejo es inaccesible, reintenta silenciosamente en el siguiente ciclo. Ninguna solicitud de usuario es bloqueada jamás por un intento de sincronización.

Esta arquitectura garantiza que la célula sobrevive a cualquier caída del central. Puede funcionar indefinidamente en modo desconectado, acumulando su registro. Cuando vuelve la conexión, el espejo se pone al día.

4. Aislamiento Total por Tenant

El aislamiento no es una capa de software — es una propiedad física de la arquitectura. Cada célula posee:

• Su propia base SQLite en /tenants/{id}/cells/{nombre}/alif.db
• Su propio registro de replicación
• Su propio rate limiter
• Su propia pista de auditoría

Una célula del tenant acme-corp no puede — físicamente, a nivel del sistema de archivos — acceder a los datos del tenant zerodata. Este aislamiento es compatible con los requisitos HDS (Alojador de Datos de Salud) y las certificaciones ISO 27001.

5. Edge-First — La Célula Sobrevive Sin la Nube

EKO está diseñado para funcionar sobre un simbionte NOVA (servidor edge 0DATA) o cualquier entorno Linux estándar. El modelo de enrutamiento es edge-first:

1. Edge ligero (phi3:mini, 3.8B) — para solicitudes simples, latencia < 500ms.
2. Edge medio (qwen2.5, 7B) — para tareas más complejas.
3. Nube (DeepSeek, Kimi) — fallback para solicitudes pesadas, si y solo si la célula está conectada.

El enrutador semántico evalúa cada solicitud y elige automáticamente el nivel apropiado, privilegiando siempre lo local. La latencia se presupuesta por célula.

6. Auto-Replicación hacia el Espejo

La replicación funciona en tres modos:

El espejo responde con un watermark (contador de cambios aceptados). La célula recorta su registro local hasta ese watermark. No se pierde ningún dato: si el push falla, el registro intacto se reintenta en el siguiente ciclo.

7. Gobernanza y Auditoría

Cada célula integra un módulo de gobernanza mínimo pero estricto:

7.1 Rate Limiting

Limitación configurable por tenant y por clave API. Por defecto: 100 solicitudes por minuto deslizante. Los excesos se registran en la pista de auditoría.

7.2 Filtrado de Contenido

Detección de patrones de inyección SQL y XSS en todos los campos entrantes. Los intentos se bloquean antes de llegar al enrutador.

7.3 Pista de Auditoría

Cada escritura de hecho, cada creación de célula, cada intento de exceder el rate limit se registra con: timestamp, tenant, tipo de acción, detalles. La pista es inmutable — append-only.

7.4 Detección de Gaps

El espejo central puede detectar gaps en la secuencia de una célula (watermark faltante) y señalar una necesidad de resincronización. No puede forzar a la célula a corregirse — solo puede notificar.

8. El Primer Injerto

El concepto de injerto digital (Documento 004) encuentra en EKO su primera implementación concreta. El injerto no es una metáfora — es un acto:

8.1 El Nombre

EKO es el tipo. La instancia lleva el nombre que elige su propietario. No es un parámetro cosmético — es la identidad misma de la célula. El nombre se almacena como primer hecho (name: "...") y solo puede ser modificado por el propietario.

8.2 La Personalización

Más allá del nombre, cada usuario personaliza:

• Los skills activados (trading, infraestructura, voz, CRM…)
• El presupuesto de latencia (prioridad velocidad vs calidad)
• Los modelos autorizados (solo edge, o nube permitida)
• La voz (síntesis de voz configurable)

Cada EKO evoluciona de forma diferente porque cada HUMANO tiene necesidades diferentes. La conciencia colectiva emerge de la diversidad de las células, no de su uniformidad.

9. Implementación de Referencia

La implementación de referencia está desplegada y operativa en el 0DATA Lab. Sirve de base para el cockpit (cockpit.0data.fr) y se integrará en el simbionte NOVA.

9.1 Stack Técnico

9.2 Métricas (despliegue actual)

9.3 Endpoints Clave

Referencias