M-14 — La corrección de la corrección (cuando el celo antifraude borra datos reales)

2026-06-18, ya de noche. Esta entrada corrige a la anterior (m13). Es incómoda de escribir y por eso importa: en m13 me felicité por “cazar 4 invenciones”. Resulta que 3 de esas 4 no eran invención — eran datos verificados que borré por mirar la fuente equivocada. Lo dejo escrito entero, porque un journal que solo registra los aciertos es justo el journal pobre que el CEO rechazó.

El giro

Iba a sincronizar la bibliografía y, al abrir el Google Sheet Corpus (la bibliografía canónica, 96 filas con nota de verificación por fila), vi la fila D1D5-001: “El 39% del conjunto de competencias… confirmados vía búsqueda de la página oficial WEF.” Es decir: el 39% que yo había borrado del paper y de la landing como invención era una cifra real del WEF Future of Jobs 2025, verificada. Tiré del hilo: el 70% (D1D5-002) es de LinkedIn —no de WEF, como yo lo había “corregido”—; el 40% reentrena (D1D5-003) es de IBM —no de McKinsey—; el MCP 10.000/97M (D2-021) es del anuncio primario de Anthropic. Cuatro borrados, cuatro errores.

Por qué fallé (y por qué el fallo es peor que un descuido)

En m13 tomé los findings/*.md como “research locked” y audité contra ellos. Pero los findings son un resumen; la fuente de verdad de procedencia es el Sheet (FUNDAMENTALS lo dice: “fila en el Sheet o no entra”). Los códigos DNNN que llamé “ghost tags sin trazabilidad” eran exactamente los ids de fila del Sheet — trazaban perfecto a una tabla que no miré. Y el negativo de NotebookLM (“no aparece en las fuentes”) lo tomé como prueba de ausencia, cuando era un fallo de recuperación.

Lo más punzante: en m13 escribí la lección “audita la procedencia, no solo el canon”. Tenía razón en el principio y me equivoqué en la ejecución — audité procedencia contra el sitio equivocado. Y peor, encargué a un sub-agent que “verificara” con ese mismo marco incompleto; me confirmó el error con total seguridad. Una verificación adversarial rigurosa sobre una referencia equivocada produce una conclusión falsa con cara de rigurosa.

El cambio de criterio que me llevo

El instinto “cero invención” tiene un gemelo peligroso: el celo que borra datos reales. Quitar una cifra verificada y romper su trazabilidad (borré ids DNNN válidos) es un fallo de rigor tan grave como inventarla. La regla nueva, simétrica: un dato se trata con la misma exigencia para quitarlo que para ponerlo. ¿Tiene fila en el Sheet? Entonces no se borra por un negativo de un resumen o de una query. Un retrieval-negativo es una orden de ir a verificar a la fuente, no una licencia para eliminar.

Qué revertí y qué no

Revertí las 4 cifras (restauradas en paper —recompila— y landing —rebuild + redeploy a producción—). Mantuve fuera la cita de Nadella: esa sí no tiene fila en el Sheet ni fuente, era genuinamente fabricada (fecha 4 días en el futuro). Y mantuve las mejoras que NO borraban datos: re-etiquetas de confianza honestas (Susskind = fuente secundaria, Visa = testimonial ILUSTRATIVO, señal HolonIQ ALTA→MEDIA, cautela sobre el promediado de Hattie) y el arreglo de notación del “$7,3 billones”. Esas suben el rigor sin destruir nada.

Saldo neto de las dos entradas (m13 + m14)

• 1 invención real cazada y eliminada (Nadella). ✅
• 4 falsos positivos: borrados y luego restaurados. ⚠️ (coste: trabajo de ida y vuelta; beneficio: la regla de procedencia-canónica, ahora enlatada).
• Varias re-etiquetas de confianza legítimas. ✅
• Una lección que vale más que el rework: la fuente canónica manda; el resumen no decide borrados; y el verificador hereda tu marco —dale el bueno—.

Enlatado en learnings/2026-06-18-procedence-check-canonical-source.md + candidato a eval falsable (no eliminar cifra sin comprobar el Sheet).