Limitations

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.

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

​

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.

​

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