Dimension 4 — Namespace provenance (15 points)

Assesses the trustworthiness of the model's origin. The dimension was promoted to actual scoring in v0.4 — earlier methodology versions ran the namespace audit in observability-only mode while empirical data accumulated. The promotion reflects that the recon corpus now provides enough population baseline data to lock the rubric.

The full point ladder, written out so a reader can see exactly what their score is composed of:

Why a step function and not a smooth curve. Namespace age is the single load-bearing signal in this dimension and the curve had to be picked between two reasonable approaches: a smooth function (e.g. a logarithm of days-since-account-created) or a step function with explicit cliff edges. The smooth function gives finer resolution but is harder to publish — a methodology page that says "the score is a logarithm" is less actionable than one that says "accounts older than 180 days score 11; accounts under 7 days score 0". Dokima picked the step function so that a model author who reads the methodology can predict the score they will receive without running the calculator. The cliff edges are a deliberate trade against resolution.

Why verified is bonus-only and never a penalty. Hugging Face's verification badge applies to roughly 3 percent of the namespaces in the recon corpus. Many legitimate model authors are not verified, including the author of this scoring tool. If verified-status were a points deduction for unverified accounts, the dimension would penalise the overwhelming majority of legitimate authors for not having walked through whatever HF's verification process is. Bonus-only avoids that trap.

HF verification criteria are not publicly documented. Hugging Face does not publish what a namespace must do to qualify for the isVerified badge, and the criteria appear to evolve. Dokima awards the +3 bonus regardless because verification represents real effort by HF to vet the namespace — even an opaque-criteria signal carries information about who HF themselves decided to flag. If HF publishes the verification criteria in the future, Dokima will revisit whether the bonus is the correct mechanic or whether a more granular rubric becomes possible. Until then, the honest stance is to credit the badge while disclosing that we do not know what it means in detail.

Model count is observability-only. Earlier drafts of this rubric proposed a tiered scoring rule based on the number of models a namespace has uploaded — the intuition being that prolific authors are more trustworthy than one-off accounts. The April 2026 1000-model recon found that model count alone does not separate prolific legitimate authors from quant farms (namespaces that bulk-upload re-quantised copies of other people's models). Without a way to distinguish the two cases, scoring on count would punish low-volume legitimate authors. The model count is surfaced via a UnknownHighVolume drift flag for namespaces above 500 models that are not on the curated quant-chef allow-list, but the flag does not contribute to the score in v0.4. The signal is captured for future calibration; the scoring rule is held until the data tells us how to use it.

Author-controlled access (the gated bonus). A namespace that ships a model with gated: manual (each access request is reviewed by a human) or gated: auto (auto-approved on terms acceptance) is doing something a freely-distributed namespace is not — the author has set up a friction layer that signals they care about who downloads the weights. Both gating tiers earn the same +1 bonus because the underlying signal (author-controlled access) is the same; the difference between manual and auto review is operational, not provenance.

The max-only severity-penalty mapping. The hijacking-signature heuristic in the private detection layer can fire multiple observations on the same model. Earlier proposals additively summed the penalties — a model with one HIGH and three LOW observations would lose 11 points (8 + 3). The April 2026 recon showed this produces score collapses in the noisy long-tail without proportionate additional information: a model with three LOW observations is not three times more concerning than a model with one. Dokima locked the max-only rule: whichever single observation has the highest severity contributes the penalty; lower-severity observations are still recorded as drift flags for transparency but do not stack onto the score. The ceiling on a single hijacking penalty is therefore -8 points (HIGH); a clean namespace with no observations loses no points. The dimension floors at zero — penalties cannot drive Dim 4 negative.

Metadata-consistency confidence step-down. A model can publish the same fact in two places — once as a Hugging Face tag (library_name, pipeline_tag, license, dataset) and once in the structured cardData block of the model card. When the two disagree, Dokima cannot decide which the author intended; the audit could fire either way. Rather than guess, the dimension records a TagVsCardData drift flag and steps the namespace-audit confidence down by 0.05 per non-hijacking drift flag observed (clamped at a 0.3 floor so even a model with many drift flags still carries a non-zero confidence). The points are unchanged; only the confidence label on the dimension changes. This surfaces metadata inconsistency to the reader as a calibrated uncertainty signal rather than letting a Dim 4 verdict carry default confidence while three different drift flags disclaim three different shape-level issues. The step is intentionally small (5 percentage points per flag) so that a single benign drift does not collapse the confidence, while a model that has accumulated five or more drift flags lands at the 0.3 floor — a strong reader-visible signal that the model's published metadata is too inconsistent for the audit to speak with confidence. Authors keep full confidence by ensuring tag values and the matching cardData fields agree.

The three monitored hijacking signature classes. The exact signature implementations live in the private detection layer (the open-core split — see Coverage disclosure), but the categories of behaviour Dokima watches for are public:

1. Sudden file-format regressions. A namespace that has only ever shipped SafeTensors weights suddenly pushes a .bin or .pkl file. This is the canonical signature for an account compromise: the new owner uses the existing trust to ship something the original author would not have shipped.
2. Dormant-then-active patterns. A namespace inactive for many months that suddenly resumes uploads, especially if the resumption coincides with file-format regressions or a sudden change in model topic. This is the canonical signature for a re-registered deleted account (Hugging Face permits username re-registration after a deletion grace period; an attacker can claim a previously-deleted username with established trust).
3. First-ever-pickle uploads. A namespace whose entire history has avoided pickle-format weights pushes its first pickle. Distinct from the file-format regression case because it can fire on a long-tenured pickle-free namespace even without the dormant-then-active pattern.

Dokima publishes the categories so consumers know what kinds of provenance threats the dimension is checking for; the specific detection implementations stay private so the heuristic cannot be route-around-tested by adversaries. The tradeoff is intentional: trust requires knowing what the dimension watches; defensive value requires not publishing the exact watch points. Cross-references Palo Alto Networks Unit 42 namespace-hijacking research and Hugging Face's documented absence of mandatory two-factor authentication on author accounts.