New category · operational integrity
Verifiable AI operations.
Structured, tamper-evident records of AI operations. Not logs. Not traces. Verifiable operational evidence built on open protocols.
Enterprise add-on · $599/yrDecision EvidenceFor the overview with pricing and demos, see the AI Governance hub →
The definition
What verifiable AI operations means.
Verifiable AI operations means running AI systems so that every consequential action produces evidence a third party can check without trusting the operator. Each decision, approval and execution is recorded as a structured event, hash-chained so any alteration is detectable, bound to the identity that acted, and exportable as a portable bundle that verifies offline.
Ordinary logging records whatever the operator chose to write, and can be rewritten by whoever controls the machine it lives on. Verifiable operations produce proof that the record itself has not been altered.
The term covers four separable jobs: what was said, what was allowed, what happened, and whether the record was rewritten afterwards. Each is independently implementable, and verification requires no account with the operator, and none with us.
In plain words
What it is, where it lives, when to reach for it
- What is it
- The definition of verifiable AI operations: running AI so a third party can check the evidence.
- Where do I use it
- On any estate that runs agents; verification itself runs offline from an exported bundle.
- When would I use it
- When trusting the operator’s own logs stops being an acceptable answer to your auditor or your customers.
- How do I use it
- Read the definition above, then the four jobs below; each maps to one open protocol you can implement.
The problem
Logs are not evidence.
Your AI agent deployed an infrastructure change, modified a customer record and triggered three downstream workflows. Something broke. What happened?
Application logs tell you what functions were called. They do not tell you what information the agent considered, what alternatives existed, or what confidence threshold was applied. They are mutable. They are unstructured. They capture events, not decisions. For autonomous AI systems, they are insufficient.
The category
The missing layer in the AI stack.
One layer between agent execution and applications is easy to overlook: operational integrity, the evidence layer applied to operations.
The foundation
Four open protocols.
Products compete. Protocols compound. The operational integrity layer is built on open standards, not proprietary formats. All four are specified and implemented; IETF submission is filed for all four.
Agent Envelope Exchange
Structured envelope wrapping every agent interaction. 14 fields. Full traceability.
Agent Orchestration Control Layers
11-layer processing pipeline governing agent behaviour. Policy, safety, audit.
Verifiable Operations Ledger & Trace
Append-only, hash-linked event ledger. Tamper-evident by construction.
Write-once Append-only Receipt Digests
Content-free witness receipts. External attestation without data exposure.
How they divide the work: AEE is the envelope, AOCL is the control pipeline, VOLT is the evidence ledger and WARD is the witness. Together they turn an agent run into a record you can hand to an auditor and verify without trusting the server that produced it.
The record
What gets recorded.
Decision evidence is opt-in per assistant and covers dashboard chat only. It is the model's own structured account of its decision, not a trace of its internals. The block is compact enough to attach to an action and rich enough to review the decision chain.
inputs_usedWhat information the agent considered"alert.severity: critical", "host: nw-worker-01"tools_usedWhat tools were invoked"fleet_status", "service_health"decisionWhat the agent decided"restart_service"reason_summaryWhy the decision was made"nginx unresponsive, no maintenance window"action_takenWhat action resulted"systemctl restart nginx"confidenceHow confident the agent was0.92The record
The evidence trail in the dashboard.
Where decision evidence is enabled, each decision block lands in the VOLT ledger as an append-only, hash-linked entry. The VOLT protocol is open and the evidence API is part of the platform; this dedicated ledger view, with its run list, hash-chained events and bundle verifier, is the Decision Evidence plugin, an enterprise add-on at $599/yr rather than something every install carries.
For developers
Signed receipts, two lines in.
You do not need the whole platform to start. QuoxProof is a small open SDK that gives every tool your agent calls a signed, hash-linked receipt, written to your own machine. Anyone can verify a receipt offline with the public key it carries: no account, no backend, no shared secret. It is the same evidence idea as the ledger above, available the moment you add a decorator.
import quoxproof
quoxproof.enable()
@quoxproof.tool
def search(query: str) -> str:
return web_search(query)
# every call writes a signed receipt to ~/.quox/proofs/
# verify later, offline: quoxproof verify <session>.ndjsonVerify offline
A receipt carries its own Ed25519 public key. Anyone can check it with no account and no network.
Local first
Receipts are written to your own machine. Witnessing and governed execution through QuoxCORE are an upgrade, not a requirement.
Honest about proof
The verifier reports what it can and cannot show, and never collapses a receipt to a single green tick.
Verify without trusting the producer. Unlike a backend audit service, a QuoxProof receipt carries its own public key, so checking its integrity never depends on the vendor that produced it. Where it came from is only established if you pin the key. The verifier stays honest about what it shows: signature valid and chain intact locally, and, when you run it through QuoxCORE, that the action was witnessed and ran through a governed plane.
pip install quoxproofgithub.com/quoxai/quoxproof →The direction of travel
The regulatory direction.
Emerging AI rules increasingly ask organisations to keep records of what their AI systems did and who approved it.
NIST AI RMF
Ongoing monitoring, documentation of AI behaviour, and accountability mechanisms.
Where it stands
Shipped today, planned next.
- Four protocol specifications published in the open, with JSON schemas and worked examples
- AEE, AOCL, VOLT and WARD: specified and implemented; IETF submission is filed for all four
- WARD v0.1: content-free hash-chain witnessing with deterministic verification and optional Ed25519-signed tips
- The Decision Evidence plugin, recording the six-field evidence block on agent decisions
- The protocol suite running in QuoxCORE: AEE envelopes and the AOCL layer audit on agent runs, part of the platform
- Protocol evolution beyond the current versions, tracked in each spec's public roadmap
Planned means not yet shipped. The public roadmaps in each protocol repository are the source of truth for what comes next.
From logs to proof
Build the evidence layer in, not on.
The organisations that build evidence infrastructure now will move faster, with more confidence, and with fewer costly surprises. The ones that wait will discover that retrofitting accountability is harder than building it in.
Go deeper
The protocols and the practice.
From the blog
The trust gap
Why AI operations need evidence rather than logs: the argument this page rests on.
Read the articleProve your AI behaved
Build the accountability record before the regulator asks for it.
Read the articleWe read the code behind a dozen self-improving agents
What a category-wide evidence gap looks like from inside the source.
Read the article