Glossary

This flag tells you whether the confidence layer was incomplete or unavailable for the row. If true, the product should not pretend it knows more than it does.

When true, the UI should avoid presenting the classification as fully supported. The correct design response is visible uncertainty, not UI-side invention or silent substitution.

Confidence tells you how much evidence supports the currently published classification. It is not a prediction score and it is not the probability that the regime is 'true'. A higher value means the current label is backed by more complete data and a clearer internal signal structure.

In the current backend, confidence_score is the geometric mean of data_quality_score and label_confidence_score: sqrt(data_quality_score × label_confidence_score). That means confidence only stays high when both inputs are strong. It should be read as evidence sufficiency for the present classification, not as forecast skill, expected return, or directional conviction.

A machine-readable reminder of what the confidence score is supposed to mean. It helps keep the UI honest about the interpretation.

The current semantics string identifies the score as a combination of data quality and label stability. This is important because it prevents the product from drifting into a misleading interpretation such as probability of future success or price direction.

How much of the latest row's required input data is actually present. A value near 1 means the latest day has the fields the chain is expected to provide.

This is computed from chain-specific required metrics, not from every possible field in the dataset. It answers 'does the latest row contain the inputs this chain needs for classification?' rather than 'is every column in the file populated?'.

This score asks a simpler question than full confidence: 'Do we have enough complete and recent data to evaluate the chain properly right now?' It is the data sufficiency side of confidence, before the model asks whether the regime itself is internally clear.

The backend computes data_quality_score from five weighted components: current_row_coverage (30%), recent_metric_coverage (20%), recent_density (20%), history_depth (15%), and freshness_asof (15%). The score is clipped to 0..1. This is about data completeness and freshness only; it does not yet judge whether the regime label is sharp or ambiguous.

How fresh the row is relative to the chain's normal publishing lag. A chain can still be usable when not perfectly fresh, but confidence should decline when lag becomes unusually large.

Freshness is chain-aware. The backend compares lag against PUBLISH_LAG_DAYS_POLICY for the chain, then applies a soft-to-hard penalty curve. This matters because Base and Arbitrum are allowed more lag than Bitcoin or Ethereum, so the same calendar lag should not automatically mean the same freshness score across chains.

How much historical depth is available for the current computation. More history usually makes baselines, percentiles, and unusualness estimates more trustworthy.

In the current backend this is capped at 1.0 once roughly 90 distinct days are available. The score is not trying to reward infinite history forever; it is trying to avoid giving full confidence to a regime that was inferred from a very short local sample.

This score measures how clearly the current scorecard and driver evidence support the label that was chosen. It is the signal-clarity side of confidence.

For non-STABLE labels, label confidence mainly depends on scorecard margin and driver support. For STABLE, the model also rewards neutrality, because a stable label should look genuinely close to the chain's own middle ground rather than merely lacking extreme readings. UNKNOWN/DEGRADED maps to zero label confidence.

How many actual published days exist in the recent trailing window relative to how many days should ideally be there. It is a direct check for holes in the recent series.

The backend measures recent_density as observed distinct days divided by expected recent days. This is why missing runs or broken daily continuity immediately push data quality down, even if the rows that do exist look individually complete.

The average row-level coverage across the recent trailing window. It tells you whether the last several weeks look consistently complete, not just whether the latest row is complete.

The backend computes recent_metric_coverage as the average of row coverage over the recent trailing window used by the confidence routine. This catches situations where today's row looks complete but the surrounding days are patchy, which would make trends less trustworthy.

This tells you how unusual the metric currently looks relative to its own history. The larger the absolute value, the more exceptional the reading is. 'Robust' means the method tries to be less sensitive to outliers than a naive standard deviation approach.

z_robust is one of the main driver-sorting signals in the UI and in backend support logic. It is especially important because label confidence uses driver signal support. Very small absolute z-scores mean the metric is not standing far from its own baseline; large absolute z-scores mean the metric is contributing unusually strong evidence.

The lag between the row's own as-of date and the latest source day used for that row. If this is 0, the row and its data date match. If it is larger than 0, the row is being judged using older underlying data.

This is the historically correct lag measure for Track Record-style views. It is different from lag versus today. Using lag_days_vs_asof_date avoids the misleading effect where old historical rows would automatically look stale simply because time has passed since publication.

How many days behind the latest published chain data is relative to today. This is useful for current freshness banners, but less useful for interpreting old historical rows.

This field remains useful for current page freshness and operational monitoring. It should not be confused with historical as-of lag. A row from months ago can have a large lag vs today even if it was perfectly fresh when it was published.

The regime label is the product's compact description of the chain's current on-chain state. It is descriptive only. It does not predict what happens next and it does not tell the user what to do. Its job is to summarize whether the latest published evidence looks more like stable conditions, heating demand, congestion pressure, cheap conditions, or a degraded / low-confidence state.

The frontend treats status.label as the canonical published regime label and only falls back to regime.label if status.label is unavailable. In the backend, the label is produced by deterministic rules over Demand, Friction, and Capacity evidence, with a confidence gate that can force UNKNOWN/DEGRADED. The UI does not recompute the label. The correct interpretation is therefore 'published classification result', not 'UI opinion' or 'forecast'.

The one-liner is a short human-readable summary of the published regime. It is there to make the page readable at a glance before the user dives into the detail.

This text is pipeline-authored descriptive copy published alongside the regime label. The UI renders it directly and should not be treated as an independent inference layer. It compresses regime, confidence, and chain context into one short sentence.

STABLE means the chain does not currently show a strong enough combination of demand pressure, friction pressure, or cheap-capacity conditions to justify a more extreme label. It does not mean 'nothing is happening'. It means the chain still looks broadly within its normal historical operating range.

In the ruleset, STABLE is the default label when the evidence does not meet CONGESTED, CHEAP, or HEATING conditions and the confidence gate does not force UNKNOWN/DEGRADED. In practice this usually means scorecard dimensions are not far enough from neutral, or the directional evidence is not persistent enough, to support a stronger regime label.

UNKNOWN/DEGRADED means the product does not have enough trustworthy evidence to publish a stronger regime label confidently. The latest data may still be visible for traceability, but the classification itself should be treated as insufficiently supported.

This state is usually triggered by the confidence gate rather than by a separate market condition. In the current model, the published regime becomes UNKNOWN/DEGRADED when combined publish confidence falls below the configured threshold. It is therefore an evidence-quality state, not a fifth economic regime in the same sense as STABLE, HEATING, CONGESTED, or CHEAP.

A 0-100 score describing how tight the chain's capacity conditions look. Higher means the chain appears closer to practical throughput pressure. Lower means more room to spare.

Capacity is built from gas_utilization_pct and blocktime_instability. The product uses 'capacity' to mean pressure on usable execution capacity, not installed theoretical capacity. Like the other dimensions, the final score is pulled toward 50 when effective confidence is low.

Coverage factor tells you how many of an axis's expected components were actually available. A lower value means that axis had to be judged with fewer than the ideal supporting inputs.

Each scorecard dimension has an expected component count: Demand expects 3, Friction expects 2, Capacity expects 2. coverage_factor is used together with overall confidence to form effective_confidence for that axis. This is why a dimension can stay visible but become visibly less assertive when component coverage is incomplete.

A 0-100 score describing how hot the chain's demand side looks relative to its own history. Around 50 is neutral. Higher means more demand pressure. Lower means quieter conditions.

Demand is built from tx_count_daily, unique_active_addresses, and tx_per_user. The raw component scores are combined and then shrunk back toward 50 according to effective confidence. This means high demand scores require both strong signals and enough confidence to trust them.

Effective confidence is the amount of confidence that actually reaches a single scorecard axis after taking that axis's coverage into account.

The backend computes effective_confidence as base_confidence × coverage_factor for each dimension. The final displayed score is then moved back toward 50 using this value. That is why low effective confidence does not necessarily delete a score; instead it makes the score less extreme and therefore more conservative.

A 0-100 score describing how difficult or expensive the chain currently looks to use relative to its own history. Higher means more cost or execution friction. Lower means the chain looks easier to use.

Friction is built from fee_burden_proxy and failed_tx_rate. The important subtlety is that this is not just a fee level. It is a composite pressure view of cost and failure-like strain, expressed relative to the chain's own normal behavior and shrunk toward 50 when confidence is weak.

A built-in note explaining how to read the scorecard. The core idea is simple: scores are 0-100, 50 is neutral versus the chain's own history, and low confidence pulls scores back toward 50.

This note is important because it encodes the product's central score semantics: chain-relative normalization, 50 as neutral midpoint, and confidence-aware shrinkage. Those three ideas are what stop the scorecard from being mistaken for an absolute cross-chain ranking.

The qualitative band attached to a score, such as low, normal, or high. It makes the numeric score easier to read quickly.

Levels are not separate data; they are categorical interpretations of the underlying 0-100 score. The confidence logic also uses score-versus-level margin, because a label should be more trustworthy when the score sits well inside its assigned band rather than barely touching it.