kolm
HMAC-SHA-256 · tamper-evident chain

Verify a receipt.

Every kolm compile and run emits a signed receipt. Paste a receipt URL or hash and we'll show you which artifact produced the output, on which device, with what K-score. No login. No payload data ever in a receipt by design.

Below is a sample receipt for support-triage.kolm. The verify button just renders it — production receipts hit /v1/receipt/:hash read-only.

01Sample receipt
kolm.ai/r/e176bc2f720b94a8 · run record Signature verified
Artifactkolm/support-triage@sha256:e176bc2f720b94a8c8e3...
K-score0.94 · gate ≥ 0.85 · passed
Compiled byacme-health (tenant 4f81)
Compiled at2026-05-12T18:42:07Z
Ran onmacOS 14.4 · arm64 · M2 Air, 16 GB
Run at2026-05-16T07:18:33Z
Latency p5080 ms (256 output tokens)
PHI modeon · redactor applied · assessment delta ≤ 0.05
Egress0 bytes · harness enforced
Ring 1 (compile)2bc4...a91d
Ring 2 (eval)8e10...f2c7
Ring 3 (run)a91d...e176
Ring 4 (audit)e176...720b94a8
Signed byHMAC-SHA-256, customer-managed key kms://arn:aws:kms:us-east-1:.../key/4f81

What the receipt does not contain: the input prompt, the model output, any PHI/PCI/privileged content. Payload bytes never leave the device. The chain proves that a run happened with the named artifact at the named K-score — not what was said.

02What a receipt proves
Provenance

This artifact, not another.

Receipt pins the SHA-256 of the .kolm. A swap to a different model or a tampered LoRA breaks the chain.

Quality gate

K-score at run time.

The compile-time K-score is signed into the artifact. The run-time receipt re-proves the gate held. Below-gate runs are refused.

No egress

Stayed on this device.

Runtime harness counts bytes-out per run. A run that exfiltrated would have ring-3 bytes-out non-zero. Auditors can scan for that.

03What a receipt is not
Asked forIn a receipt?Why
The input promptNoPayload-free by design. Run inputs may be PHI/PCI/privileged.
The model outputNoSame reason. The chain proves a run happened, not what was said.
User identityNoReceipts pin tenant + device fingerprint only. PII never recorded.
Artifact hashYesAuditor can verify against the registry the team uses.
K-score + gateYesQuality gate held at compile and at run.
Device classYesOS + arch + memory class for the auditor — not a serial number.
Wall-clock timestampsYesSo the chain orders. Times are run-issued, not authoritative.
Egress counterYesHarness-measured bytes-out per run. Used in compliance proofs.
04Verify offline

The chain checks without us.

Hand the receipt JSON to a clean machine, point at the .kolm, run kolm inspect. No network call to kolm.ai. The chain checks the artifact SHA, the K-score signature, and the ring HMACs against the customer-managed key.

# 1) Fetch receipt JSON (or paste it from email/Slack/an auditor)
curl https://kolm.ai/v1/receipt/e176bc2f720b94a8 > receipt.json

# 2) Verify against the local artifact + key kolm inspect receipt.json --artifact support-triage.kolm --key kms://...
## prints: OK
##         chain ok, artifact sha matches, K=0.94 at gate 0.85
##         all four rings cross-link, latest ring signed 2026-05-16T07:18:33Z

The verify path is the same the compliance package export at /v1/account/compliance-package runs over the last 90 days of run-records, so the audit packet you hand to a privacy officer is the same bytes they can re-check on their own machine.

05Receipts as a public artifact

Drop one in an email.

Every run can produce a public-shareable receipt link. Paste it under an output, drop it in a model-card on Hugging Face, attach it to a PR — the receipt is a one-line proof that the bytes came from a named, signed, gated artifact.

# In a sales email or a model-card
This response was generated by kolm/support-triage@sha256:e176bc2f,
K=0.94, on device, no egress.
Verify: kolm.ai/r/e176bc2f720b94a8