L2

Arbitrum and Base are handled as L2 profiles, not as miniature copies of ETH L1. Their fee stack has both local execution semantics and parent-chain settlement/security cost, so a simple “high fees means the chain is constrained” interpretation is often too naive. A visible fee move on an L2 can reflect some combination of local execution demand and parent-chain posting cost rather than one single bottleneck.

The product therefore uses a profile layer to suppress L1-only signals where they would be misleading and to privilege the metrics that remain stable and interpretable on an L2. In practice, the page is asking: is the rollup currently carrying unusual demand, unusual fee burden, or unusual tightness relative to its own recent history? It is not claiming that L2 and L1 values are directly fungible.

The advanced reader should think of the L2 page as a constrained descriptive mapping under a chain-specific semantic contract. The model preserves comparability at the regime/state level while explicitly limiting comparability at the raw-metric level.

This reading order mirrors the structure of the published data contract. Freshness and confidence are gating variables; regime is the compressed state output; scorecard is the axis-level decomposition; drivers are the ranked evidence rows; charts are the time-series visualization layer. In methodological terms, the page is arranged from contract-level validity checks to semantic compression to granular evidence.

The advanced reason for this order is to avoid a common analytical error: over-weighting the visual salience of a recent line move before establishing whether the visible row is timely, publish-eligible, and semantically well-supported. The charts contextualize the state; they do not define it.

The browser does not infer regime. It reads the canonical published label from meta.status.label, where the upstream pipeline has already combined axis conditions, chain profile rules, and the confidence gate. In other words, the visible label is an audited output of the meta layer, not a UI heuristic.

The regime vocabulary is a finite state set: STABLE, HEATING, CONGESTED, CHEAP, and UNKNOWN/DEGRADED. These states are meant to compress the chain’s location in a three-axis space defined by Demand, Friction, and Capacity, with the final label then constrained by publish-confidence eligibility. The confidence threshold is therefore part of the state machine: if confidence is below the canonical gate, the UI must treat the row as UNKNOWN/DEGRADED even when the raw axis pattern might otherwise resemble a named state.

The correct technical interpretation is: regime is a deterministic classification over the published meta payload, not a probability of future returns and not a recommendation class. The current label STABLE is a descriptive compression of the present chain state conditional on methodology version, chain profile, window, and confidence gate.

Confidence is a published meta-layer quantity in confidence.confidence_score. The UI never rebuilds it. It is used in two roles at once: first as an evidentiary score for how strongly the current descriptive row is supported, and second as a governance gate for whether the visible regime may remain a named state or must degrade to UNKNOWN/DEGRADED under the canonical threshold contract.

In the patched meta files, confidence is conceptually a synthesis of row usability and label support. The payload may expose component views such as data_quality_score and label_confidence_score; in the current row they are 1.000 and 0.733. The key question confidence answers is: “given the currently published row, how much descriptive weight should be placed on the label?”.

Technically, this is not a confidence interval, not a posterior probability, and not a forecast probability. It is a bounded support score on [0,1]. The current product contract uses a hard publish gate at 0.40: values below that threshold force degraded semantics, while values above it permit named states. The UI bands (Good / Caution / Degraded) are presentation tiers layered on top of the scalar. They do not replace the underlying number.

As-of is the temporal anchor of the visible row. The page surfaces the latest published date from the canonical meta bundle; it does not infer freshness from chart endpoints or browser time. In a reproducible system, every descriptive statement must be traceable to a concrete observation date, and as-of is that date-level binding.

The advanced reason this matters is that a regime label is only meaningful conditional on its information set. A label computed on one date and viewed later may be equally well-defined, but it is not equally current. This is why the product separates temporal recency (as-of and lag) from evidentiary support (confidence): they answer different questions and should not be collapsed into one omnibus quality number.

In practice, as-of is the date to use when reconciling the visible page against dataset manifests, daily published files, and any downstream audit. If a reader cannot pin the visible state to a concrete observation date, the state is not operationally traceable.

Lag is an operational freshness statistic measured in days from the latest published observation to “today” in the product’s UTC framing. It is not a reliability score and not a confidence penalty by itself. A low-lag row may still be weakly supported; a higher-lag row may still be internally coherent. The UI separates these concepts because conflating them would hide whether the issue is timeliness or evidentiary strength.

Formally, lag answers a scheduling question: how far is the visible row behind the current calendar? It should be read relative to the chain’s publish-lag policy, not in isolation. For BTC/ETH a 1-day lag is normal; for Base/Arbitrum a materially larger expected lag is part of the product contract. So the advanced user should interpret lag as a deviation from chain-specific publication cadence, not as a universal freshness threshold.

The reason lag belongs on the page is auditability. It makes it explicit whether the state is operationally current enough for the user’s purpose. It does not tell you that the label is wrong; it tells you whether the label is temporally up to date.

regime.determinism_hash is published for auditability: it is a hash over the input data and parameter context used to produce the regime/meta output. The UI does not derive it. Its presence is a reproducibility guarantee that the visible classification is tied to a specific upstream computational state rather than to local browser logic.

In a deterministic publishing pipeline, identical inputs under identical parameters should generate identical outputs. The hash is therefore not a user-facing score; it is a compact fingerprint of computational identity. If the hash changes while the displayed date, chain, and methodology context appear unchanged, a technical reader immediately knows that some relevant input or parameterization changed upstream.

The accompanying window-days field matters because regime and scorecard are windowed objects. A 7-day classification and a 30-day classification can be equally deterministic yet refer to different state definitions. So the proper advanced reading is the tuple (methodology version, chain profile, window, determinism hash), not the hash alone. Current hash: 23c97a76408b. Current window: 7.