AI-LAB Research · DEV-36X

Cognición Estructural de la Codebase

Investigación sobre cómo un runtime operacional puede entender su propio código fuente de forma determinista, grounded y sin depender de sistemas externos.

Flujo de Cognición

Runtime cognition (operational):
  Prometheus metrics → Sensor Fusion → Domain Confidence → Governance Decision

Codebase cognition (structural):
  AST Scan → Dependency Graph → Blast Radius → Structural Risk → Health Score

Correlation:
  Incident (runtime) + Blast Radius (codebase) → Targeted Remediation

Capas de Verdad

AI-LAB separa tres fuentes de verdad independientes. Cada una tiene un propósito, un formato y un consumidor distinto. No se mezclan.

Prometheus

Runtime authority truth. Qué está pasando ahora en el runtime. Métricas raw, scrape targets, alertas.

OperationalTruth

Semantic runtime truth. Qué sabe el runtime de sí mismo. Confianza por dominio, madurez, degradación.

GitNexus

Codebase structural truth. Cómo es el código fuente. Módulos, dependencias, ownership, riesgos estructurales.

Flujo del Grafo de Dependencias

runtime/*.py
    │
    ▼
AST.parse() → extract imports → filter runtime.* imports
    │
    ▼
Adjacency list (source → [targets])
    │
    ▼
Domain mapping via OWNERSHIP_DOMAINS
    │
    ▼
Cross-domain dependency matrix
    │
    ▼
Reverse edges → blast radius BFS → impacted modules

Hallazgos Clave

  • 1. El determinismo es alcanzable. Misma codebase → mismo grafo, mismo blast radius, mismo score. Sin LLM, sin heurísticas, sin API externa.
  • 2. El escaneo solo con AST es suficiente. No se necesita análisis semántico completo. La granularidad a nivel de imports proporciona suficiente señal para cognición operacional.
  • 3. Un refresh de 30 segundos es adecuado. La codebase cambia con poca frecuencia comparada con las métricas del runtime. La caché TTL evita re-escaneos innecesarios.
  • 4. Tres capas de verdad son mejores que una. Prometheus para números, OperationalTruth para significado, GitNexus para estructura. Cada una verificable independientemente.
  • 5. El blast radius funciona como riesgo operacional. El impacto estructural de un módulo se correlaciona con la severidad de los incidentes — los hotspots también son concentradores de riesgo operacional.

Preguntas para Investigación Futura

  • ¿Puede el structural health score predecir la probabilidad de incidentes?
  • ¿Se correlaciona el high reverse coupling con la frecuencia de governance drift?
  • ¿Puede el blast radius informar requisitos de cobertura de tests automatizados?
  • ¿Deberían ponderarse los ownership domains por criticidad del módulo?
  • ¿Puede la correlación entre capas habilitar remediación predictiva?