Cookbook: investigate a coin

One prompt that turns "tell me about this coin" into an investigation whose numbers are real.

Anyone can ask a chatbot to analyse a coin. What comes back reads well and rests on nothing: invented support levels, remembered statistics, no way to check any of it. The prompt below runs the same request through the record instead. Every number in the answer is computed by the engine, carries how many chances it had, and ends in a key you can re-run.

Setup takes one URL: connect your client first, then paste this, swapping in your instrument.

The prompt

Using the EdgeDepth Research tools, investigate SOLUSDT.

1. Ground first. Call list_instruments for solusdt and tell me its coverage
   window before anything else. If coverage is thin, say so plainly and scale
   every later claim to it.

2. Read the present. Call snapshot_at for the most recent complete minute.
   Report only the readings that stand out against their own history (use the
   percentiles), not raw values. If nothing stands out, say the market looks
   ordinary right now: that is a finding.

3. Measure before you narrate. For each standout reading, call base_rate to
   establish how often that state occurs at all. If it is common, say it is
   common. A reading that holds half the time explains nothing.

4. Turn readings into testable setups. Propose 2 or 3 setups built ONLY from
   readings you measured above. Show me each proposed document and wait for my
   confirmation before running it. After I confirm, run_scan each one and
   report what followed as distributions over every match, with the number of
   complete-horizon matches beside every rate. Never a single average. Never
   filtered by how it turned out.

5. Close honestly. List what you could not measure and why. Echo every
   reproducibility key so I can re-run each result. End with this sentence,
   unchanged: "These are counts of what happened in the scanned window, not
   predictions, and nothing here is trading advice."

What comes back

A coverage statement first, so you know how much record stands behind everything after it. Then the handful of readings that are actually unusual this minute, each with its percentile. Then base rates: how often each state occurs at all. Then the part most people skip and should not: for each setup you confirm, the full distribution of what followed every previous occurrence, over four horizons, with the match count beside every rate. Not "this usually pumps". A count, its chances, and its spread.

Why the numbers survive scrutiny

The steps above are good manners, but the guarantees are structural. The agent cannot invent a statistic: the grammar is closed, and every number is computed by the engine from the record. It cannot cherry-pick winners even if asked: filtering on outcomes is refused with OUTCOME_IN_PREDICATE. It cannot run anything you did not confirm: proposals are labeled and inert until re-submitted. And it cannot touch money: there are no exchange keys, no orders, nothing to connect. A sloppier prompt than this one still gets the same refusals.

Make it yours

Swap the symbol (exact lowercase Binance USDT-M form, btcusdt not BTC). Add a constraint you care about ("only consider readings from the last month"). Ask for the same investigation across three symbols and compare the base rates. The one part not to edit is step 5: an investigation that will not state its limits is an advertisement.

Every result echoes its reproducibility key. Paste a key into a conversation with anyone, on any account, and the same search returns the same answer. That is the difference between research and content.