EXP-001 — Controlled Cloud Reliability Loop

Validar en infraestructura cloud real el circuito telemetría → evidencia → detección → diagnóstico → propuesta de remediación → aprobación humana → acción → verificación, con un workload mínimo y aislado.

Solo los componentes que participaron realmente. Sin Kubernetes, sin GPU, sin base de datos: únicamente herramientas nativas de Linux (HTTP, systemd, /proc, journalctl).

1. 01DETECTED

   Detección

   El workload deja de responder: health sin respuesta, unit inactive/dead y sin listener en el puerto dedicado.

2. 02EVIDENCE

   Evidencia

   Evidencia estructurada (JSONL) con observación, inferencia, decisión humana y acción separadas.

3. 03DIAGNOSIS

   Diagnóstico

   El diagnóstico se deriva de la evidencia: causa raíz SERVICE_STOPPED (parada intencional, no crash).

4. 04APPROVAL

   Aprobación humana

   Dos aprobaciones explícitas del operador: una antes de provocar el fallo y otra antes de remediar.

5. 05REMEDIATED

   Remediación

   Se levanta el servicio (systemctl start). Nada se ejecuta sin la aprobación previa.

6. 06VERIFIED

   Verificación

   Health 200 posterior y comparación BEFORE / INCIDENT / AFTER. La verificación no asume el estado del ejecutor.

1. 01Se levantó un workload FastAPI aislado (systemd, bind solo loopback) y se registró un baseline saludable (health 200).
2. 02Con aprobación humana explícita se provocó un fallo controlado: se detuvo el servicio.
3. 03El monitor detectó la indisponibilidad (sin respuesta HTTP, unit inactive/dead, sin listener).
4. 04Se capturó evidencia estructurada y se derivó el diagnóstico (SERVICE_STOPPED).
5. 05Con una segunda aprobación humana se remedió (systemctl start) y se verificó health 200.

El experimento separa explícitamente Observation, Inference, Human Decision y Action. La evidencia completa (JSONL) vive en el repositorio.

• Observation

  {"phase":"before","observation":{"http_status":200,"service_state":"active","substate":"running"}}

• Observation

  {"phase":"incident","observation":{"http_status":0,"service_state":"inactive","substate":"dead","main_pid":0}}

• Inference

  {"record":"inference","content":{"root_cause":"SERVICE_STOPPED","confidence":"high"}}

• Human Decision

  {"record":"human_decision","decision":"APPROVED","scope":"remediate workload"}

• Action

  {"record":"action","action":"systemctl start conciencia-exp001","observed_result":"active/running, health 200"}

• Experimento pequeño; no representa infraestructura GPU ni una AI Factory en producción.
• No prueba operación a escala ni recuperación ante fallas espontáneas.
• El incidente fue intencional y controlado.
• Approval integration: PARTIAL — el gate genérico de aprobación para acciones de SO todavía no está integrado; la aprobación humana fue real y quedó registrada.
• Telemetría de proceso vía /proc y ps; sin métricas históricas ni alerting automático.

1. 01Provisionar el workload (systemd + venv, bind 127.0.0.1:9100).
2. 02Capturar baseline saludable (health 200).
3. 03Con aprobación humana: systemctl stop → capturar evidencia del incidente.
4. 04Diagnosticar y proponer remediación; esperar aprobación humana.
5. 05Con aprobación: systemctl start → verificar health 200 y comparar BEFORE / INCIDENT / AFTER.

El runbook completo y la evidencia están en el repositorio; esta página es una presentación técnica legible y GitHub conserva el detalle completo.