Methodology v1

How every grade in this registry is produced. The scoring code is score.py; it reads the same public JSON the site serves, so any grade here can be recomputed from published data.

Two rules govern everything below.

Judgment lives in the fields, not in the score. Each row records a set of structured facts, each with an evidence URL, a claim basis (stated if the vendor says it in writing, inferred if we concluded it) and a confidence. Scoring is then arithmetic. Nobody assigns a grade; the grade falls out.

Missing evidence scores zero. Structural non-applicability renormalises. These are different things and conflating them is how sovereignty scores get gamed. If a vendor does not disclose its subprocessors, that is a zero — silence is a finding, not a blank. If a vendor ships open weights you run on your own hardware, it has no subprocessors in your data path, and the component is dropped from that row's denominator instead. The first is a choice the vendor made; the second is a property of the delivery model.

Relationship to the EU Cloud Sovereignty Framework

In June 2026 the European Commission published its Cloud Sovereignty Framework — 48 criteria across 8 sovereignty objectives (SOV-1…SOV-8), plus a SEAL rating (Sovereignty Effectiveness Assurance Level, 0–4) computed as the lowest level reached on any objective. It was used to award a €180M sovereign-cloud contract to four providers in April 2026 at a minimum of SEAL-2.

Our components map onto its objectives:

We publish a per-row SOV-2 and SOV-3 rating on the Commission's 0–4 scale, using its own weakest-link rule, because those are the two objectives answerable from public evidence.

These are our assessments against the Commission's published criteria. They are not official SEAL ratings. An actual SEAL rating is assigned by a contracting authority on the basis of a bidder's submission and supporting documents. No vendor has submitted anything to us.

We deliberately do not publish an overall SEAL. Three reasons:

1. It does not discriminate. Weakest-link across eight objectives collapses almost every AI vendor to SEAL-0 or SEAL-1 — US providers on extraterritorial law, EU providers on non-EU silicon in SOV-5/SOV-6. A registry where every row reads the same value ranks nothing. The Commission says as much in its own lessons learnt: SEAL-4 is "not today relevant", and relaxing it "would allow to make more difference between providers."
2. Unanswered criteria silently don't count. The official calculator takes the minimum over answered rows. That is correct for a tender, where bidders must answer. Applied to public evidence it inverts: the less a vendor discloses, the better it scores. Our zero-for-missing rule exists to close exactly this hole.
3. It is a cloud-procurement instrument. Its technical dimensions are compute, storage, network, security, IAM and PaaS; AI is SOV-3 alone, five questions at 10% weight. Adopted wholesale it would make an AI registry 90% about cloud infrastructure.

We took the vocabulary, the objective structure, the weakest-link idea and the per-objective normalisation. We did not take the parts built for a procurement process we are not running.

The six components

1 — Jurisdictional exposure (25)

Which state can compel access, and under what instrument.

Jurisdiction follows the data path, not the passport. gov_access_exposure records who can compel access to data the delivery model actually exposes. A deployment with no vendor-side data flow — on-prem, air-gapped, self-hosted weights, with structurally no subprocessors and customer-controlled retention — rates none-eu regardless of where the vendor is incorporated: there is nothing vendor-held to compel. This is the same rule that gives self-hosted DeepSeek R1 no PRC data path, applied consistently to every vendor.

gov_access_exposure: none-eu 15 · mixed 8 · us-cloud-act 4 · prc 0 · unrecorded 0. transfer_mechanism: intra-eu 10 · adequacy-decision 8 · sccs+dpf 5 · sccs 4 · none-stated 0 · unrecorded 0.

adequacy-decision covers third countries the Commission has found adequate — Switzerland and the UK. It sits above SCCs because the assessment was made by the Commission rather than by the parties, and no supplementary measures are required of either side; it sits below intra-eu because an adequacy finding is a decision about a foreign legal order and can be withdrawn.

2 — Data control (25)

Whether your inputs train the model, persist, or leave the EU.

training_default: never 9 · opt-out-clear 5 · trains-deidentified 3 · opt-out-buried 2 · trains by default 0.

trains-deidentified is for a vendor that trains its own models on customer content it has de-identified itself. It scores below opt-out-clear for two reasons that are stated in the vendors' own policies: the de-identification is the vendor's claim and no third party audits it, and once the content is in the weights the contribution cannot be withdrawn. It scores above opt-out-buried because the practice is disclosed plainly rather than hidden in a sub-clause. A vendor that promises third parties will not train on your data, and then trains in-house on derivatives of the same material, belongs here rather than at never. zero_retention_available: yes 6 · no 1 · unrecorded 0. residency_class: customer-controlled / eu-only 10 · eea-adequate-only 9 · eu-default 8 · eu-selectable 6 · eu-via-third-party 4 · non-eu-only / prc-only 0.

eu-selectable scores below eu-only on purpose: a provider where EU residency is one region among many is a configuration you can get wrong, not a guarantee.

eea-adequate-only is for providers whose residency is confined to a third country covered by an adequacy decision — in practice Switzerland. Until v1.2 the enum had no such value, which forced a Swiss-only provider into non-eu-only and scored it zero alongside a US-only one. That was wrong: a Swiss data centre operated under Swiss law by a Swiss company carries neither CLOUD Act nor PRC exposure, and the Commission has assessed the regime as adequate. It scores 9 rather than 10 because the data does leave the Union.

3 — Operational independence & exit (20)

Exit cost, not where the boxes are. A hosted service in Gravelines is not lock-in; a proprietary API you cannot leave is lock-in wherever it runs.

portability_class: open-weights-permissive 12 · open-weights-restricted 9 · serves-open-models 9 · open-api-standard 5 · proprietary-only 2. deployment: air-gapped / on-prem / self-hosted-weights 8 · vpc 5 · hosted with a published self-host path 5 · hosted only 2.

4 — Supply chain (10)

The substance of the chain, not the length of the list. A long, honest subprocessor list beats an empty one, so this must never be scored on count.

Vertically integrated within the EU 10 · all subprocessors EU 9 · mixed 6 · non-EU 4 · undisclosed 0 · structurally none N/A.

5 — Security & compliance (10)

Certifications (ISO 27001 3, SOC 2 Type II 2, ISO 42001 1, an EU-specific scheme such as HDS/C5/SecNumCloud/EUCS 2, capped at 7) plus dpa_available: yes 3. The DPA field is tri-state: structurally-na marks delivery models where there is no processor to sign with — open weights on your own hardware — which is not the same thing as a vendor without a DPA.

N/A where the vendor operates no service in your data path — with open weights on your own infrastructure, their SOC is not in the path.

6 — Evidence quality (10)

The anti-opacity term, and the one component that is about us rather than the vendor. Four claims — training, residency, retention, subprocessors — at 2.5 points each, scored on how well each is evidenced: stated + high confidence 2.5 · stated + medium 1.75 · stated + low 1.0 · inferred + high 1.5 · inferred + medium 1.0 · inferred + low 0.5 · no evidence URL 0.

A vendor that documents a mediocre policy clearly outranks one that documents nothing, and no row can reach the top of the scale on our inference alone.

Grades

A ≥85 · A- 80–84 · B+ 75–79 · B 70–74 · B- 65–69 · C+ 55–64 · C 45–54 · D 30–44 · F <30.

Scores are round(earned / applicable × 100), where applicable excludes components marked N/A for that row.

Known sharp edges

We would rather state these than have them found.

• N/A renormalisation is the biggest single lever. A row with two N/A components is scored out of 80, which is worth up to ~18 points versus scoring zero on both. It is gated on deployment, a verifiable recorded fact, but it is the part of the rubric most worth attacking.
• Self-hosted DeepSeek R1 scores 93, among the highest in the registry. This is not a bug. On every axis this registry measures — jurisdiction, data control, exit, supply chain — MIT-licensed weights running on your own EU hardware have no PRC data path. The DeepSeek app and hosted API scores 24 (F). If those two facts together look wrong, the disagreement is about model provenance and training-data legality, which this registry does not score. See below.
• We do not score model provenance, training-data legality, model safety, or output quality. This is a governance and data-path registry. A high grade means your data is well governed, not that the model is good or its training was lawful.
• eu-via-third-party is a judgment call. Reaching a US-only API through a hyperscaler's EU region is real mitigation, and the contracting entity may even be European (EEA customers of Anthropic contract with Anthropic Ireland, Limited). What the class records is that the vendor's own service offers no EU processing or storage — as of 2026-08 Anthropic's first-party API offers only us/global inference and US-only data at rest. We score it 4/10, above non-EU and below genuine EU selection.
• "Undisclosed" must be earned, not scraped. Two launch rows recorded undisclosed subprocessors that were in fact public — one behind a JS-rendered trust center, one behind a bot-blocking CDN. Both were corrected on 2026-08-03 (Mistral: mixed; xAI: non-eu) and the zero became points. Before we record undisclosed, the page has to have been checked as a browser sees it; a value that punishes opacity has to be sure the opacity is real.

Schema additions required by v1

Three fields the rubric needs that the 44-field schema did not record. They are backfilled by hand for the 16 rows live when v1 shipped and must be collected during the harvest, not retrofitted:

• residency_class — enum above; residency_options is free text and cannot be scored.
• portability_class — enum above; nothing currently records weights licensing or exit path.
• subprocessor_jurisdiction — enum above. Critically, this disambiguates an empty subprocessors list, which today means both "vertically integrated, no third parties" (best case) and "would not say" (worst case).

Version

v1.3, 2026-08-06. One enum value added and one long-standing bug fixed, both forced by the meeting-transcription batch. Both are additive in effect — no previously published grade changed, because no existing row used either value.

• training_default: trains-deidentified (3), new
• training_default: opt-in (0 → 8), corrected

The correction is the more embarrassing of the two and worth stating plainly. opt-in has been in the scoring table since v1 with a value of 0, alongside "trains by default", and was never defined anywhere in this document. Training that happens only on the customer's explicit consent means no training happens by default, which is very nearly never; scoring it the same as a vendor that trains unconditionally was simply wrong. It sits one point below never because the pathway exists and because, on the vendors' own account, content already used in prior training cannot be unwound when consent is withdrawn. No live row had ever used the value, so nothing published moves — the bug was latent until a vendor with a genuinely opt-in policy was graded.

The trigger was a sentence pattern that recurs across an entire category. Four vendors state, in the same document, that they do not authorise third parties to train on customer content and that they train their own models on de-identified derivatives of it. v1.2 had nowhere to put that: never is plainly false, trains ignores a real difference in exposure, and opt-out-clear credits an opt-out that in one case does not exist and in another cannot be applied retroactively, since the vendors themselves state the contribution cannot be removed from a trained model. The scale had a hole in it, in the same way the Switzerland case exposed one in v1.1.

v1.2, 2026-08-04. Two enum values added, both forced by the second harvest batch and both additive — no previously published grade changed, because no existing row used either value.

• transfer_mechanism: adequacy-decision (8)
• residency_class: eea-adequate-only (9)

The trigger was Switzerland. v1.1 was written as though the only two states were "inside the Union" and "a third country relying on SCCs", which left a Swiss-only provider — Swiss law, Swiss data centres, no extraterritorial access regime — scoring zero on residency next to a US-only one. The scale had a hole in it rather than an opinion about Switzerland.

Also worth stating plainly, because the batch made it visible: the rubric rewards structural European-ness heavily enough that a vendor can reach A- on architecture while scoring 4.5/10 on evidence. T-Systems is the live example. The grade is defensible on what is recorded, but a reader comparing it with IONOS at 86 should know the difference is largely that IONOS writes things down.

v1.1, 2026-08-03. Framework decision: hybrid — our grade as the headline, EC objectives as the structure, SOV-2/SOV-3 published alongside.

Changes from v1 (same day): the data-path jurisdiction rule made explicit; dpa_available went tri-state; two undisclosed subprocessor values corrected against newly verified public lists (Mistral, xAI); Nebius re-rated mixed on both jurisdiction and supply chain after its subprocessor list showed a US group entity in the processing chain; platform hosts serving open-weights models classified uniformly (serves-open-models). Six grades moved as a result — the corrections and their evidence URLs are in the change feed.