RE:CZ

Resumen de la entrevista sobre Signal Trader y borrador de diseño de Event Sourcing

Guerra Prolongada del Capital

👤 Ingenieros de sistemas de trading financiero, gerentes de producto, auditores, interesados en diseño de sistemas, precisión de reparto de cuentas y auditabilidad.
Este documento registra la entrevista de diseño de Signal Trader en torno a LOGS/71, con el objetivo de converger conceptos en reglas de sistema realizables. Los contenidos clave incluyen: Signal Trader debe seguir el principio de guerra prolongada de capital, la semántica mínima de señal es product_id + dirección, la decisión de valor nominal recae en Signal Trader, múltiples señales se ejecutan fusionadas por neteo, se usa el ID de suscripción como granularidad de reparto de cuentas, el principio de aislamiento no puede violarse. En cuanto a fondos y reparto, se establece un pool de amortiguación independiente para inversores, el cálculo de VC admite evaluación perezosa. La estrategia de ejecución prioriza órdenes a mercado, la contabilidad adopta un sistema de doble vía. El manejo de excepciones enfatiza que no se permite el cierre activo de posiciones por el sistema. El sistema de auditoría emplea el mecanismo de Event Sourcing, el registro de auditoría es el flujo de eventos, el estado se obtiene mediante replay del reducer, asegurando trazabilidad, consistencia y reproducibilidad. El artículo también enumera la lista mínima de eventos para v1 y los próximos pasos, con el objetivo de avanzar hacia un sistema demostrablemente correcto, entrando en la fase de ingeniería auditable, escalable y lista para producción.
  • ✨ Las restricciones clave de Signal Trader incluyen determinar posición por pérdida, semántica de señal, decisión de valor nominal, etc.
  • ✨ Se adopta un sistema de auditoría basado en Event Sourcing, donde el registro de auditoría es el flujo de eventos y el estado se obtiene mediante replay del reducer.
  • ✨ El reparto de cuentas para múltiples inversores usa el ID de suscripción como granularidad, estableciendo un pool de amortiguación independiente, y el principio de aislamiento no puede violarse.
📅 2026-03-12 · 989 words · ~5 min read
  • Signal Trader
  • Event Sourcing
  • Reglas de reparto de cuentas
  • Sistema de auditoría
  • Implementación de ingeniería
  • Borrador de diseño
  • Resumen de entrevista

Table of Contents

Borrador de diseño de registro de entrevista y trazabilidad de eventos para Signal TraderRestricciones clave establecidas en esta sesiónReglas de capital y distribución de cuentasPools de amortiguación independientes por inversorActivación del cálculo del VCEstrategia de ejecución y ejecución de órdenesPrincipios de manejo de excepcionesSistema de auditoría: Mecanismo de re-ejecución Action / ReducerSugerencia de capas de eventosSemántica de rechazo de órdenes (clave)Lista mínima de eventos para v1 (borrador)Próximos pasos

Borrador de diseño de registro de entrevista y trazabilidad de eventos para Signal Trader

Es jueves 12 de marzo de 2026, por la tarde.

Hoy se realizó una ronda de entrevistas centradas en la implementación de ingeniería para el diseño de Signal Trader en torno a LOGS/71. El objetivo fue converger las restricciones conceptuales en reglas de sistema realizables, especialmente en cuanto a la precisión de distribución de cuentas para múltiples inversores, los principios de aislamiento y la capacidad de re-ejecución para auditoría.

Restricciones clave establecidas en esta sesión

  1. Signal Trader debe seguir el principio de la guerra prolongada del capital: determinar la posición por la pérdida, restricción dura del riesgo, maximización de la eficiencia del capital.
  2. La semántica mínima de una señal es product_id + direction(-1/0/1); stop_loss_ratio es opcional; el tiempo se toma en el momento en que Signal Trader recibe la señal.
  3. La decisión sobre el valor nominal reside completamente en Signal Trader; el lado de la señal no puede inyectar libertad en la intensidad de la posición.
  4. direction=0 tiene una semántica fuerte: cerrar inmediatamente la posición actual y mantener forzosamente una posición plana.
  5. stop_loss_ratio no puede modificarse durante la tenencia de una posición; los cambios solo surten efecto en la próxima apertura.
  6. Si para abrir una posición se requiere un stop-loss pero falta stop_loss_ratio, rechazar la apertura.
  7. Múltiples señales para el mismo producto se ejecutan mediante compensación neta; cuando se compensan completamente, se liquida de manera unificada usando el mid del libro de órdenes.
  8. Cuando existen múltiples unidades de suscripción, el "ID de suscripción" sirve como granularidad para la distribución de cuentas; un inversor puede tener múltiples suscripciones a la misma señal.
  9. El principio de aislamiento no puede violarse; los costos generados por una retirada inmediata de fondos de un inversor son asumidos exclusivamente por ese inversor.
  10. El sistema prioriza optimizar la precisión en la distribución de cuentas para múltiples inversores (prioridad máxima para el MVP).

Reglas de capital y distribución de cuentas

Pools de amortiguación independientes por inversor

  • Los residuales no van a un pool común, sino a un pool de amortiguación independiente a nivel de inversor.
  • Los fondos en el pool de amortiguación siempre pertenecen a ese inversor, solo que pueden no ser retirables temporalmente debido a las limitaciones de precisión mínima.
  • El pool de amortiguación es parte del sistema VC de ese inversor; no existe una acción adicional de "reintegración al VC".

Activación del cálculo del VC

  • Se permite la evaluación diferida (Lazy Evaluate) activada por múltiples tipos de eventos (activación de señal, cambio de suscripción, consulta, temporizador).
  • La restricción clave es evitar acciones frecuentes de transferencia de fondos, priorizando el cálculo en el libro mayor sobre las acciones en cadena/externas de fondos.

Estrategia de ejecución y ejecución de órdenes

  1. En la etapa actual, se prioriza el uso de órdenes a mercado para entrar, priorizando garantizar la ejecución.
  2. La contabilidad se realiza en doble vía:
    • Se registra un evento de ejecución cuando la orden se envía con éxito.
    • Se registra un evento de ejecución completada y los cambios en el libro mayor de posiciones cuando llega la confirmación de ejecución.
  3. En caso de compensación interna completa (sin ejecución externa):
    • Se utiliza el mid del libro de órdenes para una liquidación unificada.
    • Se registra en el log de auditoría la fuente del valor mid y el momento de su captura.

Principios de manejo de excepciones

  • No se permite que el sistema cierre posiciones activamente durante la tenencia (a menos que la señal proporcione explícitamente direction=0).
  • No se establece un tiempo de enfriamiento para las fluctuaciones del lado de la señal; no se reduce artificialmente la frecuencia antes de que se agoten los fondos del VC.
  • Cuando llega un direction=0, incluso si no hay posición, se registra un evento de auditoría de éxito, para verificar la salud del enlace de señal.
  • Elemento de alerta clave: un gran volumen de rechazos de órdenes en un corto período.

Sistema de auditoría: Mecanismo de re-ejecución Action / Reducer

En esta sesión se acordó adoptar: El log de auditoría es el flujo de eventos, y el estado se obtiene re-ejecutando el reducer.

Esto es esencialmente Event Sourcing:

  • El log de auditoría es de solo anexado (append-only), sin reversiones físicas.
  • El estado del sistema (posiciones, VC, distribución de cuentas) se obtiene re-ejecutando los eventos.
  • El mismo flujo de eventos + la misma versión del reducer deben producir un estado determinista y consistente.

Sugerencia de capas de eventos

  1. Intent*: Capa de intención de señal (ej., recepción de señal, cambio de posición objetivo).
  2. Execution*: Capa de ejecución (envío de orden, rechazo de orden, confirmación de ejecución).
  3. Ledger*: Capa de libro mayor (asentamiento de resultados de posición/VC/distribución).

Semántica de rechazo de órdenes (clave)

Rechazar una orden no es "borrar el historial", sino "añadir un evento de compensación":

  1. Registrar IntentCreated.
  2. Intentar ejecutar; si la orden es rechazada, registrar OrderRejected.
  3. Añadir un evento de compensación que libere los recursos reservados (ej., IntentReleased).
  4. El libro mayor de posiciones solo se modifica por hechos de ejecución, no por intenciones rechazadas.

Esto permite equilibrar tres aspectos:

  • Trazabilidad para auditoría (sin pérdida de historial)
  • Consistencia del libro mayor (no registrar ejecuciones fallidas como posiciones exitosas)
  • Re-ejecución para resolución de problemas (explicar por qué no se ejecutó en cada paso)

Lista mínima de eventos para v1 (borrador)

  1. SignalReceived
  2. IntentCreated
  3. OrderSubmitted
  4. OrderRejected
  5. OrderAccepted
  6. OrderFilled
  7. InternalNettingSettled
  8. PositionUpdated
  9. InvestorLedgerUpdated
  10. BufferAdjusted
  11. SubscriptionUpdated
  12. SignalForcedFlatHandled (ruta de direction=0)
  13. MidPriceCaptured
  14. AlertTriggered

Próximos pasos

  1. Finalizar primero el esquema de eventos (campos, clave de idempotencia, número de versión).
  2. Dibujar la máquina de estados del reducer (dividida en las tres capas Intent/Execution/Ledger).
  3. Complementar con un conjunto de casos de prueba de regresión para "consistencia en re-ejecución" (rechazo de órdenes, ejecución parcial, compensación completa, residuales por retirada).
  4. Avanzar en la implementación tomando la "precisión en la distribución de cuentas para múltiples inversores" como el primer criterio de aceptación.

El valor de esta entrevista radica en que hemos llevado lo "conceptualmente correcto" hacia lo "demostrablemente correcto a nivel de sistema". Sobre esta base, Signal Trader puede realmente entrar en la fase de ingeniería de ser auditable, escalable y listo para operar en tiempo real.

See Also

Referenced By