> ## Documentation Index > Fetch the complete documentation index at: https://docs.aiaxoniq.com/llms.txt > Use this file to discover all available pages before exploring further. # AI features > Anomaly detection, forecasting, natural-language query, incident analysis and the knowledge base — what each does, and what to check before trusting it. aiAxonIQ runs a set of AI features over your telemetry. They are assistive: each produces a starting point that is faster than doing it by hand, and each can be wrong in a way you should be able to recognise. **Your telemetry stays inside your organization.** These features run in a service reachable only by the aiAxonIQ API, on your behalf, scoped to your organization — the same isolation as every other query. See [Platform architecture](/concepts/architecture#the-ai-service). ## What is available Statistical outliers in a metric over a recent window, by Z-score and interquartile range. Fast, explainable, no training. Where a series is heading, with seasonality. Capacity planning and error-budget projection. A question in English becomes a query over your telemetry. Give it a log excerpt from an incident; get a summary and likely causes. Index your own runbooks and postmortems, then get answers grounded in them. Proposed alert rules and SLOs derived from how your services actually behave. ## Anomaly detection Z-score and interquartile-range outlier detection over a recent window. **Statistical, not learned.** There is no model to train and no warm-up period, and a flagged point can always be traced back to how far it sat from the recent distribution. That is a real advantage over an opaque score: you can tell whether to believe it. **An anomaly is a deviation, not a problem.** A deploy, a marketing campaign or a planned batch job is anomalous and entirely fine. Treat output as "something changed here", not as an incident. Also note that **anomaly alert rules are fired by the AI service, not by the main alerting loop.** Creating one as an ordinary rule and expecting the evaluator to run it will not work — nothing evaluates it and it silently never fires. See [Alerting](/guides/alerts/overview). ## Forecasting Projects a metric forward, accounting for seasonality — daily and weekly cycles rather than a straight line through the average. Use it for capacity questions ("when do we run out of disk") and for error budgets ("do we exhaust before the window ends"). **Forecasting is rate limited**, because fitting a model is seconds of compute rather than milliseconds. If you are driving it from a script, expect to be throttled and space the calls out. **A forecast assumes the future resembles the past.** It cannot know about the launch next week or the customer who churned yesterday. It is a projection of the current trend, and it is at its least reliable exactly when something has just changed. ## Natural-language query Ask a question in English; get a query over your telemetry and its result. The generated query is constrained before it runs and executes under a per-organization identity, so a generated query cannot read another organization's data regardless of what it asks for. **Read the query it generated before trusting the number.** The failure mode is not a refusal — it is a plausible query that answers a slightly different question than the one you asked, and returns a confident number for it. Natural-language query is at its best for exploration and for learning the data model. For anything that goes in a report, check the query. ## Incident analysis Supply a log excerpt from an incident and get a summary and likely causes. Runs are saved, so an analysis can be reopened later — useful when writing the postmortem a week afterwards. **The log excerpt is the input.** A request without one is refused rather than answered generically: an analysis with nothing to analyse would be fluent and worthless. ## Knowledge base Index your own documents — runbooks, postmortems, architecture notes — and ask questions answered from them rather than from general knowledge. This is what makes answers specific to *your* system. "How do we roll back the payments service" has a real answer only if the runbook that describes it has been indexed. **Indexing writes to a corpus shared across your whole organization**, so it requires the **Editor** role. Anyone in the organization can then search it. Do not index a document you would not show to every member. ## Suggestions Alert rules and SLOs proposed from observed behaviour, which you accept or dismiss. A suggestion derived from what a service actually does is a far better starting point than a threshold picked because it was a round number. Accepting one creates an ordinary rule or objective — there is nothing special about it afterwards. ## Feedback Most surfaces accept a thumbs up or down. It is recorded against your organization and is how these features improve. It is worth the two seconds: the alternative is that nobody finds out a suggestion was wrong. ## Next Monitoring *your* AI workloads — a different thing to this page. Where suggestions land, and how rules actually evaluate. Error budgets and forecasting them.