FMEA y riesgos¶
El stack tiene un análisis FMEA (Failure Mode and Effects Analysis) formal: 20 modos de falla identificados, priorizados por RPN = Severidad × Probabilidad × Detección, cada uno con su mitigación.
Por qué importa
El FMEA es la razón por la que el stack es production-grade. No esperamos que las cosas fallen en producción — anticipamos los modos de falla y diseñamos las mitigaciones antes.
Top de fallos por RPN¶
| ID | Modo de falla | RPN | Status | Mitigación |
|---|---|---|---|---|
| F12 | PEER NGA-West2 descarga manual bloquea pipeline | 378 | CLOSED | Fallback a synthetic GM (Kanai-Tajimi) con disclaimer |
| F10 | OpenSeesPy Python 3.12 vs stack 3.13 | 324 | NO-FIX | Boot health check + README Step 0 |
| F20 | Claim numérico sin fuente pasa Gate 0.5 | 320 | CLOSED | claim_detector.py regex + claim-verb requirement |
| F09 | VERIFY Gate 2 (Q1/Q2) bloquea tarde | 280 | CLOSED | preflight_statistics.py en COMPUTE C5.5 pre-IMPLEMENT |
| F16 | Retraction Watch no integrado en verify_citations | 243 | CLOSED | Fast-path RETRACTED verdict (CrossRef Labs) |
| F06 | Claude API quota exhausted mid-batch | 240 | CLOSED | claude_budget_tracker.py circuit breaker + checkpoints |
| F05 | OpenAlex rate limit sin backoff compartido | 210 | CLOSED | rate_limiter.py token bucket + http_cache.py |
| F04 | Session compaction mid-IMPLEMENT | 192 | CLOSED | topic_key canónico + saves obligatorios por fase |
| F19 | params.yaml con campos null post-edit | 180 | CLOSED | validate_params_ssot.py pre-commit |
El fallo que asusta: F02 — datos stale¶
F02 (COMPUTE C5 pasa con datos stale) tiene severidad 10 porque no es un crash: es un success silencioso sobre datos equivocados.
El flujo del horror: el usuario edita params.yaml, olvida regenerar y borrar data/processed/, COMPUTE corre con params viejos sobre archivos del mismo nombre, todos los gates dan verde y el paper se publica con una mentira invisible. Descubrimiento externo = retractación.
Fix: generate_compute_manifest.py embebe SHA-256 de params.yaml + metadata token de cada CSV. El gate C5 falla si el hash no coincide. verify_inputs_integrity() está wired en validate_submission.py.
Cómo se diseñan las mitigaciones¶
Cada mitigación sigue el mismo patrón:
- Identificar el modo de falla y su cadena de efectos.
- Cuantificar RPN (severidad, probabilidad, detección).
- Diseñar una mitigación de código + un test de regresión.
- Cerrar el fallo (CLOSED) o documentar por qué no se arregla (NO-FIX).
Los fallos descubiertos en producción real (ej. el hijo laicsee-2026) alimentan el FMEA: 5 bugs cerrados en un solo batch, todos con tests de regresión.
Estado actual¶
De los 20 fallos: la mayoría CLOSED, algunos NO-FIX (resueltos por otra vía o cubiertos transitivamente). Suite de regresión: tests/test_fmea_mitigations.py.
Ver también¶
- Cache y rate limiter — mitigación F05.
- Troubleshooting — síntomas de cada fallo.
- El pipeline — F09 preflight en COMPUTE C5.5.
Fuente canónica
Deriva de docs/shared/FMEA.md, que mantiene la tabla completa de 20 fallos.