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
- Signal Trader must adhere to the principle of capital endurance warfare: position sizing based on loss, hard risk constraints, and maximizing capital efficiency.
- The minimum semantic unit of a signal is
product_id + direction(-1/0/1);stop_loss_ratiois optional; timing is based on the moment the Signal Trader receives the signal. - The decision-making authority for notional value lies entirely with the Signal Trader; the signal side cannot inject freedom regarding position sizing.
direction=0has a strong semantic meaning: immediately close the current position and forcibly maintain a flat position.stop_loss_ratiocannot be changed during an open position; changes only take effect on the next opening trade.- If opening a position requires a stop-loss but
stop_loss_ratiois missing, reject the opening trade. - Multiple signals for the same product are executed using netting consolidation; when positions completely offset, use the order book
midprice for unified settlement. - When multiple subscription units exist, use "Subscription ID" as the granularity for account splitting; one investor can have multiple subscriptions to the same signal.
- The isolation principle cannot be violated; costs incurred by an investor's immediate capital withdrawal are borne solely by that investor.
- 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
- In the current phase, prioritize using market orders to chase entry, prioritizing fill guarantee.
- 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.
- For complete internal netting (no external fill):
- Use the order book
midprice for unified settlement. - Record the source and timestamp of the captured
midprice in the audit log.
- Use the order book
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=0arrives, 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
Intent*: Signal intent layer (e.g., signal received, target position change).Execution*: Execution layer (order submission, order rejection, fill confirmation).Ledger*: Ledger layer (position/VC/account split results posted to ledger).
Order Rejection Semantics (Critical)
Rejection is not "deleting history" but "appending compensating events":
- Record
IntentCreated. - Attempt execution; if the order is rejected, record
OrderRejected. - Append compensating events to release held resources (e.g.,
IntentReleased). - 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)
SignalReceivedIntentCreatedOrderSubmittedOrderRejectedOrderAcceptedOrderFilledInternalNettingSettledPositionUpdatedInvestorLedgerUpdatedBufferAdjustedSubscriptionUpdatedSignalForcedFlatHandled(path fordirection=0)MidPriceCapturedAlertTriggered
Next Steps
- Finalize the event schemas (fields, idempotency keys, version numbers).
- Draw the reducer state machine (split into
Intent/Execution/Ledgerthree layers). - Add a set of regression test cases for "replayable consistency" (order rejection, partial fills, complete netting, withdrawal residuals).
- 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.