SEAL overlay — full text

SEAL — Sovereignty Effectiveness Assurance Level

Auditor-facing companion to SOVEREIGNTY.md. It documents how NeuralRing maps captured evidence onto the EU Commission's Cloud Sovereignty Framework grade (SEAL, levels 0–4 across 8 Sovereignty Objectives), and — more importantly — what that mapping does and does not prove. Read SOVEREIGNTY.md first for Tier (0–3) and the assurance ladder; SEAL is a standards-aligned overlay on top of those, never a replacement.

Implemented in `packages/sovereignty/src/seal.ts`; the mapping is exercised by `seal.test.ts`.

1. What SEAL is here

The EU Cloud Sovereignty Framework scores a cloud/AI service on 8 Sovereignty Objectives (SOV-1…SOV-8), each on a 0–4 ladder, with the overall grade equal to the lowest objective (weakest-link). NeuralRing surfaces SEAL as a familiar, standards-aligned lens on the same sovereignty facts it already tracks — but it refuses to manufacture a grade. Every SEAL value carries one of three kinds, and they are never conflated:

Only `official` + `verified`/`certified` counts toward a hard `min_seal` gate (GET /api/v1/models?min_seal=N, and the routing predicate). Today no provider in the catalog carries an official SEAL, so ?min_seal=N for any N ≥ 1 honestly returns empty — exactly as it should. We do not let an indicative grade unlock a gate the customer asked us to enforce. (`satisfiesMinSeal`)

A stored credential is normalised on ingest (`normalizeSealCredential`): an official value missing a reference or evidence is downgraded to `claimed`, and an indicative/claimed value can never wear certified assurance. An indicative or claimed SEAL therefore cannot serialise in the official shape.

2. The indicative mapping (this IS the spec)

computeIndicativeSeal() reuses the existing disciplines from SOVEREIGNTY.md: evidence-grounding (§3.3), the method-can-verify / overclaim guard (§3.4), and weakest-link composition (§3.6). Indicative sublevels are capped at SEAL-3 — INDICATIVE_CEILING = 3. SEAL-4 is reserved for an official assessment (the framework's own lessons-learnt note SEAL-4 is not attainable today).

2.1 Per-objective derivation

The overclaim guard is the load-bearing rule: registry evidence may raise only SOV-1/SOV-2; a probe only SOV-4; only a scoped location certification raises SOV-3. A verified domicile never silently lifts execution (SOV-3), supply chain (SOV-5) or technology (SOV-6). This is the same guard that prevents an execution-location overclaim in the attestation engine.

The raise/contradict asymmetry (Phase 17, docs/SUPPLY-VERIFICATION-DESIGN §4.2): a method may only raise the objectives it can prove; any captured evidence may contradict any objective it falsifies, always moving conservatively (the SOV-5 non-EU-silicon→0 rule is the existing precedent; a hosting-provenance probe likewise lowers SOV-1/2/3-adjacent posture via a Tier-2 exposure cap when it catches a US front, never raising them). A probe can redden an objective; it can never green one. And a cert's scheme-derived binds gates which objective it may lift — an ISMS/isms or disclosure cert moves SOV-7, never SOV-3 (which needs a location-binding scheme through the human scope lane).

2.2 Composition (overall indicative grade)

1. If any assessed objective is 0 (a substantiated contradiction, e.g.

non-EU silicon) → overall = 0. Weakest link, and a definite failure dominates.

1. Else if ≥ 3 objectives are `unknown` → overall = `null` with

coverageIncomplete = true. We do not grade what we mostly cannot see.

1. Else → overall = the lowest assessed (numeric) objective.

unknownObjectives[] and coverageIncomplete are always surfaced so a reader sees exactly which objectives are dark.

3. Worked example — the GX10 (must NOT be inflated)

The GX10 is a real NVIDIA GB10 box on EU soil, self-operated, keys held locally, liveness probe-verified — but its geography is only self_attested (a LAN probe cannot prove where the rack physically sits) and its silicon is NVIDIA (non-EU). A naive mapping would call it "Tier 0, fully sovereign." The honest indicative SEAL does not:

SOV-1 = unknown   (no registered ultimate parent for a self-operated box)
SOV-2 = 1         (domicile self_attested)
SOV-3 = 1         (key custody / residency self_attested; no scoped cert)
SOV-4 = 2         (conformance probe verified — ceiling)
SOV-5 = 0         (NVIDIA GB10 — known non-EU silicon → contradicted)
SOV-6 = unknown
SOV-7 = unknown   (no certifications)
SOV-8 = unknown
→ overall = 0     (SOV-5 contradiction dominates), coverageIncomplete = true
→ kind = indicative, assurance = self_attested  (Tier 0 ≠ a high SEAL)

Tier 0 and SEAL 0 coexisting is the whole point: tiering answers "is the operating/parent jurisdiction EU and the data in-region?" (yes), while SEAL asks the harder, fuller question "is sovereignty effective across all eight objectives?" — and supply-chain provenance alone sinks the overall grade. The catalog shows this verbatim at GET /api/v1/models/nvidia/Qwen3.6-35B-A3B-NVFP4/endpoints.

4. What a SEAL value here does and does not prove

An `indicative` SEAL proves: NeuralRing applied the documented mapping to the evidence it actually captured, with the overclaim guard and weakest-link composition, and capped the result at SEAL-3. It is a faithful lower bound lens, not a certification.

It does not prove: that the provider passed an official Cloud Sovereignty Framework assessment; that unknown objectives are fine (they are simply unseen); or that an EU domicile implies EU supply chain / technology. Only an `official` SEAL with a verifiable reference proves an actual assessment — and only that can gate routing.

5. API & UI surface

• GET /api/v1/models and …/models/:slug/endpoints carry a seal block:

{ indicative, official?, claimed? }, each credential with per-objective objectiveCoverage, overallLevel, coverageIncomplete, unknownObjectives.

• GET /api/v1/models?min_seal=N filters on official/verified only

(`applyModelFilters` → `satisfiesMinSeal`).

• Research-agent proposals carry an indicative seal block into the review

queue (GET /api/v1/admin/proposals/:id) so a human reviewer sees the mapped grade alongside the evidence — never an official one.

• The model browser renders a SEAL badge that is **amber unless an

official+verified assessment exists* (never green for indicative/claimed), with an expandable SOV-1…SOV-8 breakdown and the disclaimer "indicative — not an official EU SEAL assessment."*

• Phase 30 "The Hallmark" — the SEAL chip obeys the same three-colour code

as the ring badge: indicative/claimed → amber with a dashed border, official+verified → solid blue, official+certified → solid green (the honesty gate is unchanged — only the presentation of the same states). The model-detail SOV-1…8 breakdown is now an ordered objectives chart (name + plain-language question + a 0–4 level mini-bar + method per row); unknown is a neutral/faint "unknown — not assessed" (never a bar at 0), a contradicted objective (level 0) is danger-red, and the weakest-link composition sentence ("overall = lowest assessed objective; ≥3 unknown → no grade") sits under the chart.