> ## 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.

# Limitations

> What Alterscope does not claim, the known boundaries of each model, and where coverage is still rolling out.

A risk vendor that won't state its limitations isn't being rigorous — it's being sold. This page is the honest counterpart to the rest of the methodology section: what our numbers are *not*, where each model's assumptions bite, and where coverage is still expanding. Read it alongside the model pages, not instead of them.

## What our numbers are not

* **Not guarantees.** Every score, VaR, and probability is a **model estimate**, not a prediction of loss and not a promise about the future.
* **Not investment advice.** Alterscope provides risk data and analytics. Allocation, hedging, and trading decisions are yours.
* **Not a substitute for your own diligence.** Our outputs are an input to a decision, designed to be auditable and combined with your own judgment.

## Model assumptions and their limits

### VaR & Monte Carlo

* The simulation draws **normally-distributed factor shocks**. It does **not** model fat tails, jumps, or regime breaks, so real tail events can exceed the simulated VaR/ES. See [VaR & Monte Carlo](/trust/methodology/var-and-monte-carlo).
* VaR/ES are reported at fixed 95% and 99% confidence over the requested horizon — they describe the modeled distribution, not a worst case.

### Risk factors

* The factor explainability uses **exact Shapley values over Alterscope's transparent scoring function** — it explains how factors move the composite, and is not a feature-importance from a hidden black-box model.
* Factor weights are **calibrated internally** and re-balanced by hierarchical risk parity. We publish the structure and methods; we do not publish the weight values.

### Oracle classification

* The oracle risk score is a **rule-based expert scorecard**, not a statistically calibrated probability. Read the band as a structured indicator.
* Classification currently covers **Morpho-style Chainlink oracle adapters**. Other oracle architectures are surfaced as `unverifiable` rather than guessed, and coverage is expanding. See [Oracle classification](/trust/methodology/oracle-classification).

### Pool risk scores

* These are **Alterscope's own implementations of published peer methodologies** (RiskDAO-style, Gauntlet-style, Block Analitica-style). They are independent reconstructions from public research — **not the firms' official outputs, and not API resale.**
* Scores are surfaced independently in their native units with **no blending**. Comparing them requires understanding what each measures. See [Pool risk scores](/trust/methodology/pool-risk-scores).

### Graph intelligence

* **Cross-chain contagion dampening is an uncalibrated prior** — the calibration corpus is Ethereum-only. Same-chain dampening is empirically fitted.
* Graph metrics and communities are **batch-computed** and can lag live state by up to their refresh interval; every response reports its last-computed time.
* **Smart-money and wallet-level concentration depend on wallet-ingestion coverage**, which varies and is still expanding. Treat them as a capability scaled by coverage, not a complete census of participants.

## Coverage is rolling out

Methodology availability varies by market, chain, and pool. A model existing does not mean it covers every asset you care about yet. Which markets and pools currently carry which signals is documented under [Coverage & gaps](/trust/data/coverage-and-gaps), and the freshness/quality metadata on every response tells you, per call, whether the data behind a specific number is current and complete.

## When to trust a number

Every Alterscope response carries a [freshness and quality verdict](/trust/data/freshness-and-quality). The short version:

* A `pass` verdict on `fresh`/`realtime` data is safe to rely on within the model's stated assumptions above.
* A `warn` verdict, or `approaching_stale` data, is usable but worth a second look for high-stakes decisions.
* A `fail` verdict, or `stale`/`unknown` data, should not be relied on unsupervised.

If a number can't be trusted, the platform says so in the response rather than hiding it — that, more than any single score, is the methodology.

## What we publish, and what we don't

We publish the methods, the formulas, the inputs, and the validation approach so our numbers can be judged and sanity-checked. We withhold the proprietary calibration — exact weights, tuned parameters, and training specifics — that would let the model be reconstructed wholesale. Where a parameter is sensitive, the model page publishes the formula and marks that parameter *calibrated internally*. Enough to be credible and verifiable; never a build recipe.