How should an automated trading audit log be designed?
An audit log should reconstruct one signal from TradingView trigger to final broker result: signal ID, timestamps, normalized command, target account/symbol, validation, dispatch, cTrader result and duplicate/retry events—without secrets.
What this means in practice
An audit log should reconstruct one signal from TradingView trigger to final broker result: signal ID, timestamps, normalized command, target account/symbol, validation, dispatch, cTrader result and duplicate/retry events—without secrets. This page is specifically about “How should an automated trading audit log be designed?”, so each scenario below is explained by its own mechanism instead of sharing one generic diagnosis.
Real-world scenarios
Scenario A — Successful trace
Keep one signal ID through the TradingView event, normalized command, account/symbol routing, cTrader result and final position state. The trace should reconstruct this scenario without storing secrets. For Scenario A — Successful trace on question 50, use that evidence specifically to answer “How should an automated trading audit log be designed?”; keep it separate from the evidence for the other scenarios on this page.
Scenario B — Rejected trace
Keep one signal ID through the TradingView event, normalized command, account/symbol routing, cTrader result and final position state. The trace should reconstruct this scenario without storing secrets. For Scenario B — Rejected trace on question 50, use that evidence specifically to answer “How should an automated trading audit log be designed?”; keep it separate from the evidence for the other scenarios on this page.
Scenario C — Duplicate ignored
Keep one signal ID through the TradingView event, normalized command, account/symbol routing, cTrader result and final position state. The trace should reconstruct this scenario without storing secrets. For Scenario C — Duplicate ignored on question 50, use that evidence specifically to answer “How should an automated trading audit log be designed?”; keep it separate from the evidence for the other scenarios on this page.
Scenario D — Reconnect/retry trace
Treat this as duplicate-delivery risk. If the first request was already persisted or queued before the error response, a resend must reuse the same signal ID and produce no second trading effect. For Scenario D — Reconnect/retry trace on question 50, use that evidence specifically to answer “How should an automated trading audit log be designed?”; keep it separate from the evidence for the other scenarios on this page.
What to check
- intended signal/action
- last stage that definitely succeeded
- first stage that differs from intent
- final cTrader state after the event
Practical rule
For “How should an automated trading audit log be designed?”, change only the first layer whose evidence no longer matches the intended action. Preserve signal identity, timestamps and final cTrader state, and reproduce execution-affecting changes on demo before live use.
Decision summary
Direct answer: An audit log should reconstruct one signal from TradingView trigger to final broker result: signal ID, timestamps, normalized command, target account/symbol, validation, dispatch, cTrader result and duplicate/retry events—without secrets.
Next action: Match the observed evidence to one scenario above, test that mechanism independently on demo and keep the result traceable with one signal ID.
Primary sources
Need a TradingView → cTrader execution route?
NRUNO routes your TradingView instructions to cTrader. Your strategy and signal logic remain yours.