I didn't design SOVP at a drawing board. It grew out of twelve years of Technical SEO, out of the observation that a profession was losing its foundation, and out of the decision to rebuild that foundation instead of continuing to work on the surface.
This page tells how that happened: from the first observation of declining click-through rates to an active IETF draft. The specification lives at Litzki Systems LLC, the product at CERTavia. Here is the story in between.
The Observation: 2024 to September 2025
The first signs came from my own work. Click-through rates in client projects fell while rankings stayed the same. My own domain showed the same picture. Something had shifted, and no algorithm update explained it.
What followed was no longer a gut feeling, but three figures that I deliberately keep separate:
| Source | Claim | Classification |
|---|---|---|
| Gartner (February 2024) | Search volume declines 25 percent by 2026 | Forecast |
| Imperva/Thales Bad Bot Report (read September 2025) | Automated traffic exceeds 50 percent of total web traffic | Measurement |
| Own hypothesis, RAP v1.8 (January 2026) | By 2027, 40 percent of B2B first contacts run through machines | Own position, not an external source |
By this point, the majority of visitors on many domains were already machines, not humans. For machines, there was no reliable answer to a simple question: who owns this domain, and is what it claims actually true? No certificate, no protocol, no authority answered that deterministically. That gap became the starting point.
„For machines, there was no reliable answer to a simple question: who owns this domain, and is what it claims actually true?"
Building the Tools: November to December 2025
Before a protocol, there were tools. A homegrown keyword and backlink tool. An alternative to Frase and NeuronWriter for content briefings. Custom dashboards for project reporting.
The reason was simple: working alone means carrying monthly costs in the low three digits per tool yourself, for software that rarely delivered exactly what a project needed. Building it myself cost time, saved money, and ultimately delivered exactly the data that was needed. No marketing layer in between.
Anyone who builds their own tools eventually sees something no finished tool shows: the gap underneath all of them. Every SEO tool measures rankings, backlinks, content scores. None of them answered whether the domain being analyzed was actually trustworthy, for a machine making its own decisions.
The Manifesto: January 2026
In January 2026, the Revenue Architecture Protocol emerged, RAP v1.8: a consulting framework in marketing language, for decision-makers, with ten pillars. I'll call it openly what it was: a manifesto, not a specification.
Five ideas from RAP carried forward, unchanged to this day:
- Architecture before content
- Machine-readability as a design goal, not an afterthought
- Deterministic instead of stochastic logic
- Externally anchored trust instead of self-reporting
- Immutability of the core
What was missing was more concrete: formalization, openness, cryptographic verifiability. RAP demanded the right things and still had no procedure to prove them.
An early black-box concept from this phase emerged from a collaboration that ended early. What followed was built from scratch: its own deterministic architecture, its own filing.
The Scoring Logic: Twelve Years in an Audit Catalog
Long before the manifesto, a weighted SEO audit catalog already existed: 28 checkpoints across six areas — technical, performance, mobile, content, structure, and off-page. Each checkpoint received an impact level and a degree of fulfillment.
| Impact Level | Weight (V) |
|---|---|
| Very High | 10 |
| High | 7 |
| Medium | 4 |
The formula behind it: Σ(P × V) / Σ V_max × 100. Not a protocol — a consulting tool, grown out of twelve years of operational SEO work in which I evaluated hundreds of domains exactly this way. Subjective, verifiable only by the person who ran the audit, signed by no one.
The structure of this catalog lives on in today's CES score: weighted parameters, grouped into clusters, aggregated into an overall value, evaluated against a defined threshold. The architecture stays the same. Three layers were added:
- Reproducibility: The same scan today produces the same result on any machine.
- Cryptographic signing: The result is documented tamper-proof.
- Binary consequence: CERTIFIED or FAILED. The old catalog allowed shades of gray. SOVP deliberately does not.
The protocol's parameter space covers over 265 signals. CERTavia implements 80+ of these parameters across six clusters, tailored to the EU AI Act. Both numbers are correct. They describe different layers of the same system.
„Visibility can be measured. Identity can be verified. Together, they form a protocol."
Between the old audit catalog and today's protocol lay a phase in which I tested whether mathematical models from wave physics could prove that architectural integrity produces measurable algorithmic visibility. The math was valid; the question pointed in the wrong direction. The shift from a physical analogy to cryptographic verification was the decisive turn.
Formalization: March to June 2026
Three decisions turned the manifesto into a protocol.
An open protocol instead of a tool: A tool belongs to a vendor. A protocol belongs to the web. Every instance that checks SOVP checks the same rules, regardless of who wrote it.
Ed25519 with DNS anchoring instead of a certificate authority: No central authority decides who is trustworthy. The public key lives in the domain's own DNS zone. Anyone can verify it without asking a third party.
Binary instead of a score: CERTIFIED or FAILED, no percentage in between. The same logic applies to alarms in intensive care, as I described in System Failure Announces Itself: a finding with a gray zone invites inaction. The same rule applies to a trust protocol.
The full benchmark, DACH Enterprise Readiness Report 2026, shows how rarely CERTIFIED has been achieved so far. The audit dimensions in detail are on the expertise page.
What SOVP Claims, and What It Doesn't
SOVP is a verification layer beneath existing trust frameworks. It complements them; it doesn't replace them. SOVP doesn't check whether content is true, complete, or compliant. It checks whether the origin of a machine-readable document is cryptographically proven before any system even processes it.
Distinction from SVTP: SOVP (Sovereign Validation Protocol, draft-litzki-sovp) has no connection to draft-sovereign-svtp, the "Sovereign Verification & Trust Protocol" from an entity called Sovereign AG. The similarity in name is the subject of an ongoing IPR proceeding at the IETF. I maintain the full protocol notice with all references on the expertise page.
Where the Protocol Lives Today
Three places where SOVP actually exists today, not just where it's described:
- The specification at Litzki Systems LLC →
- draft-litzki-sovp on the IETF Datatracker →
- Scan your own domain, CERTavia →
The path from the first declining click-through rate to an active draft wasn't planned. It was the logical consequence of a single question that no existing system could answer.
Questions about SOVP, the formalization, or the audit? Talk to me directly.
Schedule a call Discover SOVP →