Sovereign Validation Protocol: Independent External Verification

180+ Deterministic Parameters

5 Validation Layers

2 of 1,525 domains at SRS 75 or above, none of them CERTIFIED (cut-off 5 Sep 2026)

Ternary Verdict: CERTIFIED / NOT_CONFORMANT / INCOMPLETE

00 // EXECUTIVE SUMMARY

I started by scanning the top 50 Fortune 500 domains. The result was so unambiguous I scanned another 100 DACH enterprises to make sure. The count of domains with machine-readable infrastructure an autonomous AI agent could parse, validate, and act on: zero out of 150.

The later SOVP benchmark confirms the picture at larger scale: in September 2026, 2 of 1,525 domains scored 75 SRS or higher; none was CERTIFIED.

AI agents read your infrastructure, not your website. They parse structured entity data, validate cryptographic signals, and apply deterministic scoring to decide whether your infrastructure qualifies as a trustworthy source. Infrastructure that qualifies is visible to procurement pipelines. Exclusion is silent: the system moves on with no error, no notification, no second attempt.

[REQUEST A CALL →]

01 // ARCHITECTURAL INTEGRITY

Cryptographic Identity

Ed25519-signed records bound to DNS layer form the cryptographic root every agent verification chain depends on.

Schema Completeness

Structured data correctness and completeness across all Schema.org entity types relevant to B2B procurement.

Knowledge Graph Authority

Semantic entity clarity within the global Knowledge Graph: unambiguous entity references, no conflicting data states.

02 // THE VERIFICATION CORE

A signature check forms the core of the verification. The measured statement is canonicalized per RFC 8785, signed with Ed25519 per RFC 8032, and checked against the key published in DNS. Any third party can run this check themselves.

Ψ_core = Verify(K_pub, σ, JCS(M))

Core Verification Function (RFC 8032 + RFC 8785)

K_pub: Ed25519 public key, published in the domain's _sovp DNS TXT record

σ: the signature over the canonicalized document

JCS(M): the document in RFC 8785 canonical form

Ed25519 pure mode signs the canonicalized bytes directly. An external pre-hash before Verify is excluded by Section 4 of the draft and makes every valid signature fail.

Key Implication

Ψ_core = 1 establishes control over the key published in DNS, and that alone. The verdict sits in a separately signed SovereignAttestation under the Litzki Systems issuer key. Both layers stay independently verifiable.

03 // DETERMINISTIC VALIDATION

Two Results, Two Shapes

The signature check is binary: draft-litzki-sovp-04 Section 4 defines Ψ_core as returning a binary result over the signed scope. The assessment verdict is three-state and reads CERTIFIED, NOT_CONFORMANT or INCOMPLETE. Section 8.3 of the same draft keeps the two apart: verdicts and scores require a separate signed document under an independently resolved key.

An autonomous agent can confirm the identity of a system entity once the signature check (Ψ_core) returns 1.

04 // GLOBAL SIGNAL PROPAGATION

Index Dominance

Visibility is a question of indexing physics. Index Dominance means maximizing crawl frequency through clean architecture. The goal is Instant Indexing Authority: transforming static libraries into a real-time news ticker for the global Knowledge Graph.

• Crawl accessibility for GPTBot, PerplexityBot, ClaudeBot
• Historical authority from archive-indexed sources
• Structured sitemap with machine-readable priority signals
• robots.txt directives correctly scoped per agent class

05 // AGENTIC COMMERCE (2026+)

B2B purchasing processes are shifting toward autonomous AI agents. Websites optimized only for human readers give procurement algorithms little they can process.

Cryptographic Identity (Ψ_core)

DNS-bound Ed25519 signatures form the gate. Without a verifying signature, the identity claim stays unsubstantiated.

Structured Data Integrity

Schema.org completeness and correctness: every entity type an AI procurement agent expects to find.

Crawl Accessibility

GPTBot, PerplexityBot, ClaudeBot: each agent class has distinct access requirements.

Semantic Entity Clarity

Zero ambiguity in the Knowledge Graph: conflicting entity states equal structural exclusion.

Agentic Readiness (New, May 2026)

WebMCP manifest, /.well-known/webmcp.json, MCP endpoint, llms.txt: the agent-native interface layer. Infrastructure with this layer in place is fully traversable by browser-native agents.

[VALIDATE YOUR INFRASTRUCTURE →]

PROTOCOL BACKGROUND

The Validation Problem

SOVP addresses the verification boundary before data ingestion by providing a deterministic cryptographic check for a signed identity document. A site that scores 87 on one audit tool may score 71 on another. This variance is an architectural property of probabilistic systems. Autonomous agents cannot operate on such signals.

Draft 04 makes this boundary explicit: the protocol verifies the signature, the DNS-published key, signed freshness, and the host binding. How the search and procurement layer has shifted →

Draft 04 Validation Boundary

Draft 04 defines SOVP at the Layer 0 ingestion boundary. The protocol verifies the cryptographic attribution of a signed identity document to the party controlling the Ed25519 key published for the host. The full scan additionally measures five layers; these measurements lie outside the signed scope (Section 8.3):

• Cryptographic identity anchoring via DNS-bound Ed25519 signatures
• Structured data completeness and schema correctness
• Historical authority from archive-indexed sources
• Crawl accessibility for registered AI agents (GPTBot, PerplexityBot, ClaudeBot)
• Semantic entity clarity within the global Knowledge Graph

Protocol specification: IETF Experimental Draft draft-litzki-sovp-04, 7 October 2026. What Google's Web Bot Auth convergence means for infrastructure owners →

PROTOCOL SPECIFICATION

Self-issuance notice: the attestation published at /.well-known/sovp-attestation.json for litzki-systems.com is issued by Litzki Systems LLC about its own domain. Issuer and subject are the same party. It demonstrates the document format and the verification procedure; it is not third-party assurance about this website. The same is true of the identity document at /.well-known/sovp-identity.json, which is self-asserted by design: SOVP proves control of the DNS-published key and nothing more.

The normative protocol text is the IETF Internet-Draft. Plain text and XML are linked from the Datatracker page.

[READ draft-litzki-sovp-04 (IETF)] [YOUTUBE: LITZKI SYSTEMS CHANNEL] [SOVP PYTHON LIBRARY ON GITHUB] [IETF INTERNET-DRAFT: SOVP SPECIFICATION]

VALIDATOR PORTAL

The SOVP Validator Portal was the monitoring product until October 2026, with rescans, Vault records, score badges, a REST API, and an MCP endpoint. It is closed to clients and used only internally and for demonstrations. I offer SOVP scans as an individual service on request. The open-source Python reference implementation remains free for everyone (pip install sovp, Apache 2.0): it verifies a host's signed SOVP identity document against the key in its DNS.