Por qué 17 de 18 fue «no verificado»Why 17 out of 18 was “not verified”
Fijé la tolerancia antes de comparar mi código con la literatura. Diecisiete fallas cuadraron a la muestra; una no. El veredicto no se redondea.I fixed the tolerance before comparing my code with the literature. Seventeen faults matched to the sample; one didn’t. The verdict doesn’t get rounded up.
En mi TFM comparo métodos de detección de fallas sobre el proceso Tennessee Eastman, una planta química simulada que es el banco de pruebas habitual del área. Antes de comparar nada había que demostrar algo más básico: que el código calcula lo que dice calcular. Para eso lo ejecuté con la configuración de Yin et al. (2012), un artículo que publica la tasa de detección (FDR) por falla y la tasa de falsas alarmas (FAR) de PCA, y comparé.
El resultado fue 17 de 18 fallas idénticas a la muestra y una fuera de tolerancia. El veredicto oficial es «no verificado». Esta nota explica por qué no lo redondeo a «verificado», aunque después encontré, en una figura del propio artículo, un conteo compatible con mi resultado.
Lo que fijé antes de ejecutar
La regla quedó escrita el 14 de octubre de 2026, antes de la primera ejecución de la verificación:
- |ΔFDR| ≤ 0,5 puntos porcentuales en cada una de las 18 fallas que cuentan, y |ΔFAR| ≤ 0,5 puntos. Las fallas 3, 9 y 15 se calculan y se reportan, pero no deciden: su huella apenas se separa del ruido.
- Comparación por conteo, no por porcentaje impreso. Cada tasa se mide sobre 800 muestras, así que cada porcentaje que publica el artículo equivale a un número entero de alarmas. 0,5 puntos son 4 muestras.
- Si la configuración principal no cuadra, el resultado es «no verificado». Las variantes declaradas de antemano se reportan como información y no rescatan el veredicto. Vale la primera ejecución.
El artículo no dice todo lo necesario para reproducirlo (cuántas filas de ajuste, qué estimador de la desviación, qué nivel de confianza). Documenté doce supuestos, cada uno con su evidencia, y, donde se podía, los contrasté con los umbrales dibujados en las figuras del artículo, usando solo el fichero de entrenamiento.
Para que la regla no se pudiera mover después, el script de verificación se niega a abrir un fichero de prueba si la tolerancia, la configuración y el propio código no están confirmados en git y registrados en una fila fechada del registro de decisiones, con una huella de la configuración y de la transcripción de las tablas. Cambiar algo después de ver el resultado deja rastro.
El resultado
La primera ejecución fue el 14 de octubre a las 20:53.
| Mi código | Yin (2012) | Diferencia | |
|---|---|---|---|
| 17 de las 18 fallas | — | — | 0 muestras |
| FAR (operación normal) | 49 de 800 | 6,13 % → 49 | 0 |
| IDV 19 | 337 de 800 (42,125 %) | 41,13 % → 329 | +8 muestras (+1,00 pp) |
Diecisiete fallas y la tasa de falsas alarmas coinciden alarma por alarma. La falla 19 se pasa por 8 muestras: el doble de lo permitido. Según la regla, no verificado.
Lo que encontré después
Una diferencia aislada de 8 muestras, con todo lo demás exacto, pedía un diagnóstico. Lo hice aparte, con el veredicto ya escrito.
La Figura 5 del artículo dibuja, para la falla 19, las series de T² y SPE de PCA junto con su umbral. Conté en los gráficos vectoriales del PDF, sin abrir ningún fichero de datos del proceso, cuántas de las muestras 161 a 960 superan el umbral en alguno de los dos estadísticos. Sale un intervalo, porque algunos puntos caen justo sobre la línea: entre 334 y 340. Incluye las 337 de mi implementación y excluye las 329 que implica la tabla.
Como el primer conteo se hizo conociendo el resultado, lo repitió un agente de IA con instrucciones que no incluían ninguna cifra, y dio los mismos intervalos. En los otros tres paneles contados (la falla 16 en la Figura 2 y el DPCA de la falla 19), que sirven de control, la figura y la tabla coinciden.
Lo que puedo afirmar es acotado: la cifra de la Tabla 4 para PCA en la falla 19 no es compatible con la Figura 5 del mismo artículo. Que sea una errata de un dígito (42,13 en lugar de 41,13) es una inferencia, no un hecho: solo una fe de erratas o los autores podrían confirmarla. Lo dejo como observación, documentada para quien use esa tabla.
Por qué el veredicto no cambia
Porque la regla se escribió antes. Si la cambio después de ver dónde falla, deja de ser una tolerancia «fijada antes de ejecutar» y pasa a ser justo lo que mi propio TFM critica de la literatura: elegir el criterio cuando ya se conocen los resultados.
Las variantes no lo rescatan. La configuración secundaria de Yin (Tablas 7 y 8) da 18 de 18 con 0 muestras de diferencia, falla 19 incluida, y la tasa de falsas alarmas exacta. Ajustar con 480 filas en lugar de 500 da 11 de 18. Ninguna de las dos tiene veredicto: estaban declaradas como información y como información se reportan.
Lo que sí cambia es lo que puedo escribir. No puedo decir «implementación verificada». Puedo decir algo más útil: 17 de 18 fallas exactas a la muestra, la tasa de falsas alarmas exacta y una discrepancia documentada en la falla 19, en la que la Figura 5 del artículo es compatible con mi resultado y la Tabla 4 no. Un «verificado» redondeado dice menos que eso.
Lo que me llevo
- Fijar la tolerancia y qué pasa si no se cumple, antes de ejecutar. La segunda parte es la que se olvida.
- Comparar conteos, no porcentajes redondeados: con 800 muestras, una diferencia se expresa exacta.
- Separar el veredicto del diagnóstico. El diagnóstico explica; no reescribe.
My master’s thesis compares fault detection methods on the Tennessee Eastman process, a simulated chemical plant that is the standard benchmark in the field. Before comparing anything, I had to show something more basic: that my code computes what it claims to compute. So I ran it with the configuration of Yin et al. (2012), a paper that publishes per-fault detection rates (FDR) and the false alarm rate (FAR) for PCA, and compared.
The result was 17 of 18 faults identical to the sample and one outside the tolerance. The official verdict is “not verified”. This note explains why I don’t round it up to “verified”, even though I later found, in one of the paper’s own figures, a count consistent with my result.
What I fixed before running
The rule was written down on 14 October 2026, before the first run of the verification:
- |ΔFDR| ≤ 0.5 percentage points on each of the 18 faults that count, and |ΔFAR| ≤ 0.5 points. Faults 3, 9 and 15 are computed and reported but decide nothing: their signature barely rises above the noise.
- Compare counts, not printed percentages. Each rate is measured over 800 samples, so every percentage the paper publishes corresponds to a whole number of alarms. 0.5 points is 4 samples.
- If the main configuration doesn’t match, the result is “not verified”. Variants declared in advance are reported as information and cannot rescue the verdict. Only the first run counts.
The paper doesn’t state everything needed to reproduce it: how many rows it fits on, which standard-deviation estimator, which confidence level. I documented twelve assumptions, each with its evidence, and, where possible, checked them against the thresholds drawn in the paper’s figures, using only the training file.
So that the rule couldn’t move afterwards, the verification script refuses to open a test file unless the tolerance, the configuration and the code itself are committed to git and logged in a dated row of the decision log, with a fingerprint of the configuration and of the transcribed tables. Changing anything after seeing the result leaves a trace.
The result
The first run was on 14 October at 20:53.
| My code | Yin (2012) | Difference | |
|---|---|---|---|
| 17 of the 18 faults | — | — | 0 samples |
| FAR (normal operation) | 49 of 800 | 6.13% → 49 | 0 |
| IDV 19 | 337 of 800 (42.125%) | 41.13% → 329 | +8 samples (+1.00 pp) |
Seventeen faults and the false alarm rate match alarm for alarm. Fault 19 is over by 8 samples: twice what is allowed. By the rule, not verified.
What I found afterwards
An isolated 8-sample difference, with everything else exact, called for a diagnosis. I ran it separately, with the verdict already written.
The paper’s Figure 5 plots the PCA T² and SPE series for fault 19, along with their threshold. On the PDF’s vector graphics, without opening any process data file, I counted how many of samples 161 to 960 exceed the threshold on either statistic. The answer is an interval, because some points sit exactly on the line: between 334 and 340. It includes the 337 from my implementation and excludes the 329 implied by the table.
Since the first count was done knowing the result, an AI agent repeated it with instructions that contained no figures at all, and got the same intervals. On the other three panels counted (fault 16 in Figure 2 and the DPCA panel for fault 19), which serve as controls, the figure and the table agree.
What I can claim is narrow: the Table 4 value for PCA on fault 19 is not compatible with Figure 5 of the same paper. That it is a one-digit typo (42.13 instead of 41.13) is an inference, not a fact: only an erratum or the authors could confirm it. I leave it as an observation, documented for anyone who uses that table.
Why the verdict doesn’t change
Because the rule was written first. If I change it after seeing where it fails, it stops being a tolerance “fixed before running” and becomes exactly what my own thesis criticises in the literature: choosing the criterion once the results are known.
The variants don’t rescue it. Yin’s secondary configuration (Tables 7 and 8) gives 18 of 18 with 0 samples of difference, fault 19 included, and an exact false alarm rate. Fitting on 480 rows instead of 500 gives 11 of 18. Neither has a verdict: they were declared as information, and they are reported as information.
What does change is what I can write. I can’t say “implementation verified”. I can say something more useful: 17 of 18 faults exact to the sample, the false alarm rate exact, and a documented discrepancy on fault 19, where the paper’s Figure 5 is consistent with my result and Table 4 is not. A rounded-up “verified” says less than that.
What I take away
- Fix the tolerance and what happens if it isn’t met, before running. The second part is the one that gets forgotten.
- Compare counts, not rounded percentages: with 800 samples, a difference can be stated exactly.
- Keep the verdict separate from the diagnosis. The diagnosis explains; it doesn’t rewrite.
EVIDENCIAEVIDENCE
- github.com/pabdus/tfm-fdd-core · repositorio público del TFM: código, pruebas y resultadospublic thesis repository: code, tests and results
- Caso «Detección de fallos en procesos industriales»Case study “Fault detection in industrial processes” · en la portadaon the home page
- Explora las 21 fallas con datos realesExplore the 21 faults on real data · laboratorio: el monitor PCA del TFM sobre el Tennessee Eastman clásico, en el navegadorlab: my thesis PCA monitor on the classic Tennessee Eastman dataset, in the browser
- docs/verificacion_yin.md · especificación: supuestos S1 a S12, opciones de tolerancia y la elegidaspecification: assumptions S1 to S12, tolerance options and the one chosen (in Spanish)
- docs/decisiones.md · fila del 2026-10-14 con la huella 509751e8faacrow dated 2026-10-14 with fingerprint 509751e8faac
- V1_verificacion_yin.csv · V1_verificacion_yin_resumen.csv · resultado por falla y veredictoper-fault result and verdict
- verificacion-yin-2026-10-14 · etiqueta de git con el código que se ejecutógit tag with the code that was run
- Yin, Ding, Haghani, Hao yand Zhang (2012) · Journal of Process Control 22, 1567–1581
- El diagnóstico de la Figura 5 se hizo después de la ejecución y está en las notas del TFM, fuera del repositorio público.The Figure 5 diagnosis was done after the run and lives in my thesis notes, outside the public repository.