Saltar a contenido

SDP vNext: MATVARD + Session Auction Map (SAM)#

Fecha: 2026-04-09 Estado: Activo (plan canónico de nueva etapa)

1. Objetivo#

Implementar una versión limpia y auditable de SDP orientada a trading cuantitativo contextual intradía, combinando: - ontología de mercado MATVARD (subasta, valor, aceptación/rechazo), - formalización SAM (clasificación de sesión/día + reglas cuantificables + validación estadística).

Regla de arquitectura: - no usar componentes humanos/no computables como dependencia runtime; - conservarlos solo como referencia histórica en archivo.

2. Alcance#

Incluido#

  • Motor de contexto intradía por sesión (Asia/Londres/NY).
  • Clasificación cuantitativa de tipo de día.
  • Modelo de valor y aceptación/rechazo con reglas objetivas.
  • Gate de ejecución basado en score de contexto + trigger.
  • Riesgo adaptativo por régimen.
  • Observabilidad, backtest walk-forward y promotion gates.

Excluido (runtime)#

  • Módulos de mentalidad/entrenamiento humano.
  • Reglas discrecionales sin definición numérica reproducible.

3. Contrato técnico vNext#

3.1 Entidades mínimas#

  • session_state:
  • asia_range, london_range, ny_range, session_owner.
  • day_type_state:
  • balance|trend|neutral|double_distribution + confianza.
  • value_state:
  • vah, val, poc, open_vs_value, value_shift.
  • acceptance_state:
  • accepted_above, accepted_below, rejected_above, rejected_below.
  • context_score:
  • score [0..100] con desglose de factores.
  • execution_decision:
  • trade|no_trade, reason_codes, risk_profile, invalidations.

3.2 Regla canónica de decisión#

  1. Clasificar sesión y tipo de día.
  2. Medir estado de valor y apertura vs valor.
  3. Confirmar aceptación/rechazo por precio y tiempo.
  4. Calcular score contextual.
  5. Solo habilitar trigger si context_score >= umbral.

4. Arquitectura de implementación#

4.1 Capa A: Feature Layer#

  • Construir features por barra y por sesión.
  • Versionar esquema de features (features_schema_version).
  • Persistir features para reproducibilidad de backtest.

4.2 Capa B: State Engine#

  • Convertir features a estados de mercado (session_state, day_type_state, value_state, acceptance_state).
  • Evitar lógica de ejecución en esta capa.

4.3 Capa C: Decision Gate#

  • Unificar estados + microestructura + riesgo.
  • Emitir decisión binaria auditable (trade/no_trade) y reason_codes.

4.4 Capa D: Execution + Risk#

  • Entrada/salida con reglas consistentes (sin fill optimista).
  • Riesgo dinámico por contexto.
  • Hard-stop si no hay calidad de datos/contexto.

5. Roadmap por fases#

Fase 0: Baseline limpio (1-2 días)#

  • Congelar docs canónicos.
  • Archivar legacy metodológico.
  • Definir contrato de datos vNext.

Salida: - repositorio documental limpio, - plan y backlog vNext activos.

Fase 1: Session + Day Type Engine (3-5 días)#

  • Features de sesión.
  • Clasificación de tipo de día.
  • Métricas de calidad de clasificación.

Salida: - endpoint de estado de sesión/tipo de día, - pruebas unitarias base.

Fase 2: Value + Acceptance Engine (4-6 días)#

  • Modelo cuantitativo de VAH/VAL/POC.
  • Reglas objetivas de aceptación/rechazo.

Salida: - estado de valor y aceptación disponible por barra, - backtest de consistencia de etiquetas.

Fase 3: Context Score + Gate (4-6 días)#

  • Score contextual con pesos versionados.
  • Gate trade/no_trade con reason_codes.

Salida: - reporte de cobertura de decisiones, - reducción de overtrading en regímenes ambiguos.

Fase 4: Backtest robusto + walk-forward (3-5 días)#

  • Validación por ventanas rolling.
  • Costos reales (fees/slippage) obligatorios.
  • Comparativa vs baseline previo.

Salida: - paquete de evidencia por símbolo/timeframe.

Fase 5: Shadow -> Canary -> Live (continuo)#

  • Promotion gates por símbolo.
  • rollback automático por degradación.

Salida: - despliegue gradual con criterios objetivos.

6. Criterios de aceptación de vNext#

  • Reproducibilidad: mismas entradas -> mismas decisiones.
  • Trazabilidad: 100% decisiones con reason_codes.
  • Robustez: mejora consistente en PF/DD vs baseline bajo costos reales.
  • Operación: hard-stop y observabilidad activos en producción.

7. Riesgos y mitigación#

  • Riesgo: sobreajuste en clasificación de día.
  • Mitigación: walk-forward y validación por sesión.
  • Riesgo: ambigüedad en aceptación/rechazo.
  • Mitigación: umbrales objetivos + tests de frontera.
  • Riesgo: deriva documental.
  • Mitigación: índice canónico + archivo fechado por corte.

8. Convención de versión#

Nombre sugerido de etapa: SDP vNext-SAM1.

Notas: - Se puede renombrar a SDP v3 si deseas continuidad comercial. - Técnicamente, usar SAM1 ayuda a distinguirlo del linaje legacy.