> ## Documentation Index
> Fetch the complete documentation index at: https://docs.alterscope.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Real-Time Detection

> How Alterscope's detection engine scans connector and on-chain data each cycle, scores findings, and routes them to the alerts inbox.

Risk grades and simulations tell you where a position stands; **detection** tells you the moment something changes. Alterscope runs a standing detection engine that re-reads its data sources on a fixed cycle, evaluates a library of rules against the latest state, and emits **findings** — scored, scoped observations that something looks wrong — into the same alerts inbox you already use.

The engine is deliberately boring: a short, repeated loop over real data, not a black box. This page describes what it actually does today.

## The detection cycle

Each cycle the engine pulls a fresh snapshot from its wired sources, builds a feature view of the market, and runs every registered rule against it:

1. **Read.** It fetches the latest state from each connected source — EVM lending markets (Aave v3, Compound v3, Euler v2, SparkLend, Morpho Blue), Stellar venues (Blend, SDEX, Aquarius, Sushi), and an Ethereum RPC for on-chain reads.
2. **Build features.** It aggregates that data into a feature snapshot: oracle staleness, failed-transaction rate, utilization, liquidity imbalance, and holder concentration. Each feature carries a **data-quality score** that rises with how many real sources backed it, so a thin snapshot is visibly thin rather than silently confident.
3. **Evaluate.** It runs protocol rule packs (lending, DEX, and governance) plus the core risk cycle, producing findings where a rule trips.

The cycle cadence is fixed (60 seconds by default). A finding is only as fresh as the last completed cycle, and the engine reports when that was — a wedged or frozen engine is detectable, not silently stale.

## What a finding carries

Every finding is a structured record, not a free-text alert. It names the **protocol** and **chain** it concerns, the **rule pack** that produced it, a **root cause**, and a **recommended action**, alongside three scores:

* **Severity** — how serious the condition is.
* **Confidence** — how strongly the data supports it.
* **Blast radius** — how much of the relevant exposure the condition touches.

Severity maps to the familiar alert bands — **info**, **warning**, **critical** — so a finding lands in your inbox at a priority you can triage at a glance.

## From finding to your inbox

Findings flow into the **alerts platform** — the same inbox that carries your rule-based alerts. The engine registers detection as a platform-owned alert source, so detector findings appear in `/alerts` next to everything else, filterable by source. There is nothing extra to wire up: if you can see alerts, you can see findings.

The engine also keeps a short rolling history of recent findings and persists it across restarts, so a pod restart does not blank your recent detection history.

## Governance events

Beyond the polling cycle, the engine accepts **governance events** — a parameter change, an admin action, a proposal — and evaluates them immediately against the governance rule pack. Duplicate events inside a 24-hour window are de-duplicated, so the same on-chain action does not produce a wall of repeated findings.

## Honest coverage

<Warning>
  Detection quality tracks **which sources are wired in your environment**. A detector only fires on data it can see:

  * Detectors that depend on the **knowledge-graph / topology export** (contagion- and concentration-aware rules) stay dark wherever no graph-intelligence export is connected — they light up as that data lands, not before.
  * Per-protocol and per-chain coverage follows connector coverage. A protocol with no connected source produces no findings for that protocol, by design — the engine runs **fail-open** on the sources it has rather than fabricating a signal.

  Treat detection as a capability whose breadth grows with source coverage, not as exhaustive surveillance of every protocol. See [Coverage & gaps](/trust/data/coverage-and-gaps) for what is connected where, and [Graph Intelligence](/trust/methodology/graph-intelligence) for the network analysis the topology-aware detectors build on.
</Warning>

## What this is not

Detection surfaces conditions; it does not move funds. Findings are observations routed to your inbox — acting on them is yours to decide. The engine reads and scores; it does not place transactions.