> For the complete documentation index, see [llms.txt](https://docs.digitaldon.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.digitaldon.net/how-the-analysis-works/engine.md). # Overview This section explains what goes into a card and why, at the level you need to read one properly and know when to distrust it. It does **not** publish the recipe — the thresholds, weights and calibration behind the numbers are the product, and they stay in the product. ## The pipeline 1. **Resolve the token.** A ticker, a name or an address is matched to a real trading pair across every active chain. That pair supplies price, liquidity, market cap, FDV, the 24h buy/sell split, the pool's age and the project's social links. A ticker matching several chains gets you a picker, not a guess. 2. **Pull the chart.** Two timeframes — a short one and a long one — so the analysis can separate "what happened this week" from "what's been happening for months". Below a floor of usable history, analysis stops here and the card says so. 3. **Pick a profile.** Token age decides: **Fresh**, **Early** or **Established**. This changes what the rest of the run leans on. See [Token profiles](/how-the-analysis-works/profiles.md). 4. **Clean the launch off the chart.** For young tokens, the opening stretch of trading is excluded before anything is measured. Launch price action is a vertical line followed by a cliff, and leaving it in poisons every support level, every average and every "% below ATH" number downstream. If the token also set its all-time high in that window, the card flags it, so you don't read "−94% from ATH" as a discount. 5. **Compute the signals.** A set of independent readings spanning momentum, trend, chart structure, volume behaviour and transaction flow. Each one is normalised onto the same scale so they can be compared and combined. 6. **Weight them into a score.** Profile-specific weights, normalised to 0–100. The weighting is asymmetric — some signals are trusted more when they're warning than when they're blessing. [What the score means](/how-the-analysis-works/score.md). 7. **Derive the trade zones.** A short-term plan from recent swing structure and a long-term plan from the higher-timeframe structure, then a set of invariants that keeps the two coherent with each other. [Entry & exit zones](/how-the-analysis-works/zones.md). 8. **Read the chain data.** Liquidity ratio, FDV overhang, buy/sell pressure — computed independently of the chart, because a perfect setup on 0.4% liquidity isn't a setup. [On-chain sentiment](/how-the-analysis-works/onchain.md). 9. **Render.** Telegram gets a chart image plus a formatted message; the Web Analyzer renders panels from the same result. The formatting differs. The numbers cannot. ## Design principles worth knowing **One analysis, two surfaces.** Telegram and the browser don't run "similar" logic — they produce the same numbers for the same token, and that's verified automatically before any change to the analysis is allowed to ship. A tool whose entire output is a verdict cannot afford two verdicts. **Missing data is stated, never invented.** Every signal has a minimum amount of history it needs to mean anything. If it isn't there, the signal is dropped from the score rather than defaulted to neutral-and-counted. The card says "limited data" instead of quietly producing confident numbers from a handful of candles. **A number you can't act on is worse than no number.** This shows up in several places: the short-term plan is suppressed entirely when there isn't a tradable one, the chart refuses to call a three-week high an all-time high, and "no short-term trade here" exists as an explicit message rather than an empty panel that reads as a broken bot. **Degrade, don't fail.** If an optional data source is unavailable or at its ceiling, the affected part of the card comes back partial or absent. It doesn't take the rest of the analysis down with it. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.digitaldon.net/how-the-analysis-works/engine.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.