AI Trading Bot Logs: Why Did It Place That Order?

DN AI Trading Beginner Series · Reviewed 8 November 2026

Imagine opening your bot dashboard and finding an order you did not expect. The chart now shows a signal. The bot has a success message. An AI assistant offers an explanation involving momentum, a threshold and a risk check. Which of those items tells you what was recorded before this particular request was submitted?

The answer depends on the evidence. The current chart might describe a different configuration. The success message might describe delivery to an intermediary. The explanation might have been generated after you asked the question. Each item can be useful, but they answer different questions.

This guide gives you eight checks for reconstructing the recorded basis of one decision. It builds on DN’s live-results and net-P&L audit, which examines trade accounting, and the signal-data guide, which examines timing, finality and delivery stages. Here the task is to connect contemporaneous evidence to a specific request without filling the missing pieces with a story.

Five records, four links

Use a small case first. You do not need to describe every bot, service and historical trade in one worksheet. The DN map separates these records:

This is DN’s inspection framework, not a claim that every platform exposes these five objects. If your platform provides only some of them, record that limitation. An honest partial record is more useful than a complete-looking reconstruction with invented links.

OpenTelemetry distinguishes structured records with consistent field names, types and meanings from records that merely happen to be encoded as JSON. That distinction is useful here: a field called “ID” needs a defined meaning before you compare it with another field called “ID.” [1]

1. Define the exact case you are investigating

Start by naming the venue, account alias, product or instrument, and environment. Keep the case narrow enough that two records can reasonably be compared. “My trading bot” is not a sufficiently precise context if you run several instances, connect more than one account or keep both test and live environments.

Use harmless aliases such as ACCOUNT-A in the shared worksheet. Retain the private mapping to the actual account in your own controlled records. The purpose of the alias is to preserve a distinction without exposing an account identifier.

Then specify the question. You might be investigating which settings the decision referenced, whether a request points to that decision, or whether a supplied reply belongs to that request. Those are narrower questions than “Did the bot work correctly?” They can produce useful answers even when the broader question remains unresolved.

Keep the identifier’s scope with the case. Binance’s Spot glossary defines orderId as identifying an order on a symbol. A bare order number copied without the product context therefore discards part of the documented meaning. [2]

Do not change context labels just to make records line up. If one record belongs to a test environment and another belongs to a live account, preserve that difference. A matching-looking reference does not erase a context conflict.

2. Find the signal evidence the decision actually referenced

Locate the input or signal snapshot associated with the decision. A snapshot can be a saved alert record, a bounded input record or another retained artifact. Give it a safe local alias, and keep a reference to where the original can be inspected. The worksheet needs the relationship, not a paste of the entire payload.

Record what the evidence contains and what it leaves out. An alert message may identify an action and instrument without retaining every input used to calculate the condition. A screenshot may show a chart without showing which saved alert generated the message. Treat those as different kinds of evidence.

If you reproduce the calculation now, label the reproduction as a later analysis. It may help test an explanation, but it is not automatically the input record used by the earlier decision. Preserve the original reference separately.

Timestamp labels also need their meanings. OpenTelemetry’s data model separates the time an event occurred, measured by its source clock, from the time a collection system observed it. Trace and span identifiers are optional processing references; they should not be relabeled as exchange order IDs. [3]

This map does not compare clocks or calculate latency. If your question is whether a signal was stale, incomplete or based on an unfinished candle, use the signal-data checks. Here, preserve the reference to the actual evidence instead of substituting a newer observation.

3. Match the settings snapshot, not today’s settings

Find the configuration record referenced by the decision. Give the record its own alias and retain a version label if one exists. An alias such as SET-7 identifies the saved settings evidence; a version label such as CFG-7 describes that evidence. Neither label proves that the bot used it.

The decisive link is the decision’s settings reference. If the decision points to SET-8 while the supplied settings card is SET-7, do not silently replace one value. The immediate finding is that the supplied records do not establish the proposed settings link.

TradingView provides a concrete reason to preserve the saved context. Its running alerts use the script, inputs, symbol and timeframe saved when the alert was created. Later changes to the chart or inputs do not update that existing alert context. [4]

For your own case, a configuration reference can point to a small, redacted record of the relevant settings. Include the part needed to examine the decision: for example, the configured rule version, the permitted action or the limit that the decision claims to have checked. Avoid exporting unrelated account details.

A current dashboard screenshot is useful evidence of what you can see now. It should retain that description. If the historical settings are unavailable, leave the historical link unresolved rather than relabeling the current screenshot as an earlier configuration.

4. Separate the recorded reason from a later explanation

The decision record should answer two distinct questions: what action was recorded, and where is the evidence for the reason recorded at that time? In the DN map, the action can be submit a new order, do not submit or unknown. The reason has its own reference and timing classification: contemporaneous, later note or unknown.

“Contemporaneous” describes the relationship of the record to the decision process. It is not a judgment that the reason was correct, complete or honest. A rule identifier and input references may explain the stated basis more precisely than a paragraph saying the market looked favorable.

For example, a retained decision summary might say that a named entry condition passed under a particular configuration, then identify the applicable input and settings records. You can investigate that recorded claim. A later message saying “the bot probably saw momentum” is a hypothesis unless the earlier evidence supports it.

If an AI assistant helps organize the records, ask it to separate copied facts, missing fields and later interpretations. Its new explanation does not become the original decision record simply because it sounds coherent. Keep a later note attached as a later note.

Preserve an explicit do-not-submit action too. If that decision is linked to a recorded new-order request, the map should show the inconsistency. It should not change the action to submit merely because a request record exists. A cancellation or amendment is a different request kind, so the same comparison must not automatically treat every request as a new order.

If no decision reason was retained, state that directly. You may still establish other reported links. The missing reason remains a missing reason.

5. Link the submitted request with the right kind of identifier

Keep the request record separate from the decision. The request is the instruction recorded as submitted; the decision is the record of the stated basis and intended action. Give each its own alias, preserve the request’s decision reference, and identify whether the instruction was a new order, cancellation, amendment or an unknown kind.

Identifier names are not interchangeable. Kraken Spot WebSocket v2 distinguishes an echoed request identifier, req_id, from its exchange-generated order_id. Its cl_ord_id identifies an open order per client, while order_userref is explicitly non-unique and can group orders. [5]

A grouping tag can help you find candidates. It cannot, by itself, select one request from several candidates. Likewise, a request identifier does not become an exchange order identifier because the two values happen to look similar. Retain the identifier type and context.

Provider behavior also differs. Coinbase Advanced Trade documents a particular duplicate client_order_id rule: it returns the corresponding existing order rather than creating another one. That is an endpoint-specific rule, not a universal meaning of “client ID” or a general instruction to retry. [6]

The DN tool compares the exact aliases you declare within typed links. It does not discover the correct IDs from a raw log, test a provider’s uniqueness rules or decide whether a new request should be sent. If the evidence supports several candidates, record that ambiguity.

6. Read the reply at the layer it describes

Keep a reply’s reference link separate from its meaning. A reply can belong to the request you are examining while providing only limited information about what happened afterwards. Conversely, a detailed-looking reply may be unrelated to the request in your case.

TradingView’s webhook documentation describes sending an alert message by HTTP POST and checking delivery in the alert log’s Webhook status column. That status concerns delivery to the selected URL. It is not an exchange fill record. [7]

Similarly, Binance Spot’s documented ACK response contains identifying fields and a transaction time; it does not contain fill quantities or order status. An acknowledgement therefore cannot answer every execution question. [2]

The map lets you distinguish a transport receipt, an order acknowledgement, a reported acceptance, a reported rejection, a reported fill and an unknown reply kind. These are reader classifications of supplied evidence. Selecting “reported fill” does not verify an exchange account or calculate how much remains unfilled.

Binance’s Spot execution report separates client, order, trade and execution identifiers, as well as execution type and order status. Those labels describe different parts of the record. [8]

TradingView strategy order-fill alerts originate from its broker emulator; they are not themselves external exchange fill records. [4]

If the reply is missing, retain the signal, settings and decision findings already available. Do not convert the missing reply into either a successful trade or a confirmed failure. Questions about an unresolved submission belong in DN’s order-timeout guide, not in a guessed answer from this map.

7. Preserve gaps, ambiguous links and conflicts separately

A record can be available without establishing the link you need. You may have two candidate requests with the same group label. You may have a settings record whose reference differs from the one named by the decision. You may have a reply from another environment. Those findings deserve their own descriptions.

Do not treat “no matching record supplied” as “the event did not happen.” The records you can see may have limited coverage. Kraken’s executions channel, for example, has separate controls for open-order and trade-history snapshots. A selected snapshot is not automatically a complete account history. [9]

Coinbase Advanced Trade’s List Fills endpoint also has filters and pagination, and distinguishes fill, trade, order and product identifiers. A selected row or page therefore needs its retrieval context if you use it as evidence. [10]

For the map, record the specific limitation: missing record, unknown reference, grouping-only reference, multiple candidates, different context or mismatched value. A reported match requires the exact reference and the reader’s declaration that the evidence is unique within the same case context.

An explicit conflict is useful information. It can tell the person reviewing the system where to look next. It does not establish that someone falsified a log, that the bot ignored a rule, or which record is authoritative. Preserve both records and the conflict rather than choosing the one that produces the tidiest explanation.

Keep the review bounded. The map is about the supplied evidence for one case; it does not certify the completeness of the wider logging system.

8. Share a small, redacted record and a precise question

Before handing the case to a developer, support team or another reviewer, separate the evidence references from credentials. A useful handoff identifies the case, the relevant records, the link that does not resolve and what additional evidence would address that gap.

OWASP’s logging guidance includes application and interaction context, actions, results and reasons. It also identifies access tokens, passwords and primary secrets as data that normally should not be recorded directly in logs. Preserve useful context without copying credentials into the shared worksheet. [11]

Use consistent harmless aliases for local records and keep original evidence under your own access controls. Do not paste API keys, bearer tokens, webhook secrets, complete signed URLs or raw private logs into this tool. It is a structured worksheet, not a secret detector or redaction service.

A focused support question might be: “Decision DEC-A references SET-8, but the available configuration export is SET-7. Which retained configuration record corresponds to SET-8?” That question asks for evidence without asserting that the bot must have used the wrong settings.

Current 3Commas Signal Bot documentation points users to the bot’s Logs for alert processing and errors, and separately to Positions for the resulting position. Those are useful places to inspect; the documentation does not promise that every internal decision reason is exposed. [12]

If a platform cannot supply the missing reason or configuration record, preserve that limitation in the final explanation. The gap is part of what you learned.

Worked example: the references agree, but what does that establish?

The examples are fictional. Their namespace is VENUE-A / ACCOUNT-A / SPOT:BASE/QUOTE / TEST-A. These are teaching labels, not a venue, account or trading recommendation.

In the first case, the signal is SIG-A, the settings record is SET-7 with version label CFG-7, and the decision is DEC-A. The decision names both earlier references and points to REASON-A as contemporaneous reason evidence. It records an intention to submit.

The submitted-request record is REQ-A, with details referenced by REQUEST-DETAILS-A. It points to DEC-A. The reply record, RPL-A, points to REQ-A and is classified only as an order acknowledgement. With the required uniqueness and context declarations, the four links can report matches. That describes the supplied reference chain, not proof of a fill or of the strategy’s correctness.

Change one part at a time. If the decision names SET-8 while the available settings record remains SET-7, that link conflicts. If the reply is unavailable, the earlier reported links remain visible. If the reason is a later note, the references can still agree while the contemporaneous reason remains unestablished.

The six included cases cover those distinctions, grouping and multiple candidates, and an explicit do-not-submit decision linked to a recorded new-order request. The last case also leaves the reason and reply unavailable, so a clear conflict remains visible alongside missing evidence.

Methodology and limits

DN designed the map as a deterministic comparison of reader-entered records. It compares four typed reference relationships under declared context and uniqueness conditions, while reporting decision-reason timing and an explicit action/request inconsistency separately. It does not infer a missing edge from the other three.

The six example cases are synthetic teaching records. They are not measured provider behavior, authenticated logs, executed trades or evidence of investment performance. The dataset documents their inputs and expected findings so the examples can be inspected.

The tool does not read the evidence files behind your aliases. It cannot establish that the saved settings were deployed, that a recorded reason faithfully describes a model’s internal process, or that a reply proves the present account state. No score summarizes those unknowns into a verdict.

Use the output to state the support precisely: which reported links agree, which records conflict, which reason evidence was contemporaneous and which questions remain open. That is a more reviewable explanation than replacing missing evidence with confidence.

Frequently asked questions

Primary sources

Official documentation reviewed on 8 November 2026 (SAST). Product, route, identifier and record meaning matter. These are documentation findings, not live execution verification.

1. Logs — OpenTelemetry
2. SPOT API Glossary — Binance
3. Logs Data Model — OpenTelemetry
4. Alerts — TradingView Pine Script v6
5. Add Order — Kraken Spot WebSocket v2
6. Create Order — Coinbase Advanced Trade
7. How to configure webhook alerts — TradingView
8. Spot WebSocket Stream Schemas — Binance
9. Executions — Kraken Spot WebSocket v2
10. List Fills — Coinbase Advanced Trade
11. Logging Cheat Sheet — OWASP
12. Signal Bot: Comprehensive JSON Guide — 3Commas