Get started
Reason
AgentsQuoxMindAgentic TeamsMirror & QuoxHatQuoxLensRemember
QuoxMemoryQortexCompoundingQuoxPlanCodebase MirrorAct
QuoxFlowQuoxEngineQuoxAgentQuoxChatAutonomyRun
EnterpriseOrganisationsPowers & ToolsmithQlusterQuoxBastionInterfaces
QuoxMCPQuoxCLIQuox ConsoleQuoxBoxQuoxVoiceGovern
HITL ApprovalsQuox SecurityAgent HonestyQuoxVaultAI GovernanceAgentic AIProve
For AuditorsVerifiable AI OpsLoggingQuoxSEOEU AI ActCompliance SuiteChannels
Matrix RoomsDiscord ProTelegram ProQuoxSignalCoreCommsAll products A-ZBuild
QuoxProofDeveloper KitPlugin SDKBring your tool to QuoxQuoxpertQuoxSkillsShip and sell
Build and sellBrowse MarketplaceDownloadsProtocolsDev Suite
Dev ServersQuoxBuildQuoxSlotsShared Skills + RulesQlarityDev workflow
RepoBrainGripeTriageFixLoopProofLoopDoneEngineAll products A-ZGet started
OverviewArchitectureProtocols
AEEAOCLVOLTWARDReference
GlossaryAPI ReferencePlugin SDKDockerAll products A-ZWhat the Quox evidence pipeline looks like after the rebuild: VOLT chains, WARD witnesses, intent filtering, and a glass dashboard that shows the state of all of it.
Compliance theatre is the practice of doing things that look like compliance without producing evidence that would survive external scrutiny. Logs are theatre. Hash chains are evidence. Here is the difference, technically.
Quox generates compliance reports across GDPR, HIPAA, SOC2, ISO 27001, and the EU AI Act. For a long time, those reports were built on logs. Logs are useful: they tell you what happened. But they are mutable, they have no witness, and a third party has no way to verify that the export you hand them matches what the system actually recorded.
When we ran an adversarial audit of our compliance formatters and found critical gaps, the formatter rewrites were step one. Step two was fixing the underlying evidence pipeline so that the formatters had something substantive to report against.
This article describes the pipeline rebuild: VOLT hash chain coverage extended to all 6 chat paths, WARD witnessing operating continuously, server-side persistence replacing browser storage, intent filtering separating compliance-relevant events from operational noise, and the Compliance Command Center surfacing all of it in one view.
This distinction matters technically. A log is a sequence of records in a database. Nothing prevents the records from being modified, deleted, or re-inserted with adjusted timestamps. A hash chain is different: each record includes the hash of the previous record. Modify any entry and every subsequent hash breaks. The chain is self-verifying.
| Aspect | Logs | Cryptographic evidence |
|---|---|---|
| Integrity | Data in a database table, mutable, deletable, editable by anyone with write access | Hash-chained records where modifying any entry breaks every subsequent hash in the chain |
| Witness | Server timestamps set by the system clock, easily manipulated | Ed25519-signed Merkle tree tips committed to an append-only ledger by WARD at each checkpoint |
| Completeness | Dependent on every code path calling the logger, gaps appear silently | Coverage tracked at path level; a missing path is a detectable gap, not a silent one |
| Intent clarity | Raw event stream mixing AI decisions, infrastructure events, and user actions without semantic distinction | Intent-filtered: agent decisions, human actions, and fleet operations separated before storage |
| Independent verifiability | Third party must trust your export, no way to verify the export matches the original | Hash chain can be independently verified against WARD-witnessed tip; tampering is mathematically detectable |
The practical implication: a third party given access to a Quox evidence export can independently verify its integrity without trusting us. They compute the hash chain themselves and check it against the WARD-signed Merkle tips. If the hashes match the signed tips, the evidence is intact. If they do not match, the discrepancy is detectable and locatable.
Three protocols underpin the evidence pipeline. Each has a distinct role. Together they produce a verifiable record from event ingestion to signed checkpoint.
| Protocol | Role | Technical detail | Coverage |
|---|---|---|---|
| VOLT | Immutable event chains | SHA-256 hash chain with previous-hash linking. Each event includes its own hash and the hash of the preceding event. Chain integrity verifiable by any party with access to the raw event store. | Path coverage: 6/6 chat paths active |
| WARD | Cryptographic witnessing | Ed25519 key pair per node. Events batched into Merkle tree; root signed and appended to witness log at each interval. Signed tips are the audit anchors. | 29,000+ events witnessed; signing cadence continuous |
| AOCL | Layered observability | 11 processing layers from ingress to audit writeback. Each layer emits independently auditable events with correlation IDs. Full causal chain from input to output reconstructable. | 11 layers active, correlation IDs on all messages |
VOLT hash chain coverage was the most significant gap we found. The original integration covered PATH 1 only: direct API key calls to the Anthropic Messages API. Five other paths existed, none of them covered. This meant compliance evidence was missing for the majority of actual production traffic.
| Path | Component | Description |
|---|---|---|
| PATH 1 | API key (Messages API) | Direct Anthropic Messages API calls via API key auth |
| PATH 2A | OAuth + MCP | OAuth-authenticated sessions routed through quoxmcp |
| PATH 2B | OAuth (no MCP) | Legacy OAuth path with direct API calls |
| PATH 3 | Agent relay | Agent-to-agent message relay through QuoxCORE |
| PATH 4 | Workflow triggered | Messages generated by QuoxFlow workflow execution |
| PATH 5 | Tool output injection | Tool call results injected into conversation context |
Each path now calls the VOLT writer at the same points in the processing chain: message ingestion, tool execution, and response output. The chain structure is identical across paths, which means any auditing or verification tool works uniformly regardless of which path generated the event.
The pipeline rebuild happened in five phases. Each produced a measurable before/after state.
Before: 1 path covered, 5 unverified. After: 6/6 paths covered with identical chain structure. The core issue was that early VOLT integration was added during PATH 1 implementation and never extended. Each new path had to explicitly call the VOLT writer. Coverage was now tracked as a first-class metric, not an assumption.
Extended from PATH 1 only to all 6 chat pathsBefore: events witnessed on-demand; periods between calls had no signed checkpoint. After: 29,000+ events with Ed25519-signed Merkle tips at regular intervals. WARD now runs a background witness loop.
Each interval, it computes the Merkle root of unwitnessed events and signs it with the node's Ed25519 key. The signed tip is appended to the witness log. An auditor can verify any event by reconstructing the tree from the raw events and checking it against the signed tip.
Event witnessing moved from manual to continuousBefore: compliance data partially in IndexedDB, lost on browser clear, inaccessible across devices. After: all evidence in PostgreSQL, accessible via authenticated API from any client. Browser storage is not compliance storage. Enterprise customers expect data to persist across browser clears, device changes, and account switches. The full migration required auditing every read path and confirming each had a server-side API equivalent.
Evidence storage moved off browser state entirelyBefore: 68% of captured events were infrastructure/fleet operations with no compliance relevance. After: events classified by type at ingress; compliance filter applies before evidence store write. A compliance report built from raw events is noise-heavy and misleading. Intent filtering classifies each event at ingestion: AI decision, human action, fleet operation, infrastructure event, or system metric. Compliance formatters now query the filtered store, not the raw event log.
Compliance-relevant events separated from operational noiseBefore: compliance state distributed across separate formatter outputs with no unified view. After: single glass dashboard showing VOLT coverage, WARD witness state, and framework readiness in one view.
The dashboard is not cosmetic. It is the operational interface for the evidence pipeline: coverage gaps are visible before an auditor finds them, WARD witness health shows whether signing is current, and framework cards reflect the three-state output (evidenced, requires action, requires configuration).
Evidence surfaced in unified operational viewThe Command Center is the operational surface for the evidence pipeline. It is not a compliance certificate generator. It is a live view of whether the underlying evidence systems are operating correctly, with framework readiness derived from actual evidence state rather than configuration claims.
The core distinction is between systems that produce records and systems that produce evidence. Records are necessary. Evidence is records that a third party can independently verify, with integrity guarantees that do not rely on trusting the organisation that produced them.
An Ed25519-signed Merkle tip from WARD is a verifiable cryptographic statement: at this point in time, this set of events existed in this exact form. Any future change to those events breaks the verification. This is not a marketing claim about trustworthiness: it is a property of the cryptographic construction.
For enterprises operating AI systems in regulated environments, that distinction matters when an auditor asks for evidence, when a regulator requests records, or when a legal dispute requires reconstruction of what an AI system actually did. The question is not whether you have logs. The question is whether your logs are evidence.
Open protocol specifications. No vendor lock-in, no proprietary formats. Implement them yourself or use QuoxCORE.