Double-check the report

Beginner 3 min

The agent answers with confidence even if it made a mistake along the way or quietly decided something for you.

So any number it gives deserves a second question: where the data came from, what it decided on its own, and whether the result holds if you compute it another way. In this example the agent admitted to a decision nobody asked for.

Send this in the same chat right after the report:

Prompt
Double-check your answer. What data did you actually use and from which source? What did you filter out or decide on your own, without my asking? Recompute the result another way and tell me whether it matches. What can't this check tell me?

What happens

The agent writes out what data it took, what it decided on its own, and computes the result another way. Here it double-checked the report from the Level statistics page. The recount matched, but the agent admitted to a decision nobody asked for: it chose weekdays only as the main variant on its own. With all calendar days, the result is 19 of 62, or 30.6%. Along the way it corrected its earlier "nothing is missing": the first calculation did not check the exact time grid.

Chat with the AI agent
You

Double-check your answer. What data did you actually use and from which source? What did you filter out or decide on your own, without my asking? Recompute the result another way and tell me whether it matches. What can't this check tell me?

AI agent

The recount matched: 18/44 = 40.9% for Mon-Fri and 19/62 = 30.6% for all calendar days. But in my first answer I chose Mon-Fri as the main variant myself; you didn't ask for that.

What data I actually used:

  • Your open BTCUSDT@BinanceFutures, 5m in ATAS. The source reported by the platform: Binance Only Market Data, type Binance, no delay.
  • In the first calculation, C# through scripts_preview processed 18,109 loaded candles, from Sep 4, 2026 00:00 to Nov 5, 2026 21:00 UTC. The calculation used the candles within the given hours and their volume by price level.
  • I computed the POC myself from ATAS footprint data, summing the volume of each level over the session. I did not read a ready-made session POC from an indicator. In the checked export, levels come in steps of 10 USDT; the result applies to this level of detail, not to the exchange's raw trades.

What I decided on my own:

  • I added the Mon-Fri variant, excluding weekends and comparing Monday with Friday. I kept weekday holidays. This is not the trading calendar of a US exchange.
  • I defined a "return" as any touch: Low ≤ POC ≤ High in the 9:30-11:25 candles, that is, in the window [9:30, 11:30).
  • I included an open right at the POC, without requiring price to move away from it first. There was one such case, Oct 28, in both variants.
  • If two prices had equal maximum volume, I took the lower one. The check showed there were no ties.
  • I used the first session only as a base: without a previous session it can't be checked.

How I double-checked it another way: I separately exported 4,914 candles through chart_get_bars, 63 full sessions of 78 candles, together with volume by price level. In JavaScript I rebuilt the profiles, adding up volumes in whole thousandths, and checked whether the POC fell within the combined range of the first 24 candles.

Every POC and the result of every checked session matched the first calculation. I also checked:

  • the exact time sequence of the candles in America/New_York;
  • that no footprint is empty;
  • that the sum of volume by price equals the volume of each candle;
  • that there is positive volume right at the POC level on a touch: this gave the same 19 and 18 cases.

My earlier wording "nothing is missing" was too broad: the first code checked the number of candles and that levels were not empty, but not the exact time grid. The grid is now checked too.

This check confirms that the calculation is reproducible on ATAS data, but it does not confirm that the raw Binance tape is complete: both methods use the same source. It also does not determine the exact moment of a touch within 5 minutes, order execution, the profitability of a strategy or the probability of a return in the future. A "return after price has first moved away from the POC" would need a different event definition.

Recheck results. I didn't change your charts.

Note the end of the answer: the check confirms the arithmetic on one and the same source, and says nothing about the source itself. If you doubt the data, compare a couple of values with the chart or with another source.

What you need

  • A crypto exchange connection
  • An agent that can run code

This is a historical test. Past results do not guarantee future results, and the trading decision is yours.