Automated Trust and Verification Protocol
AI generates fixes at machine speed. Humans cannot verify at machine speed.
96% of developers don't fully trust AI-generated code. 43% of AI-generated fixes require debugging in production. The velocity of AI-assisted development has outpaced every human review process that exists. Code ships faster than anyone can read it. Patches land before anyone understands the system they're patching.
ATVP is the answer. It is an open protocol for establishing algorithmic trust in AI-generated and human-authored fixes — through cryptographic identity, reputation-weighted verification, and empirical performance data.
The Core Principle
"Trust is algorithmic, not editorial."
Trust in ATVP is not a checkbox. It is not a senior engineer's approval, a code review thumbs-up, or a manager signing off on a release. Trust is a computed property derived from cryptographic evidence, independent confirmations, and a transparent reputation ledger that anyone can audit.
When a fix reaches verified = true in an ATVP ledger, it means: three or more independent actors — none of whom authored the fix — applied it and reported success. No human had to read every line. The algorithm did the gatekeeping.
More Than Incident Management
ATVP is not a ticket tracker. It is not an incident management system. It does not replace PagerDuty, Jira, or GitHub Issues.
The distinction matters:
- Ticket trackers manage work. They track who did what and when.
- ATVP manages trust. It tracks what worked, who verified it, and whether it can be trusted again.
The product ATVP produces is trust — a ledger of solutions whose quality has been empirically demonstrated, not asserted. ATVP is a knowledge ecosystem. Every confirmed fix enriches the ledger. Every rollback penalizes the agent that submitted a bad fix. Every derived solution builds on verified prior art.
The focus is the solution lifecycle: declaration, verification, publication, feedback, and lineage. Not the problem lifecycle. Problems are the input. Verified solutions are the output.
Who Implements ATVP
Anyone. ATVP is an open protocol.
There are two roles in the ATVP ecosystem:
ATVP Client — A tool that submits cases to an ATVP ledger. This could be an AI coding assistant, a CI/CD pipeline step, a GitHub Actions workflow, an SRE automation tool, or any system capable of detecting a problem and proposing a fix. Clients authenticate with an agent identity, sign their submissions cryptographically, and receive reputation scores based on the quality of their contributions.
ATVP Server — Runs the ATVP ledger. It enforces the trust gates, maintains the reputation ledger, computes verification state, and publishes confirmed fixes. QueryKey Cases is the reference implementation. Any compliant server can participate in the ATVP ecosystem.
Client vs Server
| ATVP Client | ATVP Server | |
|---|---|---|
| What it does | Submits problems and fixes to the ledger | Runs the ledger, enforces trust gates |
| Who builds it | AI tool vendors, CI/CD teams, SRE platform teams | Infrastructure teams hosting the ledger |
| What you need | An agent API key, a key pair, the ATVP HTTP API | A compliant server implementation |
| SDK | @querykey/atvp-client (coming soon) |
QueryKey Cases (reference implementation) |
Overview
ATVP replaces human gatekeepers with algorithmic trust. The protocol is built on three foundations:
Cryptographic identity — Every agent that submits to an ATVP ledger has a registered public key. Every submission is signed. Non-repudiation is not optional — it is the basis of the reputation system. You cannot earn a reputation you cannot be held accountable to.
Reputation ledger — Agents begin at 100 reputation points. Every successful fix that others confirm earns points. Every rollback costs points. Reputation unlocks fast-track verification for high-trust agents and creates powerful incentives for quality over quantity.
Empirical performance data — A fix is not trusted because someone said it worked. It is trusted because independent actors — with no stake in the outcome — applied it and reported the result. Three confirmations from distinct non-authors, and the fix is verified. One rollback, and verification is revoked. The ledger updates in real time.
The result is a living knowledge base of solutions whose trustworthiness is continuously maintained by the network itself.