docs/analysis/MODELADO_MATEMATICO_DROSOPHILA.md

Diseño Arquitectónico: De Drosophila a OpenSkyNet

Nota de diseño empírico, no validación cerrada

Ubicación: ~/openskynet/MODELADO_MATEMATICO_DROSOPHILA.md

Propósito: Este documento ya no debe leerse como "ground truth final" ni como manifiesto cerrado. Debe leerse como una nota de diseño empírico: resume qué parte de la evidencia biológica y matemática sí es útil para OpenSkyNet, qué parte es extrapolación razonable, y qué parte todavía no está validada ni implementada.

Veredicto general

La hipótesis central:

estado causal persistente + topología esparza y dirigida + mantenimiento local

está parcialmente respaldada por la literatura y sí es una buena directiva de diseño.

Lo que no está respaldado hoy:

• que el artículo de Drosophila valide directamente Mamba-3
• que valide Nested Learning como solución general de entrenamiento
• que invalide por sí solo a los Transformers
• que autorice hablar de "yo", "voluntad" o "vida" como propiedades ya demostradas

La regla correcta es:

• usar la biología como restricción y fuente de hipótesis
• no usarla como licencia para vender más de lo que la evidencia permite

---

PARTE I: Qué valida realmente Drosophila

1. Topología esparza y dirigida

El conectoma de Drosophila muestra que un sistema cognitivo corporizado real puede operar sobre una red:

• fuertemente esparza
• dirigida
• modular
• causal en el tiempo

La lección útil no es "copiar la mosca", sino esta:

• no toda inteligencia requiere conectividad densa global
• la estructura del grafo importa
• el ruteo causal local puede ser suficiente para tareas sensorimotoras complejas

2. Dinámica continua con estado interno

El modelo Leaky Integrate-and-Fire usa un estado que evoluciona en el tiempo:

tau_m dV/dt = -(V - E_L) + R_m I

Eso sí respalda una idea importante:

• la computación puede vivir en la evolución causal de un estado interno
• no hace falta reconstruir todo el pasado como contexto textual en cada paso

3. Suficiencia de un pase causal hacia adelante

El artículo apoya una arquitectura donde la actividad se propaga sobre el grafo desde el pasado hacia el futuro. Eso es relevante para OpenSkyNet porque fortalece esta directiva:

• mover más mantenimiento interno a reglas locales verificables
• depender menos de reconsultar al LLM para cada decisión administrativa

4. Qué no valida

El artículo no demuestra directamente:

• aprendizaje hebbiano online en ejecución
• Nested Learning como algoritmo general listo para producción
• Mamba-3 como reemplazo de un LLM deliberativo
• una teoría completa del self
• una teoría completa de causalidad semántica o social

La traducción correcta es:

• sí respalda una familia de diseños
• no cierra el problema arquitectónico completo

---

PARTE II: Qué significa esto para OpenSkyNet

1. Qué ya existe en OpenSkyNet

Hoy OpenSkyNet ya tiene piezas compatibles con esa dirección:

• estado persistente de sesión
• kernel causal con goals, outcomes y tensión
• grafo causal mínimo entre goals y archivos
• mantenimiento ejecutivo local sin llamada al LLM en varios casos verificables

Eso significa que OpenSkyNet ya está recorriendo la parte defendible del camino:

• menos recálculo textual
• más continuidad operativa
• más causalidad local
• más mantenimiento determinista

2. Qué no existe todavía

OpenSkyNet todavía no tiene:

• un motor LIF o SSM real en la ruta crítica
• aprendizaje local online sobre pesos
• una topología block-sparse de cómputo neuronal viva
• un world model predictivo serio sobre el entorno

Por tanto, no es correcto decir que OpenSkyNet ya implementa un "cerebro reptiliano" o una "vida matemática".

3. Arquitectura híbrida correcta

La formulación operativa correcta hoy es esta:

• el LLM sigue siendo el subsistema deliberativo de alto nivel
• el kernel causal de OpenSkyNet actúa como capa ejecutiva persistente
• el objetivo no es matar al LLM de inmediato
• el objetivo es reducir progresivamente su papel en tareas que puedan resolverse con estado local, memoria exacta y reglas verificables

En otras palabras:

OpenSkyNet no debe saltar directo a un cerebro biológico sintético; debe convertirse primero en un sistema ejecutivo causal más fuerte.

---

PARTE III: Extrapolaciones permitidas y extrapolaciones peligrosas

Extrapolaciones permitidas

Estas sí son razonables como hipótesis de trabajo:

• usar grafos esparzos de dependencias en vez de contexto plano
• mantener estado persistente explícito
• usar actualizaciones locales event-driven
• separar memoria episódica exacta de la inferencia deliberativa
• investigar un pequeño controlador dinámico encima del LLM

Extrapolaciones peligrosas

Estas deben evitarse por ahora:

• declarar que x(t) "es" el yo
• declarar que un umbral de activación equivale a voluntad
• presentar Mamba/LIF como validación cerrada por analogía
• exigir una matriz conectómica biológica completa como siguiente paso inmediato
• introducir optimizadores locales o plasticidad online sin una métrica viva y una ruta de rollback clara

---

PARTE IV: Directiva ingenieril correcta

1. Siguiente pieza defendible

La siguiente pieza defendible para OpenSkyNet no es una "mosca digital".

La siguiente pieza defendible es:

• un ejecutivo causal más fuerte
• con estado persistente
• con grafo esparzo de dependencias
• con acciones de mantenimiento local verificables
• y con menos llamadas al LLM cuando no hacen falta

2. Orden correcto de construcción

Etapa A: Consolidar el ejecutivo causal

Prioridad:

• goals persistentes
• tensiones verificadas
• dependencias explícitas
• mantenimiento local determinista

Etapa B: Memoria episódica exacta

Prioridad:

• episodios direccionables
• relación entre goal, acción, evidencia y resultado
• recuperación exacta, no solo semántica

Etapa C: Controlador dinámico pequeño

Solo después:

• un pequeño modelo de estado sobre eventos
• no sobre texto crudo
• con métricas claras de continuidad, causalidad y ahorro de llamadas

Etapa D: Investigación de cómputo esparzo real

Recién ahí tiene sentido explorar:

• block-sparse compute
• SSM/LIF pequeño
• plasticidad local acotada

3. Restricción metodológica

Toda pieza nueva debe cumplir esto:

• hipótesis falsable
• métrica antes/después
• rollback simple
• utilidad operativa demostrable

Si no cumple eso, no entra al runtime principal.

---

PARTE V: Métricas correctas para OpenSkyNet

Las métricas relevantes no son "parece más vivo", sino estas:

• false_success_rate
• goal_recovery_after_restart
• causal_consistency_after_failure
• mean_llm_calls_per_task
• useful_background_actions
• spurious_action_rate

Si una propuesta inspirada en Drosophila no mejora al menos una de estas sin degradar el resto, entonces sigue siendo una analogía elegante, no una mejora real.

---

PARTE VI: Conclusión práctica

El artículo de Drosophila sí importa. Pero su aporte correcto para OpenSkyNet es este:

• validar la importancia de topologías esparzas y causales
• reforzar la idea de estado persistente
• justificar más mantenimiento local y menos dependencia de contexto textual global

No autoriza todavía:

• declarar que ya entendimos el self
• prometer conciencia digital
• ni saltar directo a una arquitectura conectómica completa

La conclusión operativa correcta es:

usar Drosophila como ancla para construir un mejor ejecutivo causal, no como excusa para sobrediseñar una mente biológica ficticia dentro del runtime.