URD ATLAS
Account
The exact values that decide when a metric is high, when confidence is good enough, and which regime label a chain receives. Published openly so every classification can be traced and understood.
Most regime-classification products do not publish their thresholds. Urd Atlas does, so every label can be reconstructed and checked.
These are the exact threshold values in the currently published methodology. Every regime label on every chain page was produced using these numbers.
Below this value, the regime label becomes UNKNOWN/DEGRADED regardless of axis structure. The most important single threshold on the site.
Either criterion fires the HIGH band. Extreme high: ≥ 95th percentile or z ≥ 2.5. Low mirrors these values on the negative side.
| Band | Percentile criterion | Z-score criterion | Logic | Role in regime |
|---|---|---|---|---|
| EXTREME_HIGH | ≥ 95th | ≥ +2.5 | OR | Triggers CONGESTED alone (capacity axis) |
| HIGH | ≥ 80th | ≥ +1.5 | OR | CONGESTED (capacity+friction), HEATING (demand) |
| NORMAL | 20th–80th | −1.5 to +1.5 | — | Default — no band condition fires |
| LOW | ≤ 20th |
v1Adjust the sliders to explore how different threshold values would change the classification rules. Everything here runs in your browser — nothing changes what the product actually publishes.
Interactive threshold inputs for custom-threshold workflows. These controls are descriptive UI only until explicitly wired into a custom-output flow.
Minimum descriptive confidence required before canonical interpretation should be treated as eligible.
Minimum persistence window used to distinguish short-lived noise from more durable state.
Percentile threshold for high-band classification.
Robust z-score threshold for high-band classification.
Percentile threshold for extreme-high classification.
Robust z-score threshold for extreme-high classification.
Percentile threshold for low-band classification.
Robust z-score threshold for low-band classification.
Percentile threshold for extreme-low classification.
Robust z-score threshold for extreme-low classification.
Governance note: these controls do not overwrite canonical published outputs and must remain clearly separated from the default public regime layer.
Human-readable summary of the current threshold configuration.
Client-side preview only: adjusting these controls does not overwrite canonical published methodology, public regime labels, or default API outputs. All changes are local to your browser session.
data/published/v1/dataset.jsonA threshold is simply a line that separates one category from another. On this site, thresholds are the rules that decide when a metric is "high", when it is "extreme", when confidence is "good enough", and when a chain should be labelled HEATING instead of STABLE.
Think of it like a weather service that calls it a heatwave when temperature exceeds 30°C for three consecutive days. The threshold (30°C, 3 days) is the agreed-upon rule. The weather itself is just data. Without the threshold, you have numbers. With the threshold, you have a classification.
Urd Atlas publishes its thresholds openly so you can understand exactly how any label was produced. If you see CONGESTED on Ethereum, you can come here and trace exactly which thresholds were crossed to produce that label.
The thresholds on this page are the canonical defaults — the values the model actually uses every day. You can also use the simulator below to explore what would happen if you moved them, but that simulation stays in your browser and never changes what the product publishes.
Thresholds in Urd Atlas are deterministic classification boundaries applied to the output of the scoring pipeline. They operate at two stages. First, metric-level thresholds classify each input signal into band categories (LOW, NORMAL, HIGH, EXTREME_HIGH, EXTREME_LOW) based on percentile rank and robust z-score. Second, regime-level rules combine these band classifications across axes (Demand, Friction, Capacity) to derive the terminal regime label.
The dual-criterion band system (percentile OR z-score) is deliberate: it ensures that a metric can be flagged as high via either a positional argument (rank in recent distribution) or a distance argument (standardised deviation from recent centre), whichever fires first. This makes the classification robust to distributional irregularities where one criterion may be uninformative.
The confidence threshold (0.40) is a pre-classification gate. It is evaluated before regime rules are applied, which means no amount of extreme axis scores will produce a named regime label when confidence is below the floor. This is an intentional epistemic guardrail: the model does not publish strong labels under weak evidence.
The confidence threshold is the most important single number on this page. It is set to 0.40.
If a chain's confidence score falls below 0.40, the model will not publish a named regime label for that day. Instead it publishes UNKNOWN/DEGRADED. The data may still be shown for transparency, but you should not treat the classification as meaningful.
There is also a middle zone between 0.40 and 0.70 called the Caution band. Labels in this range are published, but the scorecard scores are pulled toward neutral (50) to avoid over-interpreting weak evidence. You will see a warning on chain pages when confidence is in this range.
Above 0.70 is the Good band. The label is well-supported and the scorecard can be read normally.
The confidence gate (default 0.40) is a pre-classification hard floor. It is evaluated as: if confidence_score < confidence_threshold, then status.label = UNKNOWN/DEGRADED regardless of axis structure. This logic runs before regime band rules are evaluated.
The confidence score itself is the geometric mean of data_quality_score and label_confidence_score: √(dq × lc). The geometric mean ensures that weakness in either component suppresses the composite — a chain with perfect data quality but ambiguous label support will not clear the floor on data quality alone.
In the Caution band (0.40–0.69), scorecard scores are degraded toward 50 via the formula score = 50 + (score − 50) × effective_confidence. This means the visual scorecard always reflects the epistemic weight of the underlying evidence — a high demand score under 0.45 confidence will appear much closer to neutral than the same raw score under 0.85 confidence.
Band thresholds decide whether a metric is "high", "low", "extreme", or "normal" on any given day. The model uses two separate tests — percentile rank and z-score — and flags a metric as high if either one crosses the threshold.
Here is what the default thresholds mean in plain language:
Band thresholds implement a dual-criterion OR logic: band = HIGH if pct_90d ≥ high_pct OR z_robust ≥ high_z. This OR structure is intentional — it ensures that a metric can be classified as high via either a rank argument (positional in the empirical distribution) or a distance argument (standardised deviation from the robust centre).
The z_robust criterion uses MAD-based standardisation: z = 0.6745 × (x − median) / MAD. The 0.6745 scaling makes the statistic asymptotically equivalent to a standard z-score under Gaussian assumptions while inheriting outlier robustness from the MAD estimator.
Band outcomes feed directly into axis-level regime rule evaluation. CONGESTED requires Capacity = EXTREME_HIGH, or (Capacity = HIGH and Friction = HIGH). HEATING requires Demand = HIGH and at least one axis trend = HEATING. CHEAP requires both Friction = LOW and Capacity = LOW.
Once the model has classified each metric into a band (high, low, extreme, etc.), it applies a set of rules to decide which regime label to assign. These rules are evaluated in a fixed order, and the first one that matches wins.
The regime classification is a deterministic rule tree evaluated after band classification and confidence gating. The evaluation order is:
confidence_score < confidence_threshold → UNKNOWN/DEGRADED (pre-empts all subsequent rules)capacity = EXTREME_HIGH OR (capacity = HIGH AND friction = HIGH) → CONGESTEDfriction = LOW AND capacity = LOW → The simulator lets you adjust the threshold values and see immediately how the classification rules would change. All of this happens entirely in your browser — nothing you do here affects the published data or the official regime labels.
This is useful for two things. First, you can understand how sensitive the labels are to threshold choices. Move the confidence floor from 0.40 to 0.60 and see how many more days would have been classified as UNKNOWN/DEGRADED. Second, Research subscribers can use adjusted thresholds to generate custom JSON outputs that apply their own classification rules to the same underlying data.
The canonical defaults are always shown. A Reset button appears whenever you have moved away from them, so you can always return to the official values.
The simulator applies the same deterministic classification rules as the production pipeline to hypothetical threshold values. It does not re-fetch data — it operates on the threshold parameters only and produces a human-readable preview of how the boundary descriptions would change.
For Research subscribers, the custom threshold workflow extends beyond the browser preview: the API endpoint POST /api/v1/files/custom accepts a threshold configuration and returns identity-hashed JSON outputs generated by applying those thresholds to the canonical published data. Custom outputs are immutable per identity hash, stored per account, and explicitly marked as custom.
Thresholds are tools for understanding, not tools for trading. The classification that comes out of applying a threshold is a description of the network's current state — it says nothing about what will happen to prices, what you should buy, or when you should act.
A good way to think about it: if Ethereum is CONGESTED, that is a factual statement about its network condition right now. Whether that is good or bad for you depends entirely on what you are trying to do — something the model does not know and deliberately does not attempt to guess.
The threshold system is a classification mechanism over descriptive on-chain observables. It has no causal model of price formation, no return objective, and no optimisation target. Threshold values were not selected to maximise any performance metric — they were selected to produce stable, interpretable, methodology-consistent classifications.
This has a direct implication for custom threshold use: adjusting thresholds does not constitute a backtested strategy. A user who finds that a stricter confidence floor or different band boundaries produce a pattern that correlates with past returns has made an observation about a descriptive data series, not validated a trading system.
| ≤ −1.5 |
| OR |
| CHEAP (friction+capacity both low) |
| EXTREME_LOW | ≤ 5th | ≤ −2.5 | OR | Stronger low signal — feeds CHEAP |
regime_engine.py · market_scorecard.py · Methodology version v1All canonical threshold values are versioned under the current methodology version and are the single source of truth for the published outputs. The interactive simulator on this page is a presentation layer that re-applies the same rule logic to hypothetical threshold values — it does not touch canonical outputs.
confidence.confidence_score0.40 → UNKNOWN/DEGRADED0.40–0.69 → scores degraded toward 50≥ 0.70 → full scorecard expressionpct_90d ≥ 80 OR z_robust ≥ 1.5pct_90d ≥ 95 OR z_robust ≥ 2.5pct_90d ≤ 20 OR z_robust ≤ −1.5pct_90d ≤ 5 OR z_robust ≤ −2.5regime_engine.py · market_scorecard.pyCHEAPdemand = HIGH AND any axis trend is HEATING (momentum ≥ 0.15) → HEATINGSTABLEThe priority ordering ensures CONGESTED cannot be masked by CHEAP conditions, and HEATING requires both level elevation and directional acceleration. STABLE is the residual category — it does not have positive conditions, it is the absence of all other conditions.