Urd Atlas Methodology

Public Methodology Reference

Canonical public explanation of what each Urd Atlas artifact layer means, how confidence and regime should be interpreted, and where the public methodology intentionally stops.

Purpose of this reference

This page defines the public meaning of the published artifacts. It is meant to let a careful technical customer understand the outputs without turning the public trust layer into a blueprint for reconstructing upstream raw data or cloning the internal pipeline.

Global interpretation rules

All dates are UTC calendar dates.
All analytical interpretation is chain-relative, not cross-chain absolute.
No price conversion is applied inside these artifacts.
Unsupported or unreliable fields are published as null.
If field meaning changes materially, the methodology version must change and the changelog must state whether historical rows were regenerated.

Artifact model

Layer	Definition	Interpretation
Gold	Daily observation layer for a chain and UTC date.	Direct daily chain aggregates or robust daily summaries. No regime interpretation.
Derived	Deterministic trend layer built from Gold.	Rolling transforms used for charting and trend context.
Meta	Analytical layer.	Publishes regime, confidence, scorecard, drivers, freshness context, and presentation helpers.
Briefs	Readable JSON summary layer.	Publishes short descriptive summaries of latest Meta context for fast reading, reporting, and non-pipeline workflows.

Gold methodology

Gold publishes direct daily chain observations or robust daily summaries. Gold does not apply regime logic, confidence degradation, or categorical interpretation.

Field family	Public meaning	Verification class
Daily counts	Daily transaction volume and block production activity.	B
Native value and fee fields	Native-denominated transfer throughput and typical same-day transaction magnitude / fee burden.	B
Execution-quality or capacity fields	Daily failure burden or capacity usage where those semantics are meaningful.	B
Breadth and cadence fields	Participation breadth and typical inter-block interval behavior.	B

Derived methodology

Derived fields are deterministic transforms of Gold. The core public pattern is the rolling average family: <metric>__ma7 and <metric>__ma30.

__ma7 is the 7-day simple moving average. __ma30 is the 30-day simple moving average. At the beginning of the archive these use the available observations rather than forcing nulls solely due to insufficient lookback.

Confidence v2 methodology

Confidence answers a narrow evidence-quality question: how well-supported is the current published analytical state by the relevant data and by the evidence for the specific label? It is not a probability of future price movement and not a trading signal.

The public composite remains the geometric mean:

confidence_score = sqrt(data_quality_score × label_confidence_score)

The current public confidence gate remains 0.40. Below that threshold, the product publishes UNKNOWN/DEGRADED rather than presenting a normal-confidence regime label.

Component	What it measures	Confidence v2 behavior
`data_quality_score`	Whether the relevant chain-specific evidence surface is complete, recent, dense, and historically deep enough.	Structurally non-applicable fields are excluded from the denominator. Optional fields are listed but do not reduce confidence when they are not part of the current regime evidence surface.
`label_confidence_score`	Whether the evidence clearly supports the specific label that was assigned.	Label-specific logic is used: HEATING emphasizes demand and trend; CONGESTED emphasizes friction/capacity pressure; CHEAP emphasizes low-friction evidence and lack of tight capacity; STABLE emphasizes genuine neutrality and absence of strong drivers.
`confidence.candidate_label`	The label the evidence supported before the confidence gate was applied.	When confidence is below threshold, the candidate can be retained for auditability while the public label is withheld as UNKNOWN/DEGRADED.

Why profile-aware data quality matters

Bitcoin, Ethereum, Base, and Arbitrum do not expose the same meaningful evidence surface. For example, EVM-only execution fields are not part of the Bitcoin confidence denominator. A missing field should reduce confidence only when that field is required for the chain profile and current methodology.

Scorecard methodology

The scorecard compresses current chain conditions into three axes: demand, friction, and capacity. Scores are chain-relative and bounded to a 0–100 display scale with 50 as the neutral point.

Score construction uses robust normalization against each chain’s own historical baseline. The currently implemented score family applies 7-day smoothing before historical comparison, excludes the most recent 14 days from the baseline, and maps robust z-scores into a bounded display score via 50 + 40 × tanh(z / 1.5).

The displayed score is confidence-degraded using 50 + (raw - 50) × effective_confidence.

Important distinction: raw scorecard evidence vs display score

Confidence v2 uses raw scorecard/regime evidence to evaluate label confidence. The public score displayed on pages is intentionally pulled toward 50 when confidence is lower. This avoids using an already confidence-degraded display score to compute confidence again.

Important distinction: regime z-scores vs scorecard normalization

regime.drivers[].z_robust is computed from 180-day raw daily values using 0.6745 × (x − median) / MAD. Scorecard dimension scores are computed from 7-day rolling averages against a 365-day baseline using (x − median) / (1.4826 × MAD). These are two separate calculations with separate purposes and separate input series. They will not produce identical values for the same metric on the same day.

BTC capacity note

For Bitcoin, gas_utilization_pct is not published. The capacity axis therefore relies entirely on blocktime_instability, computed as the rolling mean of |avg_block_time_sec − rolling_median_30| / rolling_median_30.

This instability index measures deviation from the chain's own recent block-time norm in both directions. A period of consistently fast block production and a period of consistently slow block production will both produce low instability and therefore a low capacity score. A high capacity score on Bitcoin means block timing is unusually erratic relative to recent history — not that blocks are slow.

Consumers using BTC capacity scores should interpret them as a block-time volatility signal, not a congestion-in-the-traditional-sense signal.

Regime methodology

Regime is the product’s categorical interpretation layer. It maps chain-relative analytical conditions into one of five public states: STABLE, HEATING, CONGESTED, CHEAP, and UNKNOWN/DEGRADED.

The current implemented regime engine uses:

robust z-score based on 180-day raw daily history
90-day percentile rank for banding support
OR logic for threshold-triggered band assignment
momentum epsilon 0.15 for heating/cooling trend state
label evaluation order: CONGESTED → CHEAP → HEATING → STABLE

Urd Atlas does not apply a universal fixed multi-day confirmation rule across all regime labels. Persistence is label-specific. HEATING depends in part on a trend condition derived from short-vs-medium horizon behaviour, which introduces implicit persistence. CONGESTED and CHEAP are state-triggered classifications and do not require separate trend confirmation or a fixed multi-day confirmation window before publication.

Scorecard pressure vs regime threshold

The scorecard and regime label are related but not identical. A scorecard axis can show adjacent pressure, such as high demand, while the regime label remains STABLE if the regime-axis evidence did not cross the label threshold. In those cases status.one_liner should explain the adjacent pressure instead of implying that the scorecard and regime label are the same thing.

Label stability for downstream consumers

HEATING requires directional trend confirmation: the short-term moving average must be running ahead of the medium-term average before the label fires.
CONGESTED and CHEAP do not require trend confirmation. Either label can fire on a single-day threshold crossing if the relevant axis signals are sufficiently elevated or depressed.
Labels can therefore change day to day in response to daily evidence. Consumers who use regime labels as period classifiers for backtesting or segmentation should apply their own minimum-duration or smoothing rule if multi-day stability is required.

Derived metric consequences that matter for interpretation

Some analytical components are intentionally derived rather than directly copied from a Gold field. This is methodologically valid, but it changes what the published score means.

fee_burden_proxy inside friction is a ratio of median fee to median transferred value, not a native fee field.
For BTC, blocktime_instability is the only capacity component. It is an instability proxy around the recent block-time norm, not a directional slow-block-only measure.

A period of consistently fast block times and a period of consistently slow block times can both produce low BTC capacity stress if both are stable relative to the recent norm.

Public row identity and traceability

Archived Meta rows do not rely on a separate public revision integer for identity. Public row identity is anchored in the fields that are actually present in the archive.

All rows: chain, date, methodology_version
Confidence rows: confidence.methodology_version, confidence.formula, confidence.candidate_label
Named regime rows: regime.determinism_hash
Gated rows: updated_through, confidence.confidence_score, status.label

What this page intentionally does not disclose

Exact upstream AWS schemas, join logic, or source repair rules
Intermediate feature tables and internal parquet structures
Full proprietary calibration constants required to clone the classifier end to end
Enough implementation detail to reconstruct raw source rows from published aggregates

The public methodology is designed to make the product auditable in meaning, not reconstructable in implementation.

Public Methodology Reference

Purpose of this reference

Global interpretation rules

Artifact model

Gold methodology

Derived methodology

Confidence v2 methodology

Why profile-aware data quality matters

Scorecard methodology

Important distinction: raw scorecard evidence vs display score

Important distinction: regime z-scores vs scorecard normalization

BTC capacity note

Regime methodology

Scorecard pressure vs regime threshold

Label stability for downstream consumers

Derived metric consequences that matter for interpretation

Public row identity and traceability

What this page intentionally does not disclose

Read next

Public Methodology Reference

Purpose of this reference

Global interpretation rules

Artifact model

Gold methodology

Derived methodology

Confidence v2 methodology

Why profile-aware data quality matters

Scorecard methodology

Important distinction: raw scorecard evidence vs display score

Important distinction: regime z-scores vs scorecard normalization

BTC capacity note

Regime methodology

Scorecard pressure vs regime threshold

Label stability for downstream consumers

Derived metric consequences that matter for interpretation

Public row identity and traceability

What this page intentionally does not disclose

Read next