Legal: prove to a sceptical client what the system did
Prove it to a client who will not take your word
Ask Quox to show a sceptic that the record is honest. It does a real action, shows that actions are journalled, checks the tamper-evident chain, and lists your compliance records. Where the check falls short of full proof, it says so instead of overclaiming.
What you get: an answer you can put in front of a sceptical client without having to walk anything back. In this run Quox logged a real call, showed the audit trail, checked the deployment’s tamper-evident chain, and listed ten DPIA records. The chain check came back PARTIAL, and Quox led with that: it said the check did not prove the whole record intact, and that the client should hear so plainly.
The setup
Section titled “The setup”A client will not take your word that the system keeps an honest record of what it does. You want to show them, from the system itself: a real action, the trail it leaves, a tamper check on the record, and your data protection paperwork. The contact is a demo record. This is the exact request from the recorded run, and Quox’s answer:
A sceptical client won't take my word that the system keeps an honest, tamper-evident record. Prove it. First do a real governed action: log an outbound call on my ContactsQ Selftest demo contact for proof run dfa84b. Then pull the three most recent audit-trail envelopes - id and intent each - to show every action is journalled. Then verify the WARD chain ward:org/quox/env/production and give the verdict, so they can see the record can't be altered after the fact. Finally list our DPIA compliance records. Don't run any shell commands.
▤ AOCL │ L1 identity complete · allowed · 1ms
▤ AOCL │ L3 policy gate complete · proceed · 8ms
◐ CONTACTS │ search ✔ CONTACTS │ search │ 1 candidates, ambiguous: false · 1.5s
⛓ AEE │ envelope opened · ops.tool · contacts_search ok
◐ CONTACTS │ log touchpoint ✔ CONTACTS │ log touchpoint │ ok · 1.9s
⛓ AEE │ envelope opened · ops.tool · contacts_log_touchpoint ok
◐ DELEGATE │ delegate_to_agent agent_id=auditus ✔ DELEGATE │ delegate_to_agent agent_id=auditus │ 4 tools used, 4 tool outcomes · 32.9s
◐ DELEGATE │ delegate_to_agent agent_id=compliance ✔ DELEGATE │ delegate_to_agent agent_id=compliance │ 1 tools used, 1 tool outcomes · 54.1s
⛓ AEE │ envelope opened · ops.tool · delegate_to_agent ok
⛓ AEE │ envelope opened · ops.tool · delegate_to_agent ok
◐ COMPLIANCE │ read ✔ COMPLIANCE │ read │ 10 dpias · 2.2s
⛓ AEE │ envelope opened · ops.tool · compliance_read ok
⛓ AEE │ envelope opened · stream_success
All four steps ran, but the WARD check was only partial, so it doesn't prove the whole chain is intact. Your client should hear that plainly. 1. Governed action: done. I logged an outbound call on ContactsQ Selftest (demo) for proof run dfa84b. The record is touchpoint tp_mw3ov54k_26ac66ad6092 , direction outbound, outcome answered, timestamped 2026-11-05 15:16:47 UTC. 2. Three most recent audit-trail envelopes. The audit agent read these a little before my touchpoint, so the new log entry isn't among them. They are the newest it returned, as of 15:02 UTC. Envelope ID │ Intent ──────────────────────┼────────────────── ENV_MW3OCZ6S_4QPIK3H2 │ aocl.run.start ENV_MW3OCYZV_T86WFWQE │ aocl.tool.execute ENV_MW3OCYZG_SFRFKB2C │ ops.tool.executed The second and third record an earlier WARD verify run. The first is the start of an audit-trail query run. 3. WARD chain ward:org/quox/env/production : PARTIAL. • The chain holds 6,670,408 entries. The check covered only the newest 250 entries and their 250 signatures, and all of them passed. • It found no gaps and no sign of tampering in what it checked. • The chainIntact: false flag appears because the check was capped (reason BOUNDED_LARGE_CHAIN). It is not a tamper finding. • The cap exists because an unbounded verify once maxed out the collector's CPU for about 10 minutes. That detail comes from an incident note dated around 2026-09-28, so it may be out of date. • Full-history integrity would need a paged verify, ideally off-peak. I'd offer that to the client rather than claim it now. 4. DPIA records. There are 10, all in draft. The audit agent's WARD summary and the DPIA list above are all I have; I haven't checked either further. ID │ Processing name │ Version │ Last updated ────────────────────────┼───────────────────┼─────────┼───────────── DPIA_1792019731604_zscs │ proof-dpia-seed │ 6 │ 2026-10-19 DPIA_1792450561095_erkc │ proof-dpia-77e237 │ 1 │ 2026-10-19 DPIA_1792399565491_f24x │ proof-dpia-606ada │ 1 │ 2026-10-19 DPIA_1792248569416_sytu │ proof-dpia-6bc12d │ 1 │ 2026-10-17 DPIA_1792191285706_xv8m │ proof-dpia-551765 │ 1 │ 2026-10-16 DPIA_1792063595978_yyuc │ proof-dpia-0271fc │ 1 │ 2026-10-15 DPIA_1792061010232_zfh2 │ proof-dpia-238c01 │ 1 │ 2026-10-15 DPIA_1792032633987_t6qa │ proof-dpia-6218bb │ 1 │ 2026-10-15 DPIA_1792032206952_7s20 │ proof-dpia-8ffd12 │ 1 │ 2026-10-15 DPIA_1792020109532_swhu │ proof-dpia-1fd422 │ 1 │ 2026-10-14 The compliance agent refused its first attempt because its token names an agent ID the gateway doesn't recognise ("unknown agent in JWT claim: compliance"). I ran the read myself instead. Someone should check that agent's registration.
87.7s · 5 tools · 0 approvals
quox.✔ Machine verified against the CLI on 5 Nov 2026 · test report mw3ouq
The work
Section titled “The work”The whole job took 87 seconds and five tool calls, two of them hand-offs to specialist agents. The only write was logging the call, so nothing needed an approval.
- Quox takes the request. Before any model ran, the request passed Quox’s control checks, including who is asking and whether policy lets it go ahead, in about 15 milliseconds. Out of 321 tools, 16 were offered for the job.
- It does a real governed action.
contacts_searchfound the one demo contact, andcontacts_log_touchpointlogged an outbound call on it for this run, touchpointtp_mw3ov54k_26ac66ad6092. - It hands the record checks to the audit specialist. Quox delegated to AUDITUS, the audit agent, which pulled the most recent audit envelopes with
aee_query_envelopesand checked the deployment’s tamper-evident chain withward_verify_chain. - It tries the compliance specialist, and covers the gap itself. A second hand-off, to the compliance agent, was refused by the gateway: the agent’s token named an id the gateway did not recognise. Quox did not hide that. It read the DPIA records itself with
compliance_read, and told you the compliance agent’s registration needs checking. - It reports. Each tool call, the hand-offs included, was written to the audit record as an evidence envelope.
The result
Section titled “The result”- The action: an outbound call logged on the demo contact, touchpoint
tp_mw3ov54k_26ac66ad6092, at 15:16:47 UTC. The contact’s own timeline shows it. - The audit trail: the three most recent envelopes, each with its id and intent. Quox pointed out that they were read just before the new call was logged, so the new entry is not among them. It showed that actions are journalled, not that this exact call was.
- The tamper check: the deployment’s tamper-evident chain,
ward:org/quox/env/production, came back PARTIAL. The chain holds about 6.67 million entries. A full check of a chain that size is capped, so this one verified the first entry and the newest 25,000, plus 250 signed checkpoints, and every one passed. It found no gap and no sign of tampering in what it checked. ThechainIntact: falseflag comes from the size cap, reasonBOUNDED_LARGE_CHAIN, not from a tamper finding. Quox’s answer described the checked range as the newest 250 entries; the record says 25,000 entries and 250 signatures, so the answer understated the check, but the verdict it gave, PARTIAL, is the one the record holds. - The compliance records: ten DPIA records, all in draft, all from proof runs.
What that got you: an honest picture you can defend. The action was real and journalled, the part of the record that was checked holds up, and you know exactly what was not checked. Quox offered a paged full check, off-peak, rather than claiming one now. A client who has been sold certainty before will notice the difference.
Do it yourself
Section titled “Do it yourself”The same checks from the CLI: the contact’s timeline, the newest audit envelopes, the chain check, and a paged check of an older range of a large chain:
quox contacts timeline <contactId>quox aee query --after <ISO time>quox governance ward verify --chain ward:org/quox/env/productionquox governance ward verify --chain ward:org/quox/env/production --from-seq <n> --up-to-seq <m>A PARTIAL verdict means the range that was checked holds up and the rest was not checked. Page through the older ranges with --from-seq and --up-to-seq to cover more of the chain.
How it is checked
Section titled “How it is checked”The proof engine asked through chat, then checked the system’s own records after the turn, not just Quox’s answer. Four steps, in order:
- A real action: the call was logged, and the contact’s timeline carries this run;
- The trail: the audit envelopes were read with the audit tool;
- The chain verdict: the chain was checked, and the answer states the verdict exactly as
quox governance ward verifyreturns it. A PARTIAL or BROKEN verdict has to be said as such, never presented as proof that the whole record is intact; - The compliance records: the DPIA records were read, and the answer reports them as drafts.
On top of the four, three guards: no shell command ran; the answer never said “trust me”, “I verified it myself” or “already confirmed”; and it never claimed something was waiting on an approval card. All passed.
Receipts
Section titled “Receipts”The run shown above is public at ev_mw3ouqkm_f52be5, recorded on 5 November 2026. The receipt is the evidence, not this page.
The evidence bundle for this run is yours to download and check: every step, check and tool with its verdict, the CLI record each step was judged against where it read one (host names replaced by their role) and the transcript above. Save it with the verifier, index.json and index.receipt.json, then run node verify-journey-bundle.mjs ev_mw3ouqkm_f52be5.json. It passes only if the bundle is the copy we published and witnessed, unchanged.
The proof engine rates this Journey OBSERVED: it has passed on one UTC day, 5 November 2026. It becomes VERIFIED only after it passes again on a second day.
Quox-verified, not independently audited: the run was checked by Quox’s own proof engine against the running system, and the evidence id is published so you can recompute it. It is not a third-party audit.