RE:CZ

Signal Trader Interview Summary and Event Sourcing Design Draft

Capital Protracted War

👤 Financial trading system engineers, product managers, auditors, focusing on system design, allocation precision, and auditability.
This document records the Signal Trader design interview around LOGS/71, aiming to converge concepts into implementable system rules. Key contents include: Signal Trader must follow the capital persistence principle, the minimum signal semantics are product_id + direction, nominal value decision authority lies with Signal Trader, multiple signals are executed using netting consolidation, subscription ID serves as the allocation granularity, and the isolation principle must not be violated. Regarding funds and allocation, independent investor buffer pools are established, with VC calculations supporting lazy evaluation. Execution strategy prioritizes market orders, and accounting adopts a dual-track system. Exception handling emphasizes that active system liquidation is not allowed during positions. The audit system employs an event sourcing mechanism, where audit logs are event streams, and state is reconstructed via reducer replay, ensuring traceability, consistency, and replayability. The article also lists the v1 minimum event list and next steps, aiming to advance the system toward provable correctness and enter an auditable, scalable, and production-ready engineering phase.
  • ✨ Signal Trader core constraints include position sizing based on loss, signal semantics, nominal value decision authority, etc.
  • ✨ Adopts an event sourcing audit system where audit logs are event streams and state is reconstructed via reducer replay.
  • ✨ Multi-investor allocation uses subscription ID as the granularity, establishes independent buffer pools, and the isolation principle must not be violated.
📅 2026-03-12 · 770 words · ~4 min read
  • Signal Trader
  • Event Sourcing
  • Allocation Rules
  • Audit System
  • Engineering Implementation
  • Design Draft
  • Interview Summary

Signal Trader Interview Summary and Event Sourcing Design Draft

It is Thursday, March 12, 2026, in the afternoon.

Today, we conducted a round of interviews focused on engineering implementation for the LOGS/71 Signal Trader design. The goal was to converge conceptual constraints into implementable system rules, particularly regarding multi-investor account splitting precision, isolation principles, and audit replayability.

Core Constraints Confirmed This Session

  1. Signal Trader must adhere to the principle of capital endurance warfare: position sizing based on loss, hard risk constraints, and maximizing capital efficiency.
  2. The minimum semantic unit of a signal is product_id + direction(-1/0/1); stop_loss_ratio is optional; timing is based on the moment the Signal Trader receives the signal.
  3. The decision-making authority for notional value lies entirely with the Signal Trader; the signal side cannot inject freedom regarding position sizing.
  4. direction=0 has a strong semantic meaning: immediately close the current position and forcibly maintain a flat position.
  5. stop_loss_ratio cannot be changed during an open position; changes only take effect on the next opening trade.
  6. If opening a position requires a stop-loss but stop_loss_ratio is missing, reject the opening trade.
  7. Multiple signals for the same product are executed using netting consolidation; when positions completely offset, use the order book mid price for unified settlement.
  8. When multiple subscription units exist, use "Subscription ID" as the granularity for account splitting; one investor can have multiple subscriptions to the same signal.
  9. The isolation principle cannot be violated; costs incurred by an investor's immediate capital withdrawal are borne solely by that investor.
  10. The system prioritizes optimizing the precision of multi-investor account splitting (highest priority for MVP).

Capital and Account Splitting Rules

Investor-Specific Buffer Pool

  • Residual amounts do not enter a common pool; they go into an investor-specific independent buffer pool.
  • Funds in the buffer pool always belong to that investor, but may be temporarily non-withdrawable due to minimum precision limits.
  • The buffer pool is part of that investor's VC (Virtual Capital) system; there is no additional action to "merge back into VC".

VC Calculation Trigger

  • Lazy evaluation is allowed to be triggered by multiple event types (signal trigger, subscription change, query, scheduled task).
  • The core constraint is to avoid frequent fund transfer actions, prioritizing ledger calculations over on-chain/external fund movements.

Execution and Fill Strategy

  1. In the current phase, prioritize using market orders to chase entry, prioritizing fill guarantee.
  2. Use dual-track accounting:
    • Record an execution event upon successful order submission.
    • Record a fill event and corresponding position/ledger changes upon receiving a fill confirmation.
  3. For complete internal netting (no external fill):
    • Use the order book mid price for unified settlement.
    • Record the source and timestamp of the captured mid price in the audit log.

Exception Handling Principles

  • The system is not allowed to actively close positions during a holding period (unless the signal explicitly provides direction=0).
  • No cooldown period is set for signal-side jitter; no artificial frequency reduction before VC funds are exhausted.
  • When direction=0 arrives, even if there is no position, record a successful audit event to verify signal link health.
  • Key alert item: a large number of rejected orders in a short period.

Audit System: Action / Reducer Replay Mechanism

It was clarified this time to adopt: Audit logs are the event stream; state is derived by replaying events through reducers.

This is essentially Event Sourcing:

  • Audit logs are append-only; no physical rollbacks.
  • System state (positions, VC, account splits) is obtained by replaying events.
  • The same event stream + the same reducer version must yield a deterministic, consistent state.

Suggested Event Layering

  1. Intent*: Signal intent layer (e.g., signal received, target position change).
  2. Execution*: Execution layer (order submission, order rejection, fill confirmation).
  3. Ledger*: Ledger layer (position/VC/account split results posted to ledger).

Order Rejection Semantics (Critical)

Rejection is not "deleting history" but "appending compensating events":

  1. Record IntentCreated.
  2. Attempt execution; if the order is rejected, record OrderRejected.
  3. Append compensating events to release held resources (e.g., IntentReleased).
  4. The position ledger is driven solely by fill facts, not altered by rejected intents.

This approach balances three aspects:

  • Audit traceability (history is not lost)
  • Ledger consistency (failed executions are not recorded as successful positions)
  • Replayable troubleshooting (can explain why each step did not result in a fill)

v1 Minimum Event List (Draft)

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

Next Steps

  1. Finalize the event schemas (fields, idempotency keys, version numbers).
  2. Draw the reducer state machine (split into Intent/Execution/Ledger three layers).
  3. Add a set of regression test cases for "replayable consistency" (order rejection, partial fills, complete netting, withdrawal residuals).
  4. Advance implementation with "multi-investor account splitting precision" as the primary acceptance criterion.

The value of this interview lies in advancing from "conceptually correct" to "systematically provably correct." On this foundation, Signal Trader can truly enter the engineering phase of being auditable, scalable, and ready for live trading.

See Also

Referenced By