Evaluation guide

How to evaluate DeepChamp

Do not take our word for it. This page shows how to measure the intelligence on your own data, with your own price feed, before you spend more than a few cents. We publish no results, no record and no return figures, so this is how you build your own.

The principle

DeepChamp returns research intelligence: a probability estimate, a score, a confidence tier, the factors behind them and written context. It is not a prediction of an outcome and not a recommendation to bet. A fair evaluation asks a narrower question: is our probability, issued at a known time, better information than the price you already have?

Everything below follows from that. You need three things: a log of what we said and when, your own price at the time that matters, and enough signals to tell skill from noise.

Log every signal

Store each signal exactly as received, with these fields, the moment you receive it. Do not overwrite or backfill.

Fields that make a signal auditable
FieldWhy you keep it
signal_idThe stable identity of the signal. The same content always has the same id.
content_hashA hash of the immutable fields. It proves the copy you hold is the copy we issued.
model_versionWhich model produced it. Compare versions separately; never pool across a change.
issued_atWhen we first issued exactly this content. Your timing analysis starts here, not at the time you fetched it.
edge_scoreOur score from 0 to 100, for ranking and thresholds.
model_probabilityOur fair-value estimate for that side. An estimate, not a prediction of the outcome. Your calibration check uses it.
confidence_tierHigh, medium or low. Evaluate each tier on its own.
side, line, market_type, game_idWhat the signal is about, so you can match it to your own price and your own result.
market_close_referenceA reference timestamp for the scheduled start. A time, never a price. Read your own closing price at that instant.
meta.request_id, meta.as_ofWhich response it came from and when it was produced.

A minimal log row, in any store you like. The received_at time is yours; issued_at is ours. The gap between them tells you how fresh a signal was when you saw it.

log row (field names, not values)
received_at        (your clock, UTC)
request_id         meta.request_id
signal_id          data.items[].signal_id
content_hash       data.items[].content_hash
model_version      data.items[].model_version
issued_at          data.items[].issued_at
sport, game_id, market_type, side, line
edge_score, model_probability, confidence_tier
close_reference    data.items[].market_close_reference.reference_time
your_close_price   (from your own licensed feed, filled in later)
your_outcome       (from your own source of truth, filled in later)

Compare with the close, using your own price

Each signal has a market_close_reference: a timestamp for the scheduled start, never a price. We do not host or return odds, so the comparison uses a price you already license.

  1. Read your own closing price for the same side and line at the reference time, from your own licensed feed.
  2. Remove the margin from your closing price to get a no-vig probability. Evaluate_market does this when you send both sides.
  3. Compare our probability, as issued, with that no-vig closing probability. The gap, averaged over many signals, is your closing-price comparison. Keep each model version and confidence tier separate.
  4. Compare against the price you could actually have used at the time you received the signal as well, so you can see what delay costs.

If you bring a price to evaluate_market, we do the arithmetic for you: de-vigged fair value, edge against our probability, expected value per unit and Kelly sizing. Your price is used only in that request and is not stored.

Check calibration against outcomes you track

We do not record outcomes in the signal ledger, so calibration is yours to measure. Track results from your own source of truth, then:

  1. Bucket signals by model_probability (for example in steps of five points) and compute, for each bucket, the share of outcomes that happened.
  2. Compare each bucket with its stated probability. A well-calibrated source lands near the diagonal; report the interval, not a point.
  3. Use a proper scoring rule such as the Brier score to compare us with your own model or with the market probability on the same set of signals.
  4. Pre-register the sample size and the comparison before you look. A few dozen signals cannot separate skill from noise.

What to expect

  • Research context first. Probabilities, factors and written reasons that save your agent work, with every number traceable to a signal.
  • Differences from the market that are usually small. Most signals will sit close to your price; the value is in how you use the context and the cases that differ.
  • Variation by sport, market and tier. Evaluate them separately and expect some to be useful and some not.
  • Change over time. Models are versioned; a new version starts a new sample.

What we do not claim

  • We do not publish or claim results, a record or returns for any signal, tier, sport or period.
  • We do not claim that an edge score, a probability or a tier predicts an outcome, and we do not describe any signal as certain.
  • We do not provide odds, prices or line histories, and we do not return a closing price. The reference time is all we give.
  • We do not promise any result. Sports outcomes are uncertain and AI-generated analysis can be wrong.
  • We do not place or recommend automated wagers. A person makes every betting decision.

Research and information, not betting advice. No outcomes are guaranteed. Adults 21+ only, where legal.

Start free

The free daily slate shows the envelope, the compliance object and the metadata you will log, with no signup: 20 requests a minute and 300 a day per IP address. A sandbox for the paid lines opens with them. Tell us what you want to measure on the waitlist and we will prioritise it.

curl
curl 'https://deepchampai.com/api/agent/v1/slate/today?sport=nba'

Documentation · Back to DeepChamp for Agents