Get started

New category · operational integrity

Verifiable AI operations.

Structured, tamper-evident records of every AI decision. Not logs. Not traces. Verifiable operational evidence built on open protocols, wherever your agents run.

Enterprise add-on · $599/yrDecision Evidence
protocols 4 open specsIETF four live Internet-Draftsenvelope 14 fieldscontrol stack 11 layers

For 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.

Traditional logs
Decision evidence
StructureUnstructured text
StructureTyped JSON schema
MutabilityMutable (editable)
MutabilityAppend-only, hash-linked
CapturesFunction calls, errors
CapturesDecisions with reasoning
CausalityImplicit (timestamps)
CausalityExplicit (correlation + hash chain)
VerificationTrust the server
VerificationCryptographic proof
ComplianceInsufficient for audit
ComplianceBuilt for regulatory review

The category

The missing layer in the AI stack.

Every layer has active competition. Billions in funding. Clear market dynamics. One layer between agent execution and applications has almost no competition: operational integrity, the evidence layer applied to operations.

ApplicationsCopilots, AI SaaS, enterprise assistants
Operational integrityAEE + AOCL + VOLT + WARD
AgentsGoal-oriented actors with tools and memory
OrchestrationLangGraph, CrewAI, Temporal
ContextVector stores, RAG, retrieval frameworks
ModelsOpenAI, Anthropic, Google, Meta
ComputeNVIDIA, AWS, Azure, Google Cloud

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.

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.

Every agent decision produces a structured evidence block. Compact enough to attach to every action. Rich enough to reconstruct 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.92

The record, live

The evidence trail in the dashboard.

Every 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.

quoxcore · volt ledger
The VOLT verifiable operations ledger in the Decision Evidence plugin: a VOLT protocol tag beside the ledger name, four stat cards for total runs, events recorded, evidence bundles and chain integrity, a bridge-active indicator, a correlation-id search bar with filters, a list of today's runs with ACTIVE badges and run ids, and an Import & Verify Bundle drop zone.
  1. 1Know the protocol at a glanceVOLT sits right beside the ledger name, with hash-chained events, evidence bundles and chain verification named underneath.
  2. 2Four numbers, the whole ledgerTotal runs, events recorded, evidence bundles and chain integrity sit as four cards across the top.
  3. 3See the bridge is liveA bridge-active indicator and a recorded-bundle count sit right under the stat row.
  4. 4Search by correlation idEvery run is searchable by its correlation id, with filters and a manual refresh beside the search bar.
  5. 5Read every run at a glanceEach row carries an ACTIVE badge, its workflow name, an event count and a RUN id with a timestamp.
  6. 6Verify a bundle without trusting usDrop a .json evidence bundle here and the chain is checked, not just accepted.

Captured from the real VOLT ledger, not a mockup.

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>.ndjson
01

Verify offline

A receipt carries its own Ed25519 public key. Anyone can check it with no account and no network.

02

Local first

Receipts are written to your own machine. Witnessing and governed execution through QuoxCORE are an upgrade, not a requirement.

03

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 it never depends on the vendor that produced it. 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 is clear.

Every major jurisdiction is moving towards documented, reviewable, monitorable AI operations. The specifics vary. The trajectory does not.

01

EU AI Act

Article 12: automatic recording of events. Article 14: human oversight with system understanding.

Enforcement began August 2025
02

NIST AI RMF

Ongoing monitoring, documentation of AI behaviour, and accountability mechanisms.

Framework published
03

Colorado SB 21-169

Impact assessments and records of how high-risk AI systems were used.

Enacted

Where it stands

Shipped today, planned next.

Shipped
  • 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 live agent runs, part of the platform
Planned
  • 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.

4open protocols4Open protocol specs14AEE envelope fields11AOCL control layers6evidence fields per decision

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.

scroll