> For the complete documentation index, see [llms.txt](https://www.degenbot.wiki/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.degenbot.wiki/performance-and-methodology/how-the-analysis-works.md).

# How the analysis works

A plain-language model of market data, signal generation, delivery, outcome tracking, and AI limits.

This page explains how to think about an automated alerts service. It is a **conceptual overview**, not a claim that every internal component of Degen has been inspected or certified.

### From data to a message

**Observe:** a service receives market information such as prices, candles, and volume from its configured sources.

**Analyse:** rules or models turn that information into measurements of conditions such as trend, momentum, or volatility.

**Select:** a method decides whether the conditions qualify for a particular alert. Version, thresholds, filters, and any cooldown can affect the selection.

**Deliver:** the selected observation is formatted and sent to a destination such as Telegram.

**Evaluate:** an outcome process checks what happened later under a defined rule and records the result for reporting.

These are separate steps. A functioning Telegram menu does not prove the data is fresh, the model is trained, or outcomes are being resolved correctly.

### Rules and machine learning

A traditional rule applies an explicit condition. A trained model learns a relationship from examples. A system can use either or combine them.

The presence of a machine-learning file or library is not evidence that a trained model is loaded or contributing to live alerts. That requires verification of the deployed model, its inputs, and its role in decisions.

This guide does not claim that a particular neural network, reinforcement-learning model, or self-learning feature is active. The owner must verify those claims against the release before publishing them.

### Confidence versus probability

A confidence label may be a ranking or score. **Calibration** asks whether predicted probabilities correspond to observed frequencies in suitable evaluation data. For example, a well-calibrated group of predictions near 80% would succeed around 80% of the time on the defined task—not guarantee the result of each prediction. See [scikit-learn's probability-calibration documentation](https://scikit-learn.org/stable/modules/calibration.html).

Do not read a score as a probability unless the product's methodology supports that interpretation.

### Automatic operation is not automatic improvement

Collecting data, sending alerts, and updating outcomes can be automated without allowing a strategy to rewrite itself. Candidate models can be evaluated separately from the method delivering member alerts.

Labels such as **off**, **shadow**, **test**, or **production** need a release-specific explanation. They do not alone establish whether learning changes live decisions, whether a system has passed validation, or whether money is being traded.

### What members should look for

Look for a clear version, a meaningful explanation, current data, understandable outcome rules, and candid service notices. An AI label does not replace any of these.

Unexpected behaviour should be investigated as a data, model, application, delivery, or reporting issue—not excused simply because a system is described as intelligent.