kolm / community / dev.to article - draft
Dev.to article - draft.
A ~800-word seed article for Dev.to. Markdown source below as a single pre block. Copy, paste into the Dev.to editor, tweak the example to match what you ship that week, set the canonical link to kolm.ai/articles/ai-compiler so reposts do not split SEO.
Markdown source.
# How we ship verifiable AI: the .kolm artifact format
When a hospital's compliance reviewer asks "what model produced this discharge summary on March 14 at 09:23," there are two answers an engineering team can give. The honest answer for a closed-API model is "the one the vendor was hosting under that name, until they updated it." That is not a receipt. The other answer is a single signed file you can hand them. That file is what we built kolm to produce.
## Why receipts matter
The standard regulatory question is some version of: prove what was running. SR 11-7 calls it model risk management. HIPAA calls it the audit trail. NIST AI RMF calls it traceability. The EU AI Act calls it record-keeping. The shape is the same. You need to be able to say, months later, with cryptographic certainty: this exact model, this exact prompt, this exact output, at this exact time.
Closed-API AI cannot answer this. The vendor controls the weights. The vendor controls the version under a name. The vendor controls when an update ships. Your contract says they will tell you, but the artifact your auditor needs is not the contract. It is the manifest.
## RS-1 manifest shape
A .kolm is a zip. Inside the zip is a `manifest.json` with a canonical, sorted-key shape. Everything else in the zip (weights, evaluator, compliance pack, recipe) is referenced by hash inside that manifest.
```json
{
"version": "rs-1",
"kind": "kolm-artifact",
"base": "Qwen/Qwen3-32B",
"task": "phi-redactor-v3",
"compliance_pack": "hipaa-2024",
"k_score": 0.974,
"hashes": {
"weights": "sha256:8c4f2a...",
"evaluator": "sha256:1d29b6...",
"recipe": "sha256:f37290..."
},
"signature": "ed25519:..."
}
```
The CID is computed as `cidv1:sha256:` + hex(sha256(canonical-JSON(manifest))). Canonical-JSON means recursively sorted keys, no whitespace, UTF-8. The hash is reproducible by any verifier. Our SDK's `canonicalJson` is 28 lines of pure stdlib.
## HMAC chain over IO
Compile produces the artifact. The audit story is on the runs. Every `kolm run` emits a receipt:
```json
{
"cid": "cidv1:sha256:c34a91...",
"input_sha": "sha256:bf21...",
"output_sha": "sha256:9c80...",
"ts": "2026-05-15T09:23:11Z",
"mac": "hmac-sha256:..."
}
```
The MAC is computed with a key the operator owns. The verifier never needs the key to check the chain; it only needs the public manifest signature and the input/output bytes. The MAC binds the receipt to the operator's identity for accountability.
This is the shape that makes replay work months later. Hand an auditor the .kolm, the input, and the receipt. They run `kolm verify` offline. The output matches or it does not. There is no ambiguity.
## Verify in 30 seconds
Install once:
```bash
npm install -g kolm
# or: brew install kolm / winget install kolm
```
Verify any artifact:
```bash
kolm verify discharge-summarizer.kolm receipt-2026-03-14.json
# checks signature, recomputes CID, recomputes input/output hashes,
# checks HMAC chain, emits a single line: PASS or FAIL with reason.
```
That command is the shape your CI gates on, the shape your compliance reviewer runs at audit time, and the shape an attacker has to break to forge a receipt. The verifier SDK is MIT-licensed and pure-stdlib. The thing whose job is verifying supply chain has no supply chain.
## What graduates you to kolm
Three thresholds. If none of these are true for you, the closed-API frontier is fine. We say this on the marketing site too.
1. Regulated industry. You are answering to a compliance team, an auditor, or a regulator. Receipts are not optional.
2. Egress cost matters. You are shipping at a volume where 11.6x cheaper at sustained throughput is a real budget line.
3. Air-gap or BYOC. Your customer's data cannot leave their network. You need an artifact that runs there with the same shape.
When you hit one of these, the contract you signed with the closed-API vendor stops being a feature. It becomes a liability your engineering team has to defend at audit.
## Try it
Quickstart at kolm.ai/quickstart is 12 minutes from `npm install` to a verified .kolm on your disk. The PHI redactor tutorial at kolm.ai/tutorials/phi-redactor walks through one end-to-end. The RS-1 spec at kolm.ai/spec/rs-1 is the canonical reference. founders@kolm.ai is the direct line if you want to talk to the team.
Receipts make AI defensible. That is the whole pitch.
Frontmatter suggestions.
Dev.to's frontmatter is YAML at the top. Paste this above the title.
title: "How we ship verifiable AI: the .kolm artifact format"
published: true
description: "Receipts, canonical-JSON manifests, HMAC chains, and the engineering case for verifiable AI in regulated industries."
tags: ai, machinelearning, devops, security
canonical_url: https://kolm.ai/articles/ai-compiler
cover_image: https://kolm.ai/og-card.svg
published: true
description: "Receipts, canonical-JSON manifests, HMAC chains, and the engineering case for verifiable AI in regulated industries."
tags: ai, machinelearning, devops, security
canonical_url: https://kolm.ai/articles/ai-compiler
cover_image: https://kolm.ai/og-card.svg
Post-publish checklist.
Three things after the article goes live:
1. Add the Dev.to URL to /articles as a syndication note on the canonical post. 2. Cross-post to LinkedIn with a 2-sentence summary and the Dev.to link. 3. Watch the comments for an hour. The Dev.to audience is friendlier than HN; reply to every comment in the first day.