Das Sovereign Validation Protocol: Die technische Grundlage von CERTavia.
CERTavia basiert auf dem Sovereign Validation Protocol (SOVP), einem Infrastruktur-Validierungs-Framework mit deterministischen Prüfregeln und binärem Ergebnis. Die Spezifikation liegt als IETF Internet-Draft draft-litzki-sovp-04 öffentlich vor, das Verfahren ist als USPTO Provisional Patent Application #64/005,737 angemeldet, die Referenzimplementierung steht unter Apache 2.0 auf GitHub. Diese Seite beschreibt, was geprüft wird, wie das Ergebnis signiert wird und wo die Grenzen des Verfahrens liegen.
Ein Scan dauert im Median zehn Sekunden. Die eigentliche Arbeit steckt darin, jede Prüfregel so festzuschreiben, dass sie nachprüfbar ist.
Regelbasierte Prüfung mit binärem Ergebnis
SOVP löst eine präzise definierte Aufgabe: die technische Infrastruktur einer Domain auf ihre Integrität und Vertrauenswürdigkeit als Datenquelle für KI-Systeme zu prüfen. Das Ergebnis ist binär: SOVP-CERTIFIED oder SOVP-FAILED.
Das Protokoll arbeitet mit deterministischen Prüfregeln. Das Prüfverfahren selbst arbeitet vollständig regelbasiert, ohne probabilistisches Scoring oder KI-Komponente. Regeln und Gewichte sind fest; die Messwerte externer Prüfungen können dennoch zwischen zwei Abrufen schwanken. Beispiel certavia.org: 38 Scans vom 06.08. bis 12.10.2026, alle CERTIFIED, CES zwischen 77,8 und 97,2. Cluster A wechselte von Tag zu Tag zwischen 95 und 100. Ein Scan dokumentiert deshalb einen datierten Zustand.
Das Protokoll arbeitet auf Layer-0-Ebene: der Infrastruktur-Schicht, die dem Content, der Autorenschaft und jedem weiteren Signal vorgelagert ist. Auf dieser Ebene entscheiden KI-Systeme und Agentic Pipelines, welche Domains als vertrauenswürdige Datenquellen behandelt werden.
80+ Parameter in 6 Clustern A–F
CERTavia führt 87 Prüfungen in 6 Clustern A–F aus: 79 fließen in die Bewertung ein, 8 sind Bonusprüfungen. Das SOVP-Protokoll umfasst 180+ Parameter in 20 Clustern; 53 davon ohne Compliance-Bezug sind ausdrücklich ausgeschlossen. Vier Prüfbereiche im Überblick:
DNS und kryptografische Grundintegrität
DNSSEC-Konfiguration, CAA-Records, TLS-Zertifikatskette, Zertifikats-Transparenz, HTTP-Sicherheitsheader (HSTS, CSP, X-Frame-Options, X-Content-Type-Options), SPF, DKIM und DMARC. Diese Basis-Hygiene ist Sicherheitskontext (NIS2, DORA), keine Pflicht aus Art. 50 EU AI Act.
Datenschutz & Consent
Crawler-Direktiven in robots.txt, Konsistenz der Opt-In- und Opt-Out-Deklarationen für alle relevanten KI-Crawler (GPTBot, ClaudeBot, Google-Extended, CCBot, Anthropic-ai und weitere), WAF-Response-Konsistenz, Consent Declaration Integrity.
Maschinenlesbare Identität und Authorship
Strukturierte Daten nach Schema.org, kanonische Entitätsdeklaration, AI-Discovery-Layer (ai.txt, ai.json, llms.txt, llms-full.txt), maschinenlesbare Authorship-Signale, agent-card.json, WebMCP-Konfiguration, API-Catalog nach RFC 9727: Link Relation Types for Web APIs, JWKS-Endpoint, RFC 8615: Well-Known Uniform Resource Identifiers und HTTP-Message-Signatures-Directory. Die Ebene, auf der eine Domain ihre Identität gegenüber KI-Systemen und Agentic Pipelines maschinenlesbar deklariert.
AI Governance Hard Gate
Sechs Kernprüfungen an /.well-known/ai-disclosure.json (Systemoffenlegung, menschliche Aufsicht, Annex-III-Einstufung, Data Governance, technische Dokumentation, Incident Reporting), dazu Bonuspunkte für KI-Abschnitt in der Datenschutzerklärung, KI-Bot-Gruppen in robots.txt, Opt-out-Hinweis, AI-Policy-Seite, Deepfake-Disclaimer und KI-Kontaktstelle. Ohne ai-disclosure.json ist Cluster F rechnerisch 0 und CERTIFIED ausgeschlossen. Widersprüche zwischen diesen Signalen erkennt der Scan nicht. Diese öffentlich sichtbaren Deklarationen können als technischer Beleg zur Art.-50-Dokumentation beitragen. Welche Pflicht aus welchem Absatz folgt, steht im Glossar unter Art. 50 Abs. 1–4.
Ed25519, DNS-verankert, unabhängig verifizierbar
Jedes SOVP-Zertifikat trägt eine Ed25519-Signatur über das nach RFC 8785 (JSON Canonicalization Scheme) kanonisierte JSON des Ergebnisses. Ed25519 ist ein elliptisches Kurven-Signaturverfahren, das für hohe Sicherheit bei gleichzeitig kompakter Schlüsselgröße bekannt ist und von der IETF in RFC 8032: Edwards-Curve Digital Signature Algorithm spezifiziert ist. Für DNSSEC-Anwendungen gilt zusätzlich RFC 8080: Edwards-Curve Digital Signature Algorithm for DNSSEC.
Die Signatur ist DNS-verankert: Der öffentliche Schlüssel steht als DNS-TXT-Record unter _sovp.certavia.org, und jede Attestierung verweist darauf (public_key_ref: dns:txt:_sovp.certavia.org). Jeder externe Prüfer kann die Signatur unabhängig verifizieren, ohne Zugang zu den internen Systemen von CERTavia oder Litzki Systems LLC zu benötigen.
Im Basic-Paket ist der Nachweis 90 Tage gültig, der Vault-Eintrag läuft danach ab. Ab Pro gilt das Urteil 365 Tage, der Vault-Eintrag bleibt dauerhaft abrufbar. Berichte werden automatisch erzeugt, signiert und im Vault abgelegt; eine manuelle Freigabe gibt es nicht. Der Vault-Link ist eine maschinenlesbare Verifikations-URL, z. B. cv_b5d1baaa2a4edfc2 für litzki-systems.com (CES 97,9, Scan 08.09.2026).
draft-litzki-sovp: Formelle Protokollspezifikation beim IETF
Das Sovereign Validation Protocol ist als IETF Internet-Draft unter dem Bezeichner draft-litzki-sovp im IETF Datatracker veröffentlicht (aktuelle Revision -04, Stand 7. Oktober 2026). Der Draft enthält die vollständige technische Spezifikation des Protokolls: Parameterdefinitionen, Cluster-Architektur, Signaturverfahren, DNS-Verankerung und das binäre Ergebnis-Framework.
Ein Internet-Draft ist ein öffentliches Arbeitsdokument, kein IETF-Standard und keine Empfehlung der IETF. Er macht die Spezifikation einsehbar und versioniert. Beschrieben sind das signierte Identitätsdokument, seine Kanonisierung, die Ed25519-Prüfung gegen einen DNS-TXT-Schlüssel und die Abrufregeln. Die Prüfparameter und Cluster des CERTavia-Scans legt der Draft nicht fest.
USPTO Provisional Patent Application #64/005,737
Das Sovereign Validation Protocol ist durch eine provisorische Patentanmeldung beim USPTO – United States Patent and Trademark Office unter der Nummer 64/005,737 angemeldet (Patent pending). Eine Provisional Application sichert das Prioritätsdatum; ein erteiltes Patent ist sie nicht.
Erfinder und Anmelder ist Thorsten Litzki. Die Anmeldung ist in Litzki Systems LLC, St. Petersburg, Florida, USA eingetragen.
Die Entstehungsgeschichte des Protokolls, vom gewichteten SEO-Audit-Katalog bis zum aktiven IETF-Draft, beschreibt Thorsten Litzki hier: Warum ich aufhörte, Websites zu optimieren, und anfing, ein Protokoll zu spezifizieren →
sovp-python: Apache 2.0 auf GitHub
Die Python-Referenzimplementierung des Sovereign Validation Protocol ist unter der Apache-2.0-Lizenz auf GitHub öffentlich verfügbar. Das Repository enthält die vollständige Implementierung der Prüfparameter, die Cluster-Architektur und das Signaturverfahren.
Die Veröffentlichung unter Apache 2.0 ermöglicht IT-Teams und Sicherheitsforschern, das Protokoll unabhängig zu evaluieren, in eigene Systeme zu integrieren und zur Weiterentwicklung beizutragen. Damit lässt sich nachvollziehen, ob ein Befund aus dem Scan aus der Spezifikation folgt.
Was SOVP von anderen Ansätzen unterscheidet
SOVP beantwortet eine andere Frage als Werkzeuge, die die Sichtbarkeit einer Domain in KI-Antworten messen.
Probabilistische Scoring-Systeme messen die Sichtbarkeit einer Domain in KI-Systemen. Sie geben an, wie häufig eine Domain in LLM-Ausgaben erscheint und wie stabil diese Sichtbarkeit ist. Das ist eine rückwärtsgewandte Messung eines Zustands.
SOVP misst die Infrastruktur-Voraussetzungen, die diesen Zustand erzeugen. Das ist eine vorwärtsgewandte Prüfung der Bedingungen, unter denen eine Domain als vertrauenswürdige Quelle ingested wird. Das Ergebnis ist binär und folgt festen Regeln, unabhängig von den Schwankungen einzelner LLM-Ausgaben.
Dazu kommt: Die Spezifikation ist als Internet-Draft öffentlich, die Referenzimplementierung quelloffen, und jedes Ergebnis ist signiert. Ein Befund lässt sich damit gegen die Regel prüfen, aus der er stammt.
Aktiver Schutz des Protokolls
Litzki Systems LLC verfolgt aktiv den Schutz der geistigen Eigentumsrechte am Sovereign Validation Protocol. Ein IPR Disclosure beim IETF (Disclosure ID 7291 und 7294) dokumentiert die Eigentumsrechte am Protokoll gegenüber der IETF.
Bei Anzeichen auf missbräuchliche Verwendung des Protokollnamens oder auf Nachahmungsprodukte, die das SOVP-Framework ohne Lizenz einsetzen, leitet Litzki Systems LLC die rechtlich verfügbaren Schritte ein.
567 Benchmark-Messungen, keine davon CERTIFIED
Die CERTavia-Engine hat 10 Branchenlisten gemessen, darunter DAX-Konzerne, BaFin-regulierte Institute, Behörden und Online-Händler. Bei den Juni-Läufen (11.–18.06.2026) wertete der Scanner Cluster A wegen eines Rate-Limits teils als 0 statt als nicht gemessen. Betroffene CES-Werte liegen dadurch zu niedrig; Details im Korrekturhinweis.
Höchster gemessener Einzelwert aller Juni-Messungen: 55,1. Für KRITIS50, B2B-ECOMMERCE30 und DACH-PUBLISHER40 nennen wir bis zu einer Neumessung keine Werte.
Weiterführende Seiten
Die regulatorischen Anforderungen, auf die SOVP die technische Antwort liefert.
Annex III — Hochrisiko-KI im Detail →Hochrisiko-Klassifikation und technische Nachweisanforderungen.
NIS2 und DORA: Regulatorische Schnittmengen →Wie SOVP-Parameter NIS2- und DORA-Anforderungen adressieren.
CERTavia für IT-Leiter und CTOs →API-Integration, CI/CD-Workflows und technische Evaluationsgrundlagen.
Fragen zur SOVP-Technologie
Gibt es eine API-Dokumentation?
Ja. Die SOVP-Engine ist über eine REST-API erreichbar und unterstützt MCP (Model Context Protocol) für die Integration in KI-Agenten und automatisierte Compliance-Workflows. API-Dokumentation und Zugangsdaten sind im Enterprise-Paket enthalten. API-Zugang anfragen →
Was passiert, wenn sich meine Infrastruktur ändert?
Ein SOVP-Scan ist eine Momentaufnahme. Bei Infrastrukturänderungen (neue TLS-Konfigurationen, DNS-Änderungen, Zertifikatserneuerungen) empfehlen wir einen neuen Scan. Die Bewertungsregeln sind fest, die Messwerte externer Prüfungen können zwischen zwei Abrufen schwanken: litzki-systems.com erreichte am 13.10.2026 innerhalb einer Stunde CES 97,6 und 99,0 (Cluster B 88 und 95). Ein Scan dokumentiert einen datierten Zustand.
Was ist der Unterschied zu einem Pentest?
Ein Pentest sucht aktiv und manuell nach Angriffsflächen. SOVP prüft passiv die öffentlich sichtbare Infrastrukturkonfiguration nach festen Regeln gegen einen definierten Anforderungskatalog, automatisierbar. Beides schließt sich nicht aus.
Das Protokoll in der Praxis erleben
Der kostenfreie Scan liefert das Ergebnis in Sekunden (Median rund 10 Sekunden über 329 Scans bis 13.10.2026): Urteil, CES, alle sechs Cluster mit allen Einzelparametern und Handlungsempfehlungen. PDF-Report, Signatur und Vault-Eintrag sind kostenpflichtig.
CERTavia analysiert technische Infrastruktursignale. Das Ergebnis ist ein maschinenlesbarer Befund, kein Rechtsgutachten und keine Zertifizierung im Sinne der EU AI Act Konformitätsbewertung nach Artikel 43. Für rechtsverbindliche Compliance-Bewertungen wenden Sie sich an eine zugelassene Konformitätsbewertungsstelle.
Das Sovereign Validation Protocol (SOVP) ist als USPTO Provisional Patent Application #64/005,737 angemeldet. Der IETF Internet-Draft draft-litzki-sovp-04 ist ein öffentliches Arbeitsdokument, kein Standard. CERTavia liefert technische Infrastruktur-Validierung. Die Einschätzung regulatorischer Pflichten im Einzelfall obliegt qualifizierten Rechts- und Compliance-Beratern. Die Preisangaben auf verknüpften Seiten sind in EUR und richten sich an gewerbliche Kunden.