← Back

Method & status

What sets this service apart from a directory is that every field carries evidence. These are the rules we never bend.

Status discipline

• Confirmed — verified against a primary source, with source link and date. Technical/product facts on the provider's own site (API, pricing, models) qualify here.
• Self-reported — the provider's own word (site, docs, press release, llms.txt), not verified against a register or binding document. All sovereignty and compliance marketing starts here. The status value in the data is claimed; until August 2026 it was displayed as "Claimed".
• Planned — a stated goal or "coming soon". Never conflated with achieved. Certifications are marked achieved vs. planned — that distinction is decision-critical.
• Unknown — not researched yet. Reported honestly; we never guess. A wrong "confirmed" is worse than an honest "unknown".

Selection criteria — why these providers

The register is organised into four layers — what you actually buy: (1)inference APIs (the core comparison: they host models and sell a token API — Swedish ones like Berget and grunden.ai AND European ones like Mistral and Scaleway, with jurisdiction honestly stated per field), (2) AI gateways/routers that route to others' models (Opper), (3) assistant platforms procured as finished products (Intric), and (4) compute/GPU where you run the model yourself (Glesys, Aixia, Mimer). Swedish versus European is thus not a category — it is the jurisdiction axis, shown as a tag and a filter. Pure consultancies, resellers without their own operations and products without public information are not included. Providers whose identity or category is contested are clearly marked and excluded from requirement answers until resolved.

Who verifies

The database is built and maintained by Gustaf Baltsar Garnow within the OpenSverige community, on a non-profit basis and with no ties to any provider — no affiliate links, no sponsored placement (see About). Corrections with a source are accepted on an ongoing basis via the community's Discord; providers can upgrade claimed to confirmed by submitting binding documentation (DPA, certificate, price list).

How a verification works

Every data point goes through the same chain: (1) the primary source is read — the provider's own documentation, pricing page or legal terms, never secondary sources for confirmed; (2) the value is classified according to the status discipline above — technical product facts on the provider's own page can become confirmed directly, while sovereignty and compliance statements remain claimed until verified against binding documents; (3) source and date are stored on the field, not on the page — every individual data point can be traced; (4) contradictions are flagged — if a new scrape conflicts with a manually verified value, nothing is overwritten; the record goes into the review queue and is resolved by hand. A false "confirmed" is worse than an honest "unknown".

Verification policy — sustainable without lowering the bar

Fields fall into three classes with different verification paths. (1) Automatic fields — prices, model catalogues, currency — are corroborated weekly by the scraper against the provider's public pages, and daily against public model APIs where the provider exposes one. (2) Document fields — DPA clauses, terms — are read once against the binding document and re-examined when the document changes. (3) Artifact fields — certifications, ownership chains — require opened artifacts: for a certificate, the certificate number, accredited certification body, validity period and scope, for the legal entity selling the service. Here the burden of proof sits with the provider: we do not chase artifacts, we read the ones submitted. Verification is event-driven — a provider submits evidence, the community reports, or a claim becomes publicly contested — never sweeping. The bar is the same for everyone; who climbs it is up to each provider. Confirmed certificates carry validity dates and are flagged automatically in the review queue before expiry.

Ownership and jurisdiction — what confirmed requires

The jurisdiction verdict is the most consequential data point on this site, and it follows the ownership and control chain — not the data centre's address. Chains are evidenced link by link from registered documents: group notes in annual accounts, prospectuses and offer documents, major-holdings notifications, and foreign company registers (Brønnøysundregistrene, ariregister.rik.ee, Handelsregister, KVK, RCS/Sirene, SEC). Note that Sweden has no public shareholder register — the Companies Registration Office registers companies, not owners, and share registers in private companies are not public. An extract from a register mirror such as allabolag therefore evidences the entity, never the ownership. A single undisclosed level leaves the verdict unproven, however likely it may be.

The evidence ladder has three classes. Registers — documents that actually disclose ownership (the classes above); the only path to a confirmed verdict. Contractual — a binding clause in a DPA or terms; stronger than marketing because breach carries sanction, but still the provider's own declaration. Self-reported — everything else from the provider itself: site, documentation, press releases (including newswire distribution) and machine-readable metadata such as llms.txt. Do publish an llms.txt — we read it, and agents read it; it is a welcome transparency commitment. But a declaration is an intake, never evidence, and it is classed as self-reported even when it speaks against the provider. The ladder applies symmetrically: a verdict that a provider is exposed requires evidence as good as a verdict that it is not — an unfounded accusation is the worst failure of all.

How to read the interface: a green label with "chain proven" means the entire ownership chain to the ultimate parent is evidenced in registers — it is the only green, and it is not granted on trust. A grey label with (contractual) or (self-reported) means the verdict rests on the provider's own declaration. Rust and amber require evidenced exposure or transfer. The "Entity on record" badge and the link counter ("links 2/3") are metadata — they show how far the evidence reaches, but never colour the verdict. A false "confirmed" is worse than an honest "unknown".

What a proven chain does not prove: US access laws follow control, not just ownership. US subsidiaries within the group, US sub-processors in operations and US establishments can create an access nexus even under a fully European ownership chain. That is why the verdict is called "chain proven" — never "CLOUD Act free" — and the sub-processor chain is read as its own field.

Register monitoring: an automated module checks weekly that the providers' legal entities exist, are active and carry the right name — against Brønnøysundregistrene, the French Sirene and further registers as free lookups are verified. It corroborates and fills unknowns but never changes a status itself: deviations (bankruptcy, compulsory dissolution, name changes) go to the review queue and are decided by hand. Ownership data ages more quietly than certificates — companies change hands without anything expiring — so ownership fields are re-examined on public events (takeover bids, bankruptcy) and once they are older than a year. In the source review of 2026-08-06, 22 data points were downgraded when the ladder was introduced; that no provider currently holds a confirmed freedom verdict is not a judgement about the market but an honest measure of how much of the ownership picture is evidenced in registers.

Are you a provider and want a data point confirmed?

We never change a status on request — but we are happy to read evidence: publish the document at a public URL on your own domain and post the link in our Discord. The full process, and what counts as evidence per field type, is on the page for providers.

Data sources & scraping

The foundation is manually verified facts (source + date per field). On top of it, an automatic re-scrape of the providers' public pages runs every week, and providers exposing a public model API are checked daily against it: the catalogue diff flags new and removed models for review, and API prices corroborate the pricing pages. The page scrape runs under strict fetch discipline: robots.txt and machine-readable TDM reservations (tdmrep, noai) are respected by all fetch engines, an identifying User-Agent, rate limiting, ungated content only. Under-rendered pages are escalated to a rendering fetch, and known pricing views that require interaction (tabs that load on click) are fetched by a headless browser that the pipeline drives — the same robots rules apply to it too. Which engine fetched what is logged in the raw data, so the fetch itself has provenance too. The scrape replaces earlier observations of the same field — it never accumulates the sources' material. The scraper may only corroborate existing values or fill fields that stand as unknown — it may never silently change a verified value. The detectors are deterministic (patterns, not AI guesses), and their findings are reviewed against evidence excerpts before they become facts.

Freshness & change history

Every run is diffed against the previous one. Changed fields are logged with a date and shown openly in the change history (also as JSON). That history — who changed what, and when — is the part no answer engine can replicate by re-scraping today, and it means a claim can always be traced back in time.

Open data

The entire comparison dataset is free to cite and reuse with attribution (CC-BY-4.0): machine-readable via the JSON API, llms.txt and llms-full.txt. Please cite with status and verification date — "claimed" is not "confirmed".