JSON Schema Reference
Gold, Derived, Meta, and Briefs

The as-of date for all metrics in the row. Computed as a UTC calendar day. This is the temporal coordinate used for all downstream processing — z-score windows, percentile lookups, and moving average computations all anchor to this field. It is a string in ISO 8601 format (YYYY-MM-DD) rather than a timestamp to avoid timezone ambiguity.

Canonical chain identifier used as a routing key across the entire published artifact hierarchy. The chain field determines which metric profile applies — BTC uses a UTXO profile that suppresses EVM-specific fields; ETH L1 exposes the full EVM surface; L2s use a rollup-specific profile.

Count of confirmed transactions from the AWS Public Blockchain Data transactions table for the given UTC day. On EVM chains this includes all transaction types; on Bitcoin this counts confirmed UTXO-model transactions. Used as the primary demand signal — feeds scorecard.dimensions.demand via log-normalised z-score.

Count of distinct blocks from the AWS blocks table for the given UTC day. Used as a denominator for avg_block_time_sec and as a throughput normaliser. On Bitcoin, consistent deviation from the ~144/day target can indicate hash rate changes or difficulty adjustment effects. On EVM chains with near-instant block times, this number is much larger.

Sum of the best-available native value field from the AWS transactions table. Interpretation varies by chain — on Bitcoin this is the sum of UTXO outputs; on EVM chains it reflects msg.value transfers. This field has known semantic limitations: it includes protocol-level movements, smart contract interactions where value is not economically meaningful, and internal transfers. It should be used for trend context rather than as a precise economic volume measure.

P50 of the transaction value distribution for the day. Used as a denominator in fee_burden_proxy = median_tx_fee_native / median_tx_value_native, which normalises fee cost relative to the typical economic size of a transaction. On EVM chains where many transactions have zero msg.value (smart contract calls), this can be near zero and the fee burden proxy may not be meaningful — the pipeline handles this gracefully via null fallback.

P50 of the fee distribution for the day in native units. The primary friction input. On Ethereum, this reflects the median total fee (base + priority) post-EIP-1559. On Bitcoin, this is the median sat-denominated fee. The raw value in native units is published without conversion — unit interpretation depends on the chain.

Mean of (receipt_status != 1) for EVM transactions. Always null for Bitcoin, which has no analogous on-chain failure concept under the UTXO model. A rising failed_tx_rate alongside elevated fees suggests the network is under genuine execution strain rather than merely high demand. Feeds scorecard.dimensions.friction alongside fee_burden_proxy.

Mean of gas_used / gas_limit across all blocks for the day. Only meaningful for Ethereum L1 — hidden for Bitcoin (no gas model) and L2 chains (different capacity mechanics). Under EIP-1559, the target is 50% utilisation with a 2× burst ceiling. Values consistently above 50% indicate the base fee is rising; values near 100% indicate the network is running at its hard ceiling. The primary scorecard.dimensions.capacity input for ETH L1.

Count of unique addresses appearing in either the sender or recipient field of transactions for the day, excluding nulls. On EVM chains this is generally available; on Bitcoin the UTXO model makes address-level aggregation less reliable and this field is often null. Used alongside tx_count_daily in the demand axis — together they distinguish broad shallow usage from concentrated deep usage via the derived tx_per_user ratio.

Computed as (period duration in seconds) / block_count for the day. Used in the capacity axis not as a raw value but as input to a derived instability proxy: the pipeline computes how much the block time deviated from its own rolling median, then feeds that instability signal into the capacity scorecard. This avoids treating a slightly faster block time as uniformly better or worse — what matters is whether block production became erratic.

Canonical date field — matches the Gold row this meta output was computed over. Used as the primary key for row-level lookups and time-series ordering.

Chain identifier propagated from the Gold layer. Determines the metric profile applied during computation.

The temporal ceiling of the evidence window used for this meta row. A date field rather than a timestamp to match the Gold schema convention. Critical for time-series analysis — use this as the observation date, not the pipeline run timestamp.

Version string identifying the pipeline methodology. Required for comparability analysis: rows with different methodology_version values may have been produced under different threshold parameters, metric definitions, or scoring formulas. Changes to this field are documented at /methodology/changelog.

Public provenance should be read via methodology_version, updated_through, dataset revision, and regime.determinism_hash. Do not treat revision_id as the sole or required public traceability anchor.

Deterministic output of the regime classification rule tree, applied after confidence gating. Rule evaluation order: (1) confidence < 0.40 → UNKNOWN/DEGRADED; (2) Capacity EXTREME_HIGH or (Capacity HIGH and Friction HIGH) → CONGESTED; (3) Friction LOW and Capacity LOW → CHEAP; (4) Demand HIGH and any axis HEATING → HEATING; (5) default → STABLE. The UI reads this field directly — it never recomputes the label.

Maps 1:1 to status.label: STABLE=green, HEATING=yellow, CONGESTED=red, CHEAP=blue, UNKNOWN/DEGRADED=gray. UI presentation field only — no analytical meaning beyond label mapping.

Pipeline-authored descriptive copy that compresses regime, scorecard levels, and chain context into one sentence ≤80 chars. Rendered directly on chain pages. Not an independent inference layer — it restates the scorecard levels in prose.

Geometric mean of data_quality_score and label_confidence_score: √(dq × lc). The geometric mean ensures weakness in either component suppresses the composite. Hard gate: if score < 0.40 then status.label is forced to UNKNOWN/DEGRADED. Caution band 0.40–0.69: scorecard scores are degraded toward 50 via score = 50 + (score−50) × effective_confidence.

Profile-aware composite of current required metric coverage, recent required metric coverage, recent density, history depth, and freshness versus the chain-specific publish policy. Structurally non-applicable metrics are excluded from the denominator and optional non-penalized metrics are documented separately. Weakness in data quality suppresses the full confidence score via the geometric mean.

Confidence v2 is label-specific and uses score_raw/regime evidence rather than confidence-degraded display scores. HEATING rewards demand rule margin, demand driver strength, trend strength, axis coherence, and available persistence. CONGESTED rewards friction/capacity pressure. CHEAP rewards low-friction evidence and absence of tight capacity. STABLE rewards genuine neutrality and lack of strong drivers. UNKNOWN/DEGRADED maps to 0. A materially lower label_confidence than data_quality indicates data is present but classification margin is thin.

Confidence v2 uses profile-aware data quality and label-specific evidence scoring. Structurally non-applicable chain fields are excluded from data-quality denominators, while optional fields remain visible without reducing confidence. The public composite remains sqrt(data_quality_score × label_confidence_score).

When confidence is below the product threshold, status/regime can be withheld as UNKNOWN/DEGRADED while candidate_label records the label that the evidence surface pointed toward, its label_confidence_score, and whether it was withheld by the confidence gate.

Signed integer difference between UTC today (at page render) and the as-of date. Chain-specific policy: BTC/ETH expect 1-day lag; ARB/BASE expect 7-day lag. Staleness thresholds are calibrated relative to these expectations. Use as a freshness diagnostic — do not confuse with confidence_score, which is an evidence quality measure, not a recency measure.

Set to true when the pipeline cannot produce a meaningful confidence value — typically due to insufficient data coverage or a broken pipeline stage. When true, the UI should surface a degraded state rather than presenting a spurious confidence number.

Exists to prevent semantic drift — as the confidence model evolves, this field signals what definition was in effect when the row was computed. Not intended for display; intended for programmatic consumers who need to distinguish confidence models across methodology versions.

Computed as 50 + 40 × tanh(z / 1.5) over the combined demand z-signal, then degraded toward 50 by effective_confidence = base_confidence × coverage_factor. Input metrics: tx_count_daily (log-normalised), unique_active_addresses, and tx_per_user ratio. Demand coverage factor is 3/3 when all inputs are present.

Discretisation of the continuous score. The regime engine uses these band values — not the raw score — in its classification rules. HEATING requires Demand = HIGH.

Demand expects 3 components (tx_count, active_addresses, tx_per_user). coverage_factor = available / 3. Multiplied by base_confidence to produce effective_confidence for this axis. Low coverage pulls the demand score toward 50 to avoid over-interpretation.

Computed as base_confidence × coverage_factor. This is the value used to degrade the raw demand score toward 50. A demand score of 80 under effective_confidence 0.9 is much more assertive than the same score under effective_confidence 0.3.

Input metrics: fee_burden_proxy (median_tx_fee / median_tx_value) and failed_tx_rate. Both are log-normalised and z-scored before aggregation. CONGESTED requires Friction HIGH alongside Capacity HIGH. CHEAP requires Friction LOW.

Friction expects 2 components. On Bitcoin, failed_tx_rate is always null (no EVM failure concept), so Bitcoin friction coverage is structurally capped at 0.5 for that component. The pipeline handles this gracefully — Bitcoin's friction profile only uses the fee component.

Input metrics vary by chain profile: ETH L1 uses gas_utilization_pct and blocktime_instability; BTC uses blocktime_instability only (no gas); L2s use capacity_util_pct and blocktime_instability. The chain-specific profile prevents L1 gas semantics from being applied to non-L1 chains.

Fallback field used when status.label is unavailable. The UI resolution order is: status.label → regime.label → UNKNOWN/DEGRADED. In well-formed rows both are identical.

The temporal anchor of the regime computation, distinct from the pipeline run timestamp. Used in the asof resolution hierarchy alongside updated_through.

SHA-256 of the canonical JSON serialisation of (chain, label, asof_date, drivers, window_days), truncated to 12 hex characters. Computed as stable_sha256_12(json_dumps_canonical(det_payload)). Enables tamper detection: retroactive reclassification of a historical label would produce a different hash. Use this for backtesting integrity validation.

The rolling window used for z-score baselines, percentile rank computation, and moving averages. Typically 7 days for the current row computation (most sensitive to recent conditions), though longer windows are used internally for percentile rank (90 days) and z-score baseline (180 days).

Ranked subset of the full evidence surface, ordered by a composite driver score: weight × (|z_robust| + 0.75 × |pct_dist| + 0.50 × |momentum|). Only the top drivers that are label-consistent are surfaced. Absence from the driver list does not mean a metric was uninformative — it means it ranked below the display threshold.

Canonical metric key matching the Gold field name. For derived signals like blocktime_instability or fee_burden_proxy, the key identifies the computed signal rather than a raw Gold field.

The axis assignment reflects the metric's role in the scorecard, not just its statistical properties. A metric with a high z-score assigned to demand tells you demand is the primary driver of the current state — not that the metric happens to be elevated.

MAD-based robust z-score: 0.6745 × (x − median) / MAD. The 0.6745 factor makes it asymptotically equivalent to a standard z-score under Gaussian assumptions while inheriting outlier robustness. Fallback: if MAD=0 use standard z; if std=0 return 0.

Empirical percentile rank of the current observation within the trailing 90-day sample. Minimum 30 non-null observations required; suppressed otherwise. Orthogonal to z_robust: pct answers 'where does this sit in the recent distribution?' while z answers 'how many robust standard deviations from the median?'

Defined as z_robust(mean_7d) − z_robust(mean_30d). Removes level effects by standardising both windows against the same 180-day baseline before differencing. Threshold: ≥ 0.15 is HEATING trend; ≤ −0.15 is COOLING; otherwise FLAT.

Direct observation from the Gold layer carried into the driver row for auditability. Allows downstream consumers to verify that z-scores and percentiles are computed over a sensible underlying level. Required for cross-validation against independent data sources.

Categorical summary of momentum_7d_vs_30d. Used in regime rule evaluation — HEATING label requires at least one axis driver showing HEATING trend alongside Demand HIGH.

Result of the dual-criterion band classification: HIGH if pct_90d ≥ 80 OR z_robust ≥ 1.5; EXTREME_HIGH if pct_90d ≥ 95 OR z_robust ≥ 2.5; LOW if pct_90d ≤ 20 OR z_robust ≤ −1.5; EXTREME_LOW if pct_90d ≤ 5 OR z_robust ≤ −2.5; otherwise NORMAL.

Each axis object contains band_high (NORMAL/HIGH/EXTREME_HIGH), band_low (NORMAL/LOW/EXTREME_LOW), and trend (HEATING/FLAT/COOLING). These are computed as aggregates over the axis's driver signals rather than from a single metric. Used internally in regime rule evaluation.

Contains type (btc/eth_l1/l2), label, hidden_metrics[] (metrics suppressed for this chain type), capacity_proxy (which metrics proxy capacity for this chain), and an optional note. The profile field makes chain-specific behaviour explicit in the published artifact rather than requiring consumers to know which metrics apply to which chains.

Temporal anchor for all derived values in this row. All moving averages are computed as backward-looking windows terminating at this date.

Propagated from Gold. Determines which metrics are present in the derived.metrics object for this row.

Arithmetic mean over the last 7 non-null observations of the corresponding Gold metric, computed with min_periods=1 (so early rows in the series still get a value, just with a smaller window). Naming convention: tx_count_daily__ma7, median_tx_fee_native__ma7, etc. All numeric Gold fields get both MA7 and MA30 variants. The 7-day window is the short-horizon smoother used for momentum calculation in the regime engine.

Arithmetic mean over the last 30 non-null observations, with min_periods=1. The 30-day window is the medium-horizon baseline used in momentum computation: momentum_7d_vs_30d = z_robust(mean_7d) − z_robust(mean_30d). For chart reading, the MA30 slope over the visible window is the most reliable indicator of structural regime change — short spikes in MA7 above MA30 without sustained elevation are typically noise.

Contains confidence_score (same value as meta.confidence.confidence_score for this date). Published alongside the derived metrics so UI components that render charts with confidence overlays do not require a separate Meta fetch.

Placeholder for the analog engine output (compute_analogs_and_forward_stats). The analog engine is implemented in the pipeline but context_blocks are not yet populated in published reference data artifacts. When the feature ships, this array will contain historical periods whose on-chain signature most closely resembled the current state, along with forward statistics for each analog period.

Expected values include schema identifiers such as urd_atlas.chain_brief.v1 or urd_atlas.site_briefs_bundle.v1, depending on whether the file is a per-chain brief or a site-level bundle.

The status separates the availability of the readable narrative layer from the underlying technical Meta artifact. A degraded brief can still preserve structured facts while replacing unsafe or invalid narrative text with fallback language.

Used for entitlement routing and for joining the brief back to the Gold, Derived, and Meta technical artifacts for the same chain.

Briefs are daily context, not intraday commentary. updated_through should be read as the as-of boundary of the underlying data used to generate the brief.

Carried from the Meta regime context. Briefs do not create a separate label; they make the existing Meta label readable and easy to consume.

Generated from deterministic templates and validated against the Briefs language policy. It should remain descriptive and avoid predictive, advisory, or trading-oriented language.

Derived from the latest and recent Meta confidence values. It helps the reader understand whether the brief is based on high-support or low-support context without replacing the full Meta confidence object.

The Briefs layer is validated so the narrative stays inside the same methodological boundaries as the technical JSON. Consumers should preserve these guardrails when displaying or redistributing brief text.