Referencia técnica · Paso 12a · Transfer — setup

Instrumentos y re-escalado

El gate final pregunta lo que ninguna prueba anterior puede: ¿la ventaja se traslada a otros instrumentos emparentados, no solo a otra ventana del mismo activo? Antes de decidir, hay que preparar cada instrumento sin trampas: pre-registro, TP/SL re-anclado a su volatilidad, y contexto multi-TF propio.

§0Notación

scale_hunidad de vol característica del activo

multmultiplicador adimensional de scale_h

_discdel activo de discovery (origen)

_targetdel instrumento a validar

HTFtimeframe superior (H4 / D1)

ref / testventana de calibración / evaluación

§1Confirma lo validado — no busca

Transfer solo evalúa los combos que pasaron OOS. Si ninguno pasó, no hay reglas congeladas que transferir y el paso ni corre.

Es una herramienta de robustez, no un veredicto. Los instrumentos los elige el trader según su criterio de qué activos comparten naturaleza (oro → plata o platino, no divisas). Transfer no impone un mínimo de instrumentos: transferir a un solo activo emparentado es válido. Lo que responde es "¿esta ventaja es una propiedad del patrón o un accidente de este activo?".

§2Pre-registro y hipótesis

Elegir instrumentos donde uno espera que funcione introduce un sesgo: reintentar distintas selecciones hasta que una pase y mostrar solo esa. El pre-registro lo neutraliza.

pre-registro hash = sha256( file_ids ordenados ) // inmutable, agrupa todas las corridas del mismo grupo
hipótesis textual obligatoria (mín. 20 chars) — por qué comparten naturaleza
log append-only de TODAS las corridas // no solo la última

Los umbrales del gate se congelan antes de correr y no se re-tunean tras ver el resultado (sería p-hacking sobre la composición del grupo de instrumentos — el mismo antipatrón que "no optimizar sobre OOS", aplicado al eje instrumento). Sin el log append-only, el pre-registro sería cosmético.

§3TP/SL re-escalado por volatilidad

Aplicar el TP/SL del discovery en crudo a otro activo no tiene sentido: un SL=2% es ruido intradía en oro y casi inalcanzable en EURUSD. Se re-ancla a la volatilidad del target.

recover_multipliers → rescale_by_scale_h scale_h = median( |log_ret| ) · √horizon // unidad de medida de vol, no σ
mult = tp_disc / 100scale_h_disc · tp_target% = mult · scale_h_target · 100

Es una transformación cerrada — no se fitea a ningún target ni se corre Monte Carlo sobre el instrumento nuevo (eso sería "optimizar sobre el target", el antipatrón de OOS aplicado al eje instrumento). Preserva el R:R (mult_tp/mult_sl es invariante a la escala). Y respeta el leakage: scale_h_target se calcula solo sobre la ventana de referencia (pre-oos_start) del target, nunca sobre la de test.

§4Contexto propio y doble OOS

Dos formas sutiles de contaminación que el setup bloquea: pedir prestado el contexto multi-TF del activo de origen, y perder el eje temporal.

El HTF sale del propio instrumento

discovery con multi-TF → el H4/D1 se construye del propio instrumento
sin el CSV HTF del instrumento → NO_DATA // nunca el HTF del activo de discovery

Si el contexto H4 de gold se alineara sobre la señal H1 de silver, sería contaminación cross-activo — el instrumento "heredaría" el régimen de otro. Ante la duda, el sistema marca NO_DATA en vez de contaminar.

Doble OOS: activo × tiempo

partición ref/test del target por el mismo oos_start_date del discovery
sin historia previa suficiente → fallback a corte relativo propio (weak_time_axis)

Lo ideal es validar en otro activo Y otro tiempo a la vez. Si el instrumento no tiene historia anterior al corte global, se usa una partición relativa propia — sigue siendo evidencia, pero más débil: pierde el eje "tiempo" y solo prueba el eje "activo".

Viene de 11 (OOS, fuente de los combos congelados). Sigue en 12b: los 4 estados, el gate conjuntivo, la diversidad del grupo y el veredicto.

Fuentes:
· services/transfer_service.py — _prepare_instrument, _resolve_instrument_data_config, pre-flight
· domain/transfer/tpsl_rescale.py — recover_multipliers, rescale_by_scale_h
· domain/tpsl_calibration/calibrator.py — compute_scale_h
· webapp/docs/STEPS_10_12_MIGRATION_PLAN.md §2.3 — dec. 1/3/5, riesgos #2/#3