Validación prospectiva sellada: el futuro es el único test set que queda limpio

Train, validación y test del torneo de 2.255 estrategias están gastados: cualquier reevaluación sobre esos mismos datos sería sobreajuste retrospectivo. Lo único que sigue limpio es lo que todavía no ha pasado. Por eso existe un registro diario, con cadena de hashes y sellado en la propia cadena de Bitcoin, que no promete rentabilidad: promete que nadie, ni siquiera quien lo escribió, pueda tocarlo después.

Cuando se han gastado las tres particiones de datos de un experimento (entrenar, validar y el disparo único de test), la tentación habitual es volver a mirar esos mismos datos con otros ojos, encontrar un ángulo nuevo, convencerse de que esta vez sí. El torneo de estrategias de trading que venimos contando en esta serie eligió lo contrario: declarar esos datos oficialmente quemados, y abrir un experimento distinto sobre el único conjunto que seguía intacto. El futuro.

Por qué el futuro es el único dato que no se ha gastado

Cómo funciona el registro: cadena de hashes y sellado en Bitcoin

Cada día, el sistema calcula la señal que la estrategia emitiría con parámetros congelados, leídos siempre del mismo archivo de resultados del torneo, nunca escritos a mano. Esa señal se añade a un registro que solo permite añadir, nunca editar: cada entrada nueva incluye el hash de la anterior, así que modificar cualquier línea rompería la cadena entera de forma detectable. Periódicamente, el hash de la cabeza del registro se sella con OpenTimestamps, un servicio que ancla esa prueba a la propia cadena de Bitcoin — una confirmación pública e independiente de que esa entrada concreta ya existía en una fecha determinada, sin depender de que se confíe en la palabra de nadie.

El bug que el propio sistema cazó en su primera activación

La mejor prueba de que un mecanismo de verificación funciona de verdad es que alguna vez pare algo. En la primera activación real del registro, con datos frescos, el shadow-test (que re-deriva cada señal ya registrada desde el histórico completo y la compara con la guardada) detectó una divergencia real: la tanda inaugural se había calculado sobre una vela de Bitcoin que técnicamente aún no había cerrado — el precio provisional del día en curso se había colado en la descarga de datos. El sistema no corrigió nada por su cuenta ni continuó como si no hubiera pasado nada: paró, sin tocar el registro ya escrito. Las líneas afectadas por ese defecto de nacimiento se conservan tal cual, sin editar (el registro nunca se edita, ni siquiera para corregir un error propio ya identificado), documentadas como lo que son: la prueba de que, la primera vez que hizo falta, el mecanismo de verificación cumplió su función.

Los criterios de éxito, fijados antes de la primera señal

Antes de escribir una sola entrada real, el torneo fijó por escrito los tres criterios que decidirían si este experimento tuvo éxito. Un mínimo de 3 meses de registro diario continuo antes de sacar cualquier conclusión. Una coincidencia del 100% entre la señal calculada en vivo cada día y su re-derivación completa desde el histórico, sin ninguna excepción tolerada. Y cero ediciones del registro, verificable de forma independiente por tres vías a la vez: la cadena de hashes interna, el historial de git, y los sellos de OpenTimestamps. El resultado económico deliberadamente no es uno de los tres: tres meses de retornos son ruido estadístico, la misma advertencia que ya se aplicó al resto del torneo. Lo que este experimento mide es fidelidad operativa, no rentabilidad: un registro fiel que resulte perdedor sería un éxito; un registro con divergencias sin explicar sería un fallo aunque, por casualidad, hubiera ganado dinero.

Lo que esto no es

Este registro no es una herramienta de trading ni un servicio de señales, y no pretende serlo. La estrategia que registra cada día sigue siendo, formalmente, la misma que el torneo etiquetó como "documentación únicamente": superó el filtro de robustez, pero nunca el listón estadístico decisivo, ni la prueba de consistencia fuera de muestra. Empezar a registrarla en vivo no la redime — ningún pre-registro puede convertir una hipótesis no demostrada en una demostrada, solo puede comprobar, con el tiempo, si su comportamiento se sigue pareciendo a lo que el backtest predijo. NodeWitness está considerando (sin implementar todavía, pendiente de ratificación) un registro gemelo para su propio Score, congelado como "Score DCA v1" y anclado a un commit concreto del proyecto, con la misma disciplina: nombrar una versión exacta antes de que el futuro pueda validarla o desmentirla.

Nada de este artículo es una recomendación de inversión, y nada en NodeWitness lo es — el registro descrito aquí existe para medir fidelidad, no para sugerir qué comprar o vender. Puedes leer el veredicto completo del torneo, por qué los backtests mienten incluso cuando se hacen con cuidado, o seguir el Score de ciclo en vivo de NodeWitness, con la misma disciplina de publicar también lo que no funciona.

Última actualización: 29 de agosto de 2026