Saltar a contenido

Cómo leer este manual

Qué vas a aprender

  • Qué itinerario de lectura te conviene según tu perfil.
  • Qué significan los recuadros, los diagramas y los estados (PASS, VARIANT, …).
  • Qué componentes forman la plataforma y qué papel tiene cada uno (banco de backtesting, runtime causal, motores de modelos, datos y APIs).

Un manual en capas

FinazTradingEngine es una plataforma de investigación cuantitativa causal y reproducible: datos point-in-time, un banco de backtesting con dos motores de paridad verificable (NautilusTrader y VectorTA) que actúa como oráculo, y una familia de motores de modelado y optimización (Ridge, CatBoost, ARIMA/ETS/GARCH, NHITS, Chronos-2, TimesFM 2.5, ERC y CP-SAT) sobre PostgreSQL, ClickHouse, Redpanda y MinIO, todo certificado por gates.

Piensa en el manual como en un edificio: la Parte I son los cimientos (conceptos de mercado y de backtesting que no dependen de este proyecto); el Catálogo de motores es el directorio del edificio (qué motor hay en cada planta y para qué sirve); las Partes II–V son las plantas de datos, backtesting, indicadores y estrategias; la Parte VI es la API de backtesting y análisis; la Parte VII, el runtime causal, el streaming y los modelos; la Parte VIII es la sala de máquinas (operación) y la Parte IX, la biblioteca (glosario, FAQ, ejercicios, referencias).

flowchart BT
    I["I · Fundamentos"] --> CAT["Catálogo de motores"]
    CAT --> II["II · Datos"]
    II --> III["III · Motores"]
    III --> IV["IV · Indicadores"]
    IV --> V["V · Estrategias"]
    V --> VI["VI · API de backtesting"]
    CAT --> VII["VII · Runtime y modelos"]
    VII --> VIII["VIII · Operación"]
    VIII --> IX["IX · Anexos"]

Itinerarios por perfil

  1. Mapa del sistema y Catálogo de motores.
  2. Backtesting causal (las reglas que el código impone).
  3. Parte II (datos) y Parte III (motores, carriles, ledger).
  4. Parte VI (API de backtesting) y Parte VII (runtime causal: FlowSpec, runtime, API de plataforma, modelos).
  5. Referencias para saltar a los ficheros del repo.

Convenciones

Recuadros (admoniciones)

Nota

Información de contexto o un matiz útil.

Consejo

Un atajo o buena práctica.

Cuidado

Algo que, si se ignora, produce resultados falsos o rompe el servidor.

Ejemplo

Un caso concreto, casi siempre con cifras reales del repositorio.

Recuadro plegable

Detalle opcional para quien quiera profundizar. Pulsa para abrirlo.

Estados que verás a menudo

Estado Significado
PASS Verificado con evidencia (test, log, artefacto con hash).
VARIANT Diferencia declarada y medida entre motores (p. ej., otra semilla de un indicador). No es un fallo, pero no se publica como PASS.
UNSUPPORTED No se puede hacer con ese motor o carril, con motivo.
PARITY_FAIL Dos carriles que debían coincidir no coinciden; se informa la primera divergencia con ±5 barras de contexto.
INCOMPLETO Gate cuya evidencia depende de algo pendiente, simulado u omitido.
NOT_MEASURED La magnitud no se midió; no es un cero.

Código y comandos

  • Los bloques de código tienen botón de copiar (esquina superior derecha).
  • Los secretos se escriben siempre como <TOKEN>; nunca encontrarás una clave real.
  • Las rutas de ficheros son relativas a la raíz del repositorio FinazTradingEngine.
  • Los comandos del banco de backtesting se ejecutan siempre dentro de Docker; los del runtime y los motores de modelos, en el servidor finaz-new como iort-user.

Componentes de la plataforma

Una plataforma, varios componentes

  • Banco de backtesting (finazbench): NautilusTrader, VectorTA y el ledger SIM-S, hitos H0–H4. Es el oráculo de paridad: la referencia contra la que se mide el resto.
  • API de backtesting y análisis: bench-api en :8000, rutas /v1/....
  • Runtime causal: ClockEngine, FlowSpec y ejecución batch/replay/stream (paquetes packages/finaz_*, Compose finaz-trading-engine).
  • Motores de modelos: imágenes quant, opt, neural, chronos, timesfm25.
  • API de plataforma: loopback 127.0.0.1:18300, rutas /platform/v1/....
  • Datos: PostgreSQL, ClickHouse, Redpanda y MinIO compartidos.
  • Todo certificado por los gates H0–H4, G0–G9 y S0–S6.

Cómo está hecho cada capítulo

Cada capítulo sigue la misma plantilla, para que sepas siempre dónde estás:

  1. Qué vas a aprender — los objetivos.
  2. Conceptos — explicados antes que los comandos, con analogías y diagramas.
  3. Práctica — comandos y ejemplos reales.
  4. Resumen — lo que debes llevarte.
  5. Para practicar — ejercicios; las soluciones esbozadas están en Ejercicios.

Resumen

  • Hay tres itinerarios (quant, desarrollador, operador); la Parte I es común a todos.
  • VARIANT, UNSUPPORTED, INCOMPLETO y NOT_MEASURED son honestidad declarada, no errores escondidos.
  • El banco de backtesting es el oráculo de paridad; el runtime y los motores de modelos se validan contra él.

Para practicar

  1. Elige tu perfil y anota los cinco capítulos que vas a leer primero.
  2. Busca en el Glosario la diferencia entre VARIANT y PARITY_FAIL.