Why every Kauzio decision gets a signed, public certificate that updates with the outcome
Why every Kauzio decision gets a signed, public certificate that updates with the outcome
Every Kauzio decision is issued as a signed, public certificate. KZ-YYYY-NNNNNN numbering, HMAC-SHA256 event chain, public verify URL. The certificate keeps updating as the outcome lands. Here is why that matters for trust, audit and regulated sales.

Jaswant Singh
Co-Founder & CEO, Kauzio
A decision receipt that never updates is a snapshot. Useful, but limited. Six weeks after the call, you can prove what you decided and when. You still cannot prove whether it worked.
That is why every Kauzio decision is issued as a living certificate. The certificate is signed at the moment the decision is made, and then keeps appending signed events as the outcome lands. Thirty days in. Sixty days in. Beyond, if the decision has a longer horizon.
Each certificate has a number in the shape KZ-YYYY-NNNNNN. The year, then a zero-padded sequence inside that year on your workspace. The number is stamped on every event in the chain, so the whole life of the decision lives under one identifier.
How the chain works
Every event on the certificate is a row with three things. The payload, which is the decision data or the outcome update. A timestamp. And an HMAC-SHA256 signature that covers both the current payload and the signature of the previous event.
Because each signature folds in the previous one, the chain is tamper-evident. Change any event in the middle and every signature after it stops verifying. The whole history has to be intact for the chain to validate.
The signature is computed against a per-tenant key. Anyone with the certificate URL can run the verification, because the public verify page recomputes the chain on the fly and shows the result. They do not need an account. They do not need to trust Kauzio's word. They check the hash.
A worked example, framed as illustrative
Here is what a timeline looks like on a hypothetical decision. Numbers are for illustration, not a real customer. Suppose the decision is a retail price rise on a flagship product, with an expected lift in category margin of around 220 basis points.
Event 1, day 0. Issued. The certificate is created. The payload contains the decision question, the six-axis scores, the verdict, the expected outcome band of 180 to 260 basis points, and the names of the people in the room. The signature is computed and stamped.
Event 2, day 30. First checkin. Kauzio reads the actual margin movement from the connected sales data. It writes the observed value, 240 basis points, into the chain as a new event. Signature folds in the issued event. The certificate now shows a delta of plus 20 basis points against the midpoint of the expected band, comfortably inside the range.
Event 3, day 60. Second checkin. Kauzio reads the value again. This time it is 195 basis points, after a competitor matched the price. The new event is appended and signed. The delta now reads minus 25 against midpoint, still inside the band but trending toward the lower edge. The certificate page makes the trend visible.
That is the loop. Issue, checkin, checkin, with the outcome data signed in alongside the original prediction. Anyone reading the certificate two years later can see not just what was decided, but how the call actually played out, in numbers nobody could edit after the fact.
Why this matters for trust
The first thing a buyer wants to know about an AI decision system is whether it is honest about its mistakes. A signed certificate that updates with the outcome forces that honesty into the public record. Predictions and outcomes sit on the same page, under the same signature. There is no version of events where the failure quietly disappears.
This is the difference between a vendor that markets accuracy and a vendor that publishes it.
Why this matters for audit
A board, an investor, a regulator or a new CEO asks why a decision was made. With a normal log, you reconstruct from memory and email. With a signed certificate, you open the URL. The argument that actually happened is there. The dissent is preserved. The outcome is attached.
For a finance or compliance team, the certificate is also a clean artifact to drop into the audit file. It has a number, a signature, a timestamp, a public verify endpoint. It is the kind of evidence an auditor can hold without asking follow-up questions.
Why this matters for regulated buyers
Selling AI to a regulated business is slow because the buyer is right to be cautious. They want to know who decided, on what evidence, with what expected outcome, and what actually happened. They want it in a form they can hand to their second line of defence.
A living certificate gives them that without bespoke work. The decision, the prediction, the outcome and the signature are all in one place, on a URL that does not require login. For regulated buyers, this often removes the single biggest blocker to deployment.
See a sample
We keep a live example open to the public. It is a sample certificate, with the six axis scores, an issued event and two checkin events, rendered through the public verify endpoint.
You can open it at /verify/sample. No account, no signup. Run the verification yourself and see the chain return green.
A decision you cannot prove you made carefully is, at the end of the day, a story. A decision that comes with a signed certificate, updated with the outcome, is a record. That is the standard Kauzio works to, and that is why every decision gets one.
Read next
The six ways we attack every Kauzio decision
The six ways we attack every Kauzio decision
May 20, 2026 · 4 min read
How we measure Kauzio's accuracy, per sector
How we measure Kauzio's accuracy, per sector
May 20, 2026 · 4 min read
The 5 business decisions that quietly cost the most
The 5 business decisions that quietly cost the most
May 18, 2026 · 3 min read
