Audit the Pricing Tools

Every decision the kernel made for the pricing tools is a signed record in the store the run leaves behind. Query that store by capability, tool, outcome, and time, then hand the complete records to a reviewer such as Corbel Assurance.

Continues from Native Tool Server. The default run admits two quotes, refuses a refund outside the tool grant, and refuses a third quote after the call limit is spent.

1. List every decision the application recorded

Run the pricing tools, then enter the run directory printed after evidence:. It holds receipts.db and the complete JSON records. With chio installed from Installation, list the local store.

chio --receipt-db receipts.db \
  receipt list --admin-all --limit 10 \
  | jq -c '{tool_name, decision}'

{"tool_name":"quote","decision":{"verdict":"allow"}}
{"tool_name":"quote","decision":{"verdict":"allow"}}
{"tool_name":"refund","decision":{"verdict":"deny","reason":"requested tool refund on server pricing is not in capability scope","guard":"kernel"}}
{"tool_name":"quote","decision":{"verdict":"deny","reason":"invocation budget exhausted for capability cap-01a12eff-a57c-76f4-941e-55509841be30","guard":"kernel"}}

You should see four records: two allowed quotes, one refund outside the tool grant, and one quote past the call limit. The CLI writes one complete receipt per line, and the jq projection keeps each tool name and decision. --admin-all names the read boundary, here the private store of the run you completed; a tenant-owned store takes that tenant’s boundary instead.

2. Filter the store to its two refusals

Ask the same store for denied decisions only.

chio --receipt-db receipts.db \
  receipt list --admin-all \
  --outcome deny --limit 10 | jq -c '{tool_name, decision}'

{"tool_name":"refund","decision":{"verdict":"deny","reason":"requested tool refund on server pricing is not in capability scope","guard":"kernel"}}
{"tool_name":"quote","decision":{"verdict":"deny","reason":"invocation budget exhausted for capability cap-01a12eff-a57c-76f4-941e-55509841be30","guard":"kernel"}}

You should see refund, refused because the capability grants only quotes, and a third quote, refused because both permitted calls were already used. Both name the kernel guard, and the decision reason identifies the authority check involved, so select these records by outcome rather than by guard name.

3. Save the complete refusal records for review

Redirect the same query into a file.

chio --receipt-db receipts.db \
  receipt list --admin-all \
  --outcome deny --limit 10 > denied.ndjson

You should see no output and a denied.ndjson holding both signed refusals in full. This run has two matches, so one page carries both. A larger log returns a cursor; follow it until the stream ends, because --limit sets a page size.

4. Package the run for offline verification

Export the run's signed receipts and log evidence into a fresh directory.

chio --receipt-db receipts.db \
  evidence export --admin-all \
  --output package

You should see no output and a package directory holding all four records, their capability lineage, and a manifest that describes its files. This short-lived application exited before its first checkpoint, so the package reports every receipt as uncheckpointed.

5. Verify the package against your host’s key

Check the package the way a reviewer would, pinned to the public key your host wrote to kernel-public-key.txt before it served a request.

chio evidence verify --input package \
  --trusted-kernel-pubkey kernel-public-key.txt

verified   4 receipts from 1 kernel, signatures verified against pinned keys

You should see all four receipts verified, the two refusals among them: a refusal verifies exactly like an allow. Verify Receipts Offline reads the full coverage report for this package and checks single receipts in your own code.

Next: verify the package you exported