Signal

La intuición central de XCAP es brutal y poco intuitiva para quien viene de SaaS: en un sistema de investigación de trading, la red no es una conveniencia, es la superficie de ataque más grande que tienes. Cada endpoint con llave es una credencial que puede filtrarse; cada llamada de escritura es un trade que puede dispararse por un bug. Por eso XCAP colapsa toda su exposición de red a un único punto: un edge de ingesta read-only, keyless y GET-only. El resto del sistema es determinista desde disco. Si entiendes esto, entiendes por qué `binance_public.py` solo pide klines (velas OHLCV históricas) por HTTP GET, sin API key, sin firmar nada, sin tocar jamás un endpoint de cuenta o de orden.

Concretamente, el patrón es: una fuente abstracta (en XCAP, una jerarquía `OHLCSource`) con dos implementaciones. `LocalCSVSource` lee CSVs ya en disco — cero red, el caso por defecto, el que usan TODOS los loops automáticos. Y `HttpOHLCSource` (respaldado por `binance_public.py`) que solo se activa cuando un caller pasa explícitamente `allow_network=True` o invoca el comando `data-fetch`. La asimetría es deliberada: el camino seguro es el default y el camino con red exige una opción explícita en cada llamada. Nunca un flag global ambiental, nunca una variable de entorno que se quede encendida.

El endpoint de Binance que usas es el público de mercado: `GET https://api.binance.com/api/v3/klines?symbol=BTCUSDT&interval=1d&limit=1000`. Devuelve un array de arrays: `[openTime, open, high, low, close, volume, closeTime, ...]`. Fíjate en lo que NO hay aquí: no hay header `X-MBX-APIKEY`, no hay query param de firma HMAC, no hay timestamp firmado. Ese endpoint físicamente no puede leer tu balance ni colocar una orden porque la API de cuenta de Binance vive en otra ruta y exige firma. La seguridad no es una promesa tuya de portarte bien: es una propiedad del endpoint que elegiste.

El segundo pilar es la normalización en el borde. Datos del mundo real llegan sucios: timestamps en milisegundos, números como strings, velas duplicadas, huecos. Tu edge debe normalizar a UN formato canónico antes de que nada downstream los toque. En XCAP los CSVs de `data/real` son lowercase (`open,high,low,close,volume`), timestamps parseados a fechas, y `LocalCSVSource` los lee siempre igual. Esta disciplina es lo que hace reproducible al sistema: el clasificador de régimen (SG-02) y la Market Memory (SG-03) leen de disco un formato estable, no de una respuesta HTTP volátil que cambia entre corridas.

La verificación es el cierre. XCAP tiene un comando `check` (corre con `PYTHONPATH=src python3 -m xcap.control check`) que afirma como invariante que el connector es keyless, read-only, no puede operar y no puede mover dinero. No es un test que pasa una vez: es una aserción que corre en cada `check`, de modo que si alguien añade una llave o un método de escritura, el `check` se pone rojo. Así es como conviertes una intención de diseño en una propiedad que el sistema defiende solo. La regla de oro: la seguridad que depende de que recuerdes algo no es seguridad; la seguridad que un test rojo te obliga a respetar, sí.

Un matiz operativo importante: el dashboard de XCAP bindea solo a `127.0.0.1`, nunca a `0.0.0.0`. El edge de ingesta es la única superficie de salida; la de entrada (el dashboard) no escucha en la red. Y FileVault (AES-256) cifra el disco en reposo. La cadena completa — disco cifrado, ingest keyless read-only, dashboard local-only, Capital Gate cerrado — es lo que permite tener un sistema de trading-research en un portátil sin que sea una bomba de relojería.

El error conceptual que XCAP corrigió en su auditoría de junio 2026 es sutil y vale oro: confundir salud operacional con régimen de precio. `market_state.py` mide salud del sistema (¿tengo datos frescos?, ¿están los flags bien?). `regime.py` mide algo totalmente distinto: ¿en qué ESTADO está el mercado mismo? Son ejes ortogonales y mezclarlos produce un clasificador que no sabe qué está diciendo. La primera disciplina es: un clasificador de régimen habla solo del precio, nunca del estado de tu infraestructura.

El diseño de XCAP clasifica a lo largo de cuatro ejes independientes. Trend (¿sube, baja, lateral? — vía pendiente de medias o retorno acumulado sobre una ventana). Volatility (¿calma o agitado? — vía desviación estándar de retornos, normalizada). Behavior (¿persistente/tendencial o mean-reverting? — vía autocorrelación de retornos). Y Stress (¿hay un drawdown desarrollándose?). Cada eje se calcula de forma pura: misma entrada, misma salida, sin estado oculto, sin aleatoriedad. Luego una cascada de prioridad documentada deriva un `Regime` titular único a partir de los cuatro ejes.

El insight más afilado de XCAP está en cómo define Panic, y es donde casi todo el mundo se equivoca. La tentación es definir pánico como 'volatilidad alta' (ratio de stdev elevado). Es incorrecto. Un crash monótono — el precio cayendo en línea casi recta — tiene volatilidad INTERNA baja, porque cada vela se parece a la anterior. Si defines pánico por stdev, te pierdes exactamente el crash más peligroso. La definición correcta de XCAP: pánico es un drawdown grande desarrollándose RÁPIDO, medido por un retorno reciente muy negativo y agudo, no por la dispersión. Esto es lo que distingue a un clasificador pensado por alguien que miró crashes reales de uno que copió una fórmula de un libro.

La pureza no es un capricho estético, es la base de la confianza. `regime.py` es una función pura: `classify(bars) -> Regime`. No lee de disco dentro de sí, no llama a la red, no muta nada global, no tiene rama aleatoria. Esto significa que puedes correrla mil veces sobre la misma ventana y obtener la misma etiqueta, puedes testearla con fixtures deterministas, y puedes auditar exactamente por qué dijo 'Panic' en una fecha concreta. Un clasificador con estado oculto es un clasificador en el que no puedes confiar para construir Market Memory encima.

La regla más importante, y la que conecta con toda la constelación: el clasificador es label-only. JAMÁS dimensiona ni opera. Devuelve una etiqueta y nada más. La razón es de arquitectura de honestidad: si el mismo módulo que diagnostica el régimen también decide el tamaño de la posición, tienes un incentivo para que el diagnóstico justifique la operación que ya querías hacer. Separar el diagnóstico de la acción es lo que permite, en SG-03, medir honestamente si el régimen tiene valor predictivo — porque la etiqueta se generó sin saber qué ibas a hacer con ella.

Para implementarlo bien, documenta la cascada de prioridad como código legible, no como una maraña de ifs. Por ejemplo: si Stress dispara Panic, gana Panic sobre cualquier otra cosa; si no, y Volatility es alta con Trend fuerte, es Trending-Volatile; si Behavior es mean-reverting y Trend es lateral, es Range; etc. Cada rama debe tener un comentario que explique el porqué del mercado, no solo el umbral. Ese comentario es lo que un revisor — o tú mismo en seis meses — necesita para confiar en la etiqueta.

El hallazgo central de la auditoría de XCAP fue demoledor: cada módulo previo era o computación stateless o un acumulador pasivo; NADA registraba una predicción falsable antes del desenlace y luego puntuaba su propia calibración. Ese loop ausente es exactamente lo que hace que un sistema de research sea difícil de engañar, y la única fuente honesta de evidencia de edge. Market Memory (`market_memory.py`) es ese loop. Si no construyes este módulo, todo lo demás es teatro: cálculos bonitos que nunca se confrontan con la realidad.

El corazón es `advance_market_memory(universe, state_dir, horizon_days=5, ...)` y su secuencia es sagrada en este orden: observar fechas nuevas → clasificar el régimen (usando el `regime.py` de SG-02) → registrar un forecast BLOQUEADO (un baseline derivado del régimen, con su probabilidad y su horizonte) → resolver los forecasts que ya maduraron contra el retorno forward realizado → puntuar. El bloqueo es la palabra clave: una vez registras 'en la fecha T predigo prob_up=0.62 a 5 días', ese registro es inmutable. No puedes volver a tocarlo cuando ves el resultado. Esa inmutabilidad es lo que convierte el ledger en evidencia y no en una racionalización a posteriori.

Las métricas no son una sola; son un panel honesto. Hit-rate (¿qué fracción de predicciones direccionales acertó?). Brier score (¿qué tan bien calibradas estaban las probabilidades? — penaliza tanto la sobreconfianza como la subconfianza). Calibración por bucket de confianza (cuando dijiste 70%, ¿acertaste el 70% de las veces?). Y la joya: hit-rate POR RÉGIMEN. Esta última es la que de verdad informa: te dice si tu predicción tiene valor en tendencia pero es basura en rango, o si solo aciertas en calma. Un hit-rate global de 55% puede esconder 70% en tendencia y 40% en pánico — y esa descomposición es la que dice dónde, si acaso, hay edge.

La propiedad anti-fabricación es por construcción (la profundizamos en SG-04, pero aquí es estructural): solo se resuelven forecasts cuyo horizonte ya maduró con datos que existían DESPUÉS de la fecha del forecast. Es out-of-sample por diseño. Nunca puedes 'predecir' una fecha cuyo resultado ya conoces, porque el forecast se bloqueó en T y solo se resuelve cuando llega T+horizon con datos reales. El state dir está gitignored — no se versiona el historial para que no haya tentación de editarlo a mano y maquillar resultados.

Las tres propiedades de integridad que XCAP impone, y que debes replicar: acumula (el ledger crece entre corridas, nunca se resetea), idempotente (correr el tick dos veces sobre las mismas fechas no duplica forecasts ni los resuelve dos veces), y Gate-closed (jamás opera). Esta es la misma familia de invariantes que el capital invariant de SG-05: el estado del sistema es la suma de eventos reales, nunca un replay ni un baseline fresco. El CLI `market-memory-tick` orquesta esto y lee CSVs formato `data/real` (lowercase) vía `LocalCSVSource` — cero red, todo determinista desde disco.

Un punto que separa al ingeniero del aficionado: el baseline que registras debe ser honesto y modesto. XCAP registra un 'regime_baseline' — una probabilidad derivada del régimen, no un modelo elaborado que ya optimizaste mirando el pasado. ¿Por qué empezar humilde? Porque el baseline es tu vara de medir. Si un forecaster sofisticado no le gana al baseline de régimen out-of-sample, no tienes edge, tienes overfitting. Market Memory existe para refutar tus ideas, no para confirmarlas. Y un buen registro de forecasts es evidencia, nunca prueba — por eso el Capital Gate sigue cerrado por mucho que el hit-rate se vea bien.

La pregunta que define este módulo: ¿cómo construyes un sistema que no PUEDA mentirte sobre si tiene edge? La respuesta de XCAP no es 'ser cuidadoso'. Es introducir adversarios estructurales — null controls — contra los que toda afirmación de edge debe competir. El Hypothesis Lab (`hypothesis_lab.py`) tiene un registro de forecasters reales (regime_baseline, trend_follow, momentum_follow, mean_revert) Y dos controles nulos deliberados: `always_up` (el null de DERIVA — el mercado sube de media, ¿tu forecaster solo está capturando eso?) y `coin_flip` (el null de AZAR — sembrado y determinista, ¿le ganas a tirar una moneda?). Un forecaster que no le gana a AMBOS nulos no tiene edge, tiene una ilusión.

El segundo pilar es la significancia con corrección por comparaciones múltiples. Si pruebas veinte forecasters, alguno parecerá bueno por puro azar — es el problema del data-snooping. XCAP lo neutraliza con un umbral z corregido por Bonferroni que ESCALA con K (el número de forecasters evaluados): cuantas más hipótesis pruebas, más alta la vara que cada una debe superar. `evaluate_forecasters(universe, names, horizon_days, min_samples, alpha)` compara cada forecaster real contra ambos nulos (Δazar y Δderiva) y solo le otorga `candidate_edge` si le gana al azar Y a la deriva Y supera el umbral corregido Y tiene al menos `min_samples` observaciones. Las cuatro condiciones, conjuntas. Quitar cualquiera abre una puerta a la fabricación.

El detalle que demuestra que el sistema es honesto y no está amañado: `edge_demonstrated` es SIEMPRE False. El lab puede otorgar `candidate_edge` — 'esto merece más investigación' — pero nunca declara edge demostrado, porque ningún backtest, por bueno que sea, prueba edge futuro. Esta es una decisión de diseño que protege contra tu propio optimismo: el sistema literalmente no tiene un camino de código que diga 'sí, tienes edge, opera'. El Capital Gate sigue cerrado por construcción, no por tu disciplina.

La verificación de que el scoreboard no está trucado es elegante y la debes replicar: XCAP comprobó que sobre tendencias sintéticas, `trend_follow` gana en grande (detecta la señal real), `mean_revert` se va significativamente NEGATIVO (detecta un anti-edge — apostar contra la tendencia pierde), y `coin_flip` aterriza en ~50% (el azar no se ve premiado). Si tu coin_flip saliera con 60% de hit-rate, tu pipeline está roto o tienes leakage. Los nulls no son solo adversarios: son sondas de calibración de tu propio sistema de medición. Un coin_flip que no da ~50% es un sistema que se está mintiendo, y debes pararlo todo hasta entender por qué.

El fundamento compartido evita el truco de mover la portería: `scoring.py` es la única fuente de verdad para las primitivas (prob_up, is_hit, brier, conf_bucket, hit_rate_z). Tanto Market Memory (SG-03) como el Hypothesis Lab puntúan con EL MISMO código. Si tuvieras dos implementaciones de 'hit', podrías — consciente o no — usar la más generosa para tu forecaster favorito. Una sola primitiva compartida cierra esa puerta. Esto es anti-fabricación por construcción: no puedes elegir la regla que te conviene porque solo hay una regla.

Toda evaluación es out-of-sample por la misma mecánica de SG-03: cada barra se clasifica una sola vez, el forecast se genera sin ver el futuro, y se resuelve contra el retorno forward real. El doc `docs/HYPOTHESIS_LAB.md` y los 4 invariantes del `check` codifican estas garantías. La lección de fondo, que es la tesis de toda la constelación Signal: el binding constraint para operar capital real es edge DEMOSTRADO, y estas herramientas miden edge honestamente (null controls + significancia) en vez de afirmarlo. Un sistema que solo puede emitir `candidate_edge` y nunca `edge_demonstrated` es un sistema que respeta lo que no sabe.

Este módulo nace de un fallo real y doloroso en XCAP, y por eso enseña tan bien. Un autorun programado estaba silenciosamente RESETEANDO el ledger al balance inicial de 500 y reproduciendo el mismo fixture idéntico cada 5 minutos. El sistema mostraba actividad, números cambiando, parecía vivo — y era completamente falso. Tres reglas se violaban a la vez, y son las tres que definen el capital invariant. Memoriza estas reglas porque son el núcleo: acumula, realized-only, y re-entry continúa sesiones previas.

Regla 1 — Acumula. El capital NO se resetea entre corridas ni sesiones. Si terminaste la sesión de ayer con 547.30, hoy empiezas con 547.30. Un baseline fresco cada arranque no es contabilidad, es una demo disfrazada. El ledger se carga del disco al iniciar y se persiste al terminar; el estado vive entre ejecuciones.

Regla 2 — Realized-only. El balance solo se mueve cuando una posición se CIERRA/vende. El P&L no realizado (mark-to-market, el valor flotante de una posición abierta) jamás infla el balance. La invariante exacta, que debes poder afirmar en cualquier momento: `current_balance == starting_balance + realized_pnl`. Una posición abierta con +200 de ganancia flotante NO cambia el balance; solo lo hace cuando la cierras y esos +200 se vuelven realizados. Esto evita la trampa psicológica más vieja del trading: contar las ganancias antes de embolsarlas.

Regla 3 — Re-entry continúa. Al reiniciar, el capital es el resultado acumulado de las operaciones de sesiones previas, no una línea base nueva. El sistema debe poder apagarse y encenderse mil veces y el capital ser siempre la suma honesta de todos los cierres reales que ocurrieron. Esto es lo mismo que la propiedad de acumulación de Market Memory (SG-03): el estado es la suma de eventos reales, una sola dirección, sin replay.

La lección de arquitectura es la distinción entre dos comandos que XCAP mantiene deliberadamente separados. El autorun programado corre `sim-autopilot-tick`: carga el ledger existente, rota regímenes sintéticos, y ACUMULA sobre lo anterior. Existe también `sim-run-agent`, que resetea y reproduce un fixture — pero ese se conserva SOLO para demos deterministas, y JAMÁS debe ser lo que corre el autorun. El bug fue precisamente apuntar el scheduler al comando equivocado. La enseñanza: un comando que resetea y un comando que acumula nunca deben ser confundibles; nómbralos de forma que el peligroso grite lo que hace.

Cómo se blinda esto para que no vuelva a romperse: la invariante está LOCKED por `tests/test_sim_autopilot_tick.py`. Si tocas el ledger o el autorun, esos tests deben seguir verdes. No es documentación, es un candado ejecutable. La regla operativa que el usuario impuso enfáticamente: si tocas la contabilidad, corres ese test, y si se pone rojo, has roto la integridad del capital y paras. Esta es la misma filosofía que el Capital Gate y el `check` de SG-01: las invariantes que de verdad importan se codifican como tests que se niegan a dejarte romperlas. La contabilidad de XCAP no es confiable porque el autor sea cuidadoso; es confiable porque un test rojo le impide ser descuidado.

Un autopilot tick es código que corre sin un humano mirando, y esa es exactamente la razón por la que debe ser el código MÁS disciplinado del sistema. El error que XCAP sufrió en carne propia lo enseña todo: un tick programado que cada 5 minutos reseteaba el ledger y replicaba un fixture idéntico. Visto desde fuera, el sistema parecía vivo — números moviéndose, actividad constante. Por dentro era una mentira en bucle. La pregunta que define un buen tick: ¿este loop, corriendo mil veces, ACUMULA algo verdadero, o solo genera la apariencia de actividad?

Propiedad 1 — Determinista desde disco. El tick lee su entrada de disco (CSVs `data/real` vía `LocalCSVSource`), no de la red. Los loops automáticos de XCAP NUNCA habilitan red — `allow_network` queda en False, siempre. Esto es continuidad directa de SG-01: la red es opt-in explícito por llamada humana (el comando `data-fetch`), jamás algo que un loop autónomo active solo. Un tick que toca la red sin supervisión es un tick que puede filtrar, fallar de forma no reproducible o colgarse esperando un socket. Determinista desde disco significa que el mismo estado en disco produce el mismo resultado, audaz y reproducible.

Propiedad 2 — Idempotente. Correr el tick dos veces sobre las mismas fechas no debe duplicar forecasts, ni re-resolver lo ya resuelto, ni contar dos veces un cierre. Esto importa muchísimo en loops porque los schedulers fallan, reintentan, se solapan. Si tu tick no es idempotente, un reintento corrompe el estado en silencio. La forma de lograrlo: cada evento (un forecast, un cierre) tiene una clave natural (fecha+símbolo) y el tick comprueba existencia antes de escribir. `advance_market_memory` y `sim-autopilot-tick` son idempotentes por esta razón.

Propiedad 3 — Acumula, no resetea. El tick carga el estado previo y construye SOBRE él. `sim-autopilot-tick` carga el ledger, rota regímenes sintéticos, y acumula — exactamente la regla del capital invariant de SG-05 y de Market Memory de SG-03. Esta es la misma invariante apareciendo por tercera vez en la constelación, y no es casualidad: la honestidad de un sistema autónomo ES su negativa a resetearse. Un loop que empieza de cero cada vez no aprende nada; un loop que acumula es lo único que puede construir un historial de calibración que valga.

Propiedad 4 — Gate-cerrado por construcción. El tick JAMÁS opera capital real. El Capital Gate (`capital/broker/live_trading/automation` todos en False) está verificado por `python3 -m xcap.control check`. Un autopilot es justo donde un sistema de trading mata a su dueño: corre solo, y si tuviera capacidad de operar en real, un bug a las 3am vacía la cuenta. Por eso en XCAP el autopilot es sim-only, sin excepción, y `check` lo afirma en cada corrida. La automatización y la capacidad de operar real son dos cosas que NUNCA deben coexistir sin una decisión humana deliberadísima.

Cómo se opera y se blinda todo esto: el tick corre vía el scheduler (en XCAP, una tarea programada que invoca `sim-autopilot-tick`, el comando que acumula — NUNCA `sim-run-agent`, el que resetea para demos). El comportamiento queda LOCKED por `tests/test_sim_autopilot_tick.py`: si tocas el autorun, esos tests siguen verdes o has roto la integridad del loop. Y cada corrida termina con un `check` que reafirma los invariantes (keyless, Gate-cerrado, acumulación). El principio final, que sella la constelación entera: un loop honesto es uno cuyas garantías no dependen de que alguien lo vigile, porque están codificadas como tests e invariantes que el propio loop verifica en cada vuelta. Construye loops que se nieguen a mentir incluso cuando nadie mira — esa es la única automatización en la que un sistema de research puede confiar.