Every change to your AI, sealed as evidence.
A prompt edit, a model swap, a permission grant. CooL commits each one to a signed, tamper-evident record — then hands you a verifier we do not control, so you never have to take our word for any of it.
01 — Install
One line. Then it is watching.
No proxy to stand up, no sidecar to run, nothing rewired in your inference path.
It finds every surface that can change.
You do not enumerate them. Prompts, models, permissions and tools are discovered where they already live.
Every edit becomes an event.
A temperature nudge and a permission grant are the same kind of thing here — a change, with an author and a time.
And every event lands in one sealed record.
Signed where it happened, ordered in a log that cannot be rewritten behind you.
02 — The record
The record is an object, not a log line.
It has fields, a signature, and a position in a log — all of which you can hold up to the light separately.
It travels with the change.
Into your SIEM, your ticket, your audit folder. The same bytes every time, with nothing added on the way.
And it checks out anywhere.
Offline, on a laptop you own, against a verifier we do not control.
- core
- prompt.system · v41 → v42
- author
- d.okafor@ · policy PR-2291
- binding
- sha256:9f2c…4e1a
- signature
- ML-DSA-65 + Ed25519
- log_entry
- leaf 148 202 · RFC 6962
Splunk
cool:change · indexed
Jira
AUD-2291 · attached
S3
evidence/2026-08/
03 — Console & reports
Then you just look.
Every sealed change across every model, in one place, the moment it lands.
Ask it what an auditor would ask.
Which prompts changed under scope last quarter, who approved them, and what did the verifier say. Two clicks, not two weeks.
Take the whole quarter as one file.
Signed, ordered, and checkable by someone who has never heard of us.
cool console · evidence
2026 Q2 · all surfaces
Changes sealed
12,847
this quarter
Surfaces watched
63
auto-discovered
Verify failures
0
12,847 checked
Median seal
41ms
out of band
Sealed changes · 12 weeks
Live
- prompt.system v41 → v42d.okafor ✓
- model.router gpt-4o → o3ci-bot ✓
- perm.db write granteds.raman ✓
- tool.web search enabledd.okafor ✓
evidence-pack-2026-Q2.zip
12,847 records · 1 signed manifest
04 — What it costs you now
The saving is not the sealing. It is never assembling any of this again.
Typical figures for a mid-size estate. The left column is what collecting this evidence by hand actually takes; the right is what the pipeline above produces as a side effect of running.
Prove what changed in a prompt, and who approved it
git archaeology, Slack, memory
one query
Assemble an evidence pack for one audit period
screenshots and spreadsheets
signed manifest
Answer “has this record been altered?”
nothing to check against
offline, on your machine
Onboard a new model to the same guarantees
bespoke logging per surface
discovered automatically
05 — Live, on your machine
Everything above was drawn. This part runs.
Real deterministic CBOR, real SHA-256 commitments, real ML-DSA-65 + Ed25519 signatures and a real RFC 6962 log — executing in this tab, with no server involved. Then forge the receipt and watch the same verifier reject it.
One AI change, sealed and verified live in this tab. Then try to forge it.
−Score this applicant and return approve or decline.
+Score this applicant and return approve or decline, with the top three contributing factors.
Runs entirely in this tab. No server, no account, nothing uploaded.
The pipeline
0/8
Capture the change
SIMULATEDThe SDK hook fires the moment the prompt changes. Async, buffered, fail-open — it never adds latency and never breaks inference.
cool-sdk · CI/CD · gateway hook
Queue it out-of-band
SIMULATEDThe event lands on a durable queue inside the customer's own network. Nothing sits in the critical path of the model call.
Rust ingest → Redpanda / NATS
Canonicalise to fixed bytes
REALThe record is encoded as deterministic CBOR (RFC 8949 CDE), so the same logical change always produces the exact same bytes on every machine.
Evidence engine (Rust in prod)
Commit with a hash
REALSHA-256 over those bytes becomes the binding hash — a fingerprint of the whole change. Alter one character anywhere and it no longer matches.
Evidence engine
Seal it — post-quantum
REALSigned twice over: ML-DSA-65 (FIPS 204, quantum-resistant) and Ed25519 (classical). Both must verify, so the seal holds for the ten-year retention horizon.
Hybrid signer · HSM / TEE-held keys
Append to the log
REALThe commitment is appended to a tamper-evident Merkle log (RFC 6962 — the mechanism behind Certificate Transparency) and a Signed Tree Head is issued.
Transparency log · Trillian / Rekor
Do the paperwork
SIMULATEDPolicy decides what this change needs, then the workflow writes the change doc, records the approval, files the compliance entry and notifies security.
OPA policy · Temporal · Jira / Slack
Prove it, without us
REALThe receipt is checked offline against the keys it carries. Anyone — an auditor, a regulator, a customer — can run this exact check without asking CooL for anything.
cool-verifier (offline)
Evidence appears here
Press Ship this change and watch one prompt edit turn into a sealed, provable, fully documented record — with nobody doing the paperwork.
Case study
Worked example · not a customer deploymentRetail lending · RBI-regulated
An adverse-action prompt changes on a Tuesday. In March, a regulator asks why.
A credit-scoring assistant declines applicants and must explain why. In April an engineer edits the system prompt to return the top three contributing factors; in May the router is moved from GPT-4o to o3; in June a permission grant lets the agent read a new bureau feed. Each is routine. Together they mean the model that declined an applicant in April is not the model that would decline them in June — and the bank has to be able to say which one ran.
How it goes today
Three separate systems hold part of the answer: git history, a Slack thread, and a ticket nobody linked.
The prompt change has no approver recorded anywhere durable — the reviewer approved it verbally in standup.
Logs proving what ran sit on servers the bank controls, which is exactly the party with a reason to edit them after a complaint lands.
How it goes with CooL
Each change is sealed as it happens, with its author, its policy reference and its position in an append-only log.
The April receipt is retrieved by date and shows the exact prompt, the exact model version, and who approved it.
The regulator's own analyst verifies the receipt offline, with the published verifier, without contacting the bank or us.
Time to answer “which model ran on 14 April?”
One query
The console filters sealed records by date and surface; the demo shows the record shape.
Evidence pack for the audit period
One signed file
A single export with a signed manifest, rather than an assembled folder of screenshots.
Independent verification
Offline, ~200ms
cool verify --offline on the regulator's own machine. Network requests during verification: 0.
Figures describe what the pipeline produces, not a measured customer result. You can reproduce each of them on this site: the live demo seals the record, the verifier checks it offline, and the readiness ladder states what is still simulated.
Talk about your workflow- What does CooL actually record?
- Every change to the behaviour of your AI system: a prompt edit, a model or version swap, a temperature change, a permission grant, a tool being enabled. Each one becomes a signed record containing what changed, from what to what, who did it, under which policy, and when. The record is committed to an append-only transparency log, so its position in history is provable rather than asserted.
- Do I have to change my inference code?
- No. Capture is out-of-band and asynchronous — it never sits in the request path of a model call, adds no latency to inference, and fails open. If CooL is unreachable your AI keeps serving; what could not be queued is counted and written as a signed entry rather than silently dropped.
- What can CooL not prove yet?
- Two things, and both are enforced in the verifier rather than in the marketing. Hardware attestation reports as simulated: this build has no vendor-rooted TEE quote, so it cannot prove which machine produced a record. And there is no independent witness co-signing the log, so consistency rests on our log alone. Run the verifier with --require-hardware against a record sealed a minute ago and it refuses. A demo that could only go green would prove nothing.
- Why should I believe any of this?
- You should not, and the product is built so you do not have to. The verifier is published on npm as cool-nwc, it runs entirely offline, and it will reject a record we produced if that record is wrong. The demo on this site runs the real cryptography in your own browser — real ML-DSA-65 and Ed25519 signatures, a real RFC 6962 Merkle log — with no server involved, and it includes buttons that forge the receipt so you can watch the same verifier reject it.
- What does it cost, and what happens to my data?
- The receipt format, the verifier and the SDK are open and free — anyone can issue and check a CooL receipt without paying us or asking us. The commercial product is the compliance work around the record: a managed transparency log, witnessing and timestamping, compliance mapping, and enterprise or on-premise deployments. Your evidence, prompts and personal data stay inside your own boundary; that split between control plane and data plane is architectural, not a policy promise.
06 — Start
Don't trust it. Check it.
Install the verifier, take a receipt this site produced in your browser, and run it on your own machine with the network off.
npm install -g cool-nwc
cool verify ./change-receipt.json --offline