Extreme download skew.downloads_30d runs from 808,600 to 239.2M, with a mean of 4.26M against a median of 1.69M and a standard deviation of 13.51M — more than triple the mean. The same pattern appears in downloads_per_day (median 3,044, mean 11,410, max 618,100) and in adoption_zscore, which is floored at −0.26 but reaches 17.38. A handful of models dominate the distribution; averages will mislead unless you work in medians or logs.

Likes follow the same shape but less severely. Median 236.5 versus mean 713.2, max 13,560. downloads_per_like is the most volatile field in the set: median 8,775, mean 58,990, max 2.53M — a 288× gap between median and maximum, useful for spotting heavily-used but rarely-starred infrastructure models.

Maintenance is a real problem, not an edge case. 281 of 500 models (56%) are flagged is_stale. The maintenance classes are nearly balanced — dormant 141, abandoned 140, maintained 133, active 86 — meaning 281 models fall in the two lowest tiers. days_since_update reaches 1,911 days (over five years) against a median of 446.

Concentration by author and task. Qwen alone accounts for 79 rows (15.8%), ahead of google (25), facebook (17), nvidia (17) and microsoft (16). transformers covers 331 of 471 library entries. Text-generation (115) and image-text-to-text (79) lead 35 task categories.

Timestamp artifact worth knowing. 95 rows share two near-identical created_at values from 2022-03-02 — a Hub migration timestamp, not a genuine launch date. This inflates days_since_launch accuracy for roughly a fifth of the sample.

Overview

The dataset profiles 500 unique models from the Hugging Face Hub leaderboard, combining raw hub telemetry (downloads, likes, timestamps) with derived engagement, recency and maintenance indicators. The statistical work consists of one deduplication/ordering pass, two temporal age derivations, four column-level derivations (two ratios, one standardisation, one min–max normalisation), one weighted composite score, one binned classification, and one boolean threshold flag.

1. Preparation: normalisation, deduplication, ordering

• normalize — applied first to harmonise field representations across records prior to any arithmetic.
• dedupe on model_id — enforces one row per model. The profile confirms the constraint held: model_id has 500/500 non-null values and 500 distinct values, so the effective unit of analysis is the individual model repository.
• sort by model_id — deterministic ordering only; carries no statistical content, but makes downstream row-wise outputs reproducible.

Note that deduplication was keyed on model_id, not on author. Authors are therefore repeated by design: 162 distinct authors across 500 rows, with a strongly concentrated head (Qwen 79 rows, google 25, facebook 17, nvidia 17, microsoft 16). Any author-level statistic computed from this table is an unweighted count of repositories, not of organisations.

2. Temporal aggregation: age in days

Two age_days transforms convert absolute timestamps into elapsed-day integers:

Both distributions are right-skewed (mean > median), indicating a long tail of very old or long-unmaintained repositories. days_since_update reaches 1911 days, exceeding the maximum days_since_launch of 1622 — an internal inconsistency worth flagging, since a model cannot plausibly have gone un-updated for longer than it has existed. This suggests the two anchors are drawn from different clocks or that some last_modified values predate the recorded created_at. The last_modified field also contains at least one future-dated value (2026-07-21), and created_at contains a large tie block at 2022-03-02T23:29:05.000Z (74 rows) plus a second at 2022-03-02T23:29:04.000Z (21 rows) — almost certainly a bulk backfill timestamp rather than genuine creation dates. Roughly 19% of launch ages are therefore anchored to a single synthetic instant.

3. Ratio derivations

downloads_per_like = ratio(downloads_30d, likes) — an efficiency/attention ratio expressing how many downloads accompany each like.

• Coverage: 494/500 non-null. The 6 missing values correspond to the division-by-zero cases; likes has min = 0, so the ratio is undefined for those models and was left null rather than imputed.
• Distribution: min 149.2, median 8,775, mean 58,990, max 2.53e6, stdev 1.94e5. The mean is ~6.7× the median and the standard deviation exceeds the mean by more than 3×, so this metric is dominated by a handful of extreme ratios. The median is the only defensible central-tendency summary here.

downloads_per_day = ratio(downloads_30d, days_since_launch) — a crude lifetime download rate.

• Distribution: min 515.3, median 3,044, mean 11,410, max 6.181e5, stdev 3.401e4.
• Methodological caveat: the numerator is a 30-day download window while the denominator is the model's entire lifetime in days. The resulting quantity is therefore not a download rate in any consistent sense — it is a 30-day volume amortised over total age, which systematically penalises older models and inflates newly launched ones. Its unit label (downloads/day) overstates its interpretability.

4. Standardisation: adoption_zscore

zscore(downloads_30d) centres and scales the download volume:

• Confirmed by the profile: mean ≈ -3.065e-17 (numerically zero) and stdev = 1.000, as expected for a correctly computed z-score over the full column.
• Range: min = -0.2554, max = 17.38. This asymmetry is diagnostic: because downloads_30d is extremely right-skewed (min 8.086e5, median 1.69e6, mean 4.261e6, max 2.392e8, stdev 1.351e7), the floor of the distribution sits only a quarter of a standard deviation below the mean while the top model sits over 17 standard deviations above it.
• Consequence: the z-score does not function as a usable spread measure here. It compresses the bottom ~99% of models into a narrow band near -0.25 to 0 and reserves nearly all of its dynamic range for a few outliers. A log transform prior to standardisation would have been more appropriate for a distribution with this shape; no such transform was applied.

5. Min–max normalisation: freshness_index

minmax_normalize(days_since_update, invert=true) rescales update recency to [0, 1] with 1 = most recently updated:

• Range confirmed at exactly 0 to 1, mean 0.729, median 0.7666, stdev 0.223.
• The inversion is anchored to the observed extremes (0 and 1911 days), so the index is sample-relative: the endpoints are defined by the single freshest and single stalest model in this 500-row snapshot. Adding or removing either extreme rescales every other value.
• Because days_since_update is right-skewed, linear min–max mapping pushes the bulk of models into the upper part of the range (median 0.77), which visually overstates how "fresh" the typical model is relative to the mass of the distribution.

6. Composite scoring: momentum_score

A weighted score on a 0–100 scale combining three inputs:

Weights sum to 1.0. Observed output: min 0.1833, median 24.63, mean 23.64, max 86.55, stdev 7.936.

Observations on this construction:

• The three inputs are on incommensurable scales as listed — downloads_30d spans 8.086e5–2.392e8, likes spans 0–13,560, and freshness_index spans 0–1. Unless the scoring step internally rescales each input, the two raw-count terms would numerically swamp the normalised one. The output's tight distribution (stdev 7.936 on a 0–100 scale, mean ≈ median ≈ 24) is consistent with internal per-input normalisation followed by weighting, but the profile does not document that normalisation, so the score's exact semantics are not recoverable from the recorded steps alone.
• The near-coincidence of mean (23.64) and median (24.63) makes momentum_score the most symmetric of the derived metrics — notably more so than any of its skewed inputs, which is further evidence of internal rank- or range-based rescaling.
• freshness_index is itself a min–max normalisation of days_since_update, and days_since_update also drives maintenance_class and is_stale. Three of the derived fields are therefore functions of the same underlying timestamp, and 30% of the momentum score is that single variable.

7. Binned classification: maintenance_class

days_since_update is discretised into four ordered, left-open/right-closed bins with default: unknown:

All 500 rows were assigned to one of the four substantive labels; the unknown default was never used, consistent with days_since_update being 500/500 non-null. The distribution is fairly even across the three older tiers, with active the smallest class. The cut points (90 / 365 / 730 days) are conventional calendar thresholds imposed externally, not data-driven breakpoints.

8. Threshold flag: is_stale

is_stale = days_since_update > 365. Result: 281 True (56.2%), 219 False (43.8%).

This is a strict recomputation of the classification boundary: is_stale must equal maintenance_class ∈ {dormant, abandoned}. Checking the counts — 141 + 140 = 281 — confirms exact agreement, and active + maintained = 86 + 133 = 219 matches the False count. The flag is fully redundant with maintenance_class and carries no independent information.

9. Validation

A terminal validate step closes the pipeline. Its assertions are not enumerated in the profile, so the checks it performed — and whether it would have caught the days_since_update > days_since_launch inconsistency or the future-dated last_modified value — cannot be determined from the recorded metadata.

Limitations

Coverage and missingness

• task is missing for 46/500 rows (9.2%) and library for 29/500 (5.8%). Neither was imputed nor excluded, so any breakdown by task or library covers only 454 and 471 models respectively. No missingness mechanism was investigated; if absence correlates with model type, such breakdowns are biased.
• downloads_per_like is null for 6 models with zero likes. These are silently dropped from any aggregate over that column, which shifts summaries toward models that have received at least one like.

Selection bias

• downloads_30d has a floor of 808,600 downloads. This is a leaderboard extract of already-popular models, not a sample of the Hub. Every statistic here describes the high-adoption tail; nothing supports inference about typical Hub models, and the "abandoned" share (28%) reflects abandonment among successful models only.
• The 500 rows represent only 162 authors with heavy concentration (Qwen alone contributes 15.8% of rows). Row-level averages are effectively weighted toward a few prolific organisations.

Distributional assumptions

• adoption_zscore applies a mean/standard-deviation standardisation to a distribution with a max at 17.4σ and a min at only -0.26σ. Z-scores presuppose roughly symmetric spread; here they do not discriminate among the bulk of models. The same concern applies to reporting means for downloads_30d, downloads_per_like and downloads_per_day, where the mean sits far above the median in every case.
• freshness_index and the momentum score inherit sample-relative endpoints. Neither is comparable across different snapshots or differently-composed datasets.

Metric construction

• downloads_per_day mixes a 30-day numerator with a lifetime denominator and is not a valid rate; it is structurally biased against older models.
• momentum_score weights are asserted, not calibrated — there is no stated criterion the 0.5 / 0.2 / 0.3 split optimises, and no sensitivity analysis. The internal rescaling that makes the three inputs commensurable is undocumented, so the score is not independently reproducible from this specification.
• Three derived fields (freshness_index, maintenance_class, is_stale) and 30% of momentum_score all reduce to days_since_update. This is redundancy rather than triangulation, and it makes the pipeline's conclusions sensitive to the quality of that one field.

Data integrity

• days_since_update reaches 1911 days while days_since_launch maxes at 1622, an ordering violation that propagates into freshness_index, maintenance_class, is_stale and momentum_score.
• A last_modified value of 2026-07-21 implies either a future-dated repository or a reference-date mismatch; days_since_update has min = 0, so the pipeline's "today" anchor is itself undocumented and the whole recency family is only interpretable relative to an unstated extraction date.
• 95 rows (19%) share one of two adjacent 2022-03-02T23:29:0Xz creation timestamps, almost certainly a migration artefact. days_since_launch — and therefore downloads_per_day — is unreliable for those models.

Scope

• All quantities are cross-sectional from a single snapshot. Despite the name, momentum_score measures no change over time; there is no second observation period, so no trend, growth or velocity claim is supported.
• Bin thresholds (90/365/730) and the staleness cutoff (365) are conventions. Reported class shares would move substantially under different cut points, and no robustness check across alternative thresholds was performed.