Skip to content
Kanonik
Menu
Help
Browse Help
On this page

When you and the safety check disagree

You have the final say. Your decision, and your reason, become part of the record.

Every change your AI proposes runs through a safety check before it reaches you, and you always have the final say. This article explains what the safety check does, what happens when it disagrees with a change you want to make, and why your decision in that moment becomes a permanent part of your record.

This works the same way for every framework Kanonik supports. It is about how a change gets checked and approved, not about any one standard.

The order things happen in

When you ask your AI to commit a change, three things happen in sequence, and the order matters:

  1. A quick structural check (the lint). Kanonik first checks the obvious things: required fields are filled, the format is right, there is no placeholder text left in, the wording is not a template. The lint is fast and catches simple mistakes early.

  2. The safety check (the verifier). Then a check runs on Kanonik's servers. It looks at the substance of the change against your framework and the evidence in your record, and reaches a verdict: the change looks sound, the change needs a human to look closely, or the change should not go through. This check runs on the server and cannot be skipped or talked out of by the AI that proposed the change.

  3. Your approval. Only after the verdict exists does the change come to you to approve, and you see the verdict and the reasoning behind it before you decide. You are never asked to approve something the safety check has not looked at yet. You approve knowing what the check concluded.

That third point is the change worth understanding: you decide with the verdict in front of you, not before it.

When the check is happy

If the safety check finds the change sound, you see that verdict, tick that you have reviewed it, and approve it. Nothing unusual happens, and the record simply shows that the check passed and you approved.

When the check passes but still flags something

A change can pass the safety check and still carry points worth your attention. When that happens the approval page says so plainly: it reads "Passed, with open findings to review" rather than a bare "Passed". The check let the change through and noted specific things it wants you to see first, such as a control that is mapped but has no evidence behind it yet.

You still approve it the usual way when you are satisfied. The findings are not a blocker and they do not force a second step. They are recorded alongside the change, so the state you approved in is on the record: an auditor sees that the change passed, that these points were open at the time, and that you approved with them in view. You see the same verdict wherever you meet the change, in your queue and on the approval page, so the two never tell you different things.

When the check asks for a closer look

Sometimes the check cannot reach a confident verdict on its own and asks for a human to look closely. Nothing is blocked; the check is telling you where to spend your attention. You look at the change, and if it is right, you approve it. The record shows that the check flagged it for review and that you reviewed it and approved.

When the check says no, and you disagree

Sometimes the safety check recommends against a change, and you, with context the model does not have, know the change is correct. You have the authority to override the check and approve anyway. Kanonik does not take that decision away from you.

What Kanonik asks in return is simple: acknowledge that you are overriding the check, and write one line on why. For example, the check may have misread the scope of a control, and the mapping is correct for a reason that is plain to you and was not plain to the model. You write that reason, you confirm, and the change goes through.

Today you override from the emailed link, for a request that holds that one item. In a request with other items, a rejected item cannot be approved over the rejection: the other items can still go on your record, and you send the rejected one back or ask your AI to revise it. See Deciding on an approval request, item by item.

That acknowledgement and that reason become a permanent part of your record. They are written into the same tamper-evident log as the change itself, and they cannot be quietly edited or removed later: the log would show it. Anyone who reviews your record afterward, including an auditor, sees the full picture: the check recommended against this change, this named person overrode it, on this date, for this stated reason.

In the Audit log, a change the check flagged reads "Flagged", never "cleared". It shows what the check found, who approved it anyway and the words they recorded. If no reason was recorded for an approval over a flag, the entry says so plainly.

This is the point of it. An override that no one can see looks like the safety check was ignored. An override that is acknowledged, reasoned, and on the record looks like what it is: a qualified person made a judgement call and stood behind it. The acknowledgement shows you meant to do it. The reason shows why. Together they turn a disagreement with the model into a defensible decision.

You are the authority, and the record proves it

Kanonik's safety check is there to catch what you might miss, not to overrule you. You hold the final decision on every change. The difference between Kanonik and a tool that simply blocks you is that here your authority is explicit and your judgement is recorded, so the decision stands up later.

If your organisation wants a stricter posture, an administrator can set the safety check so that a recommendation against a change is a hard stop with no override. That is a choice you make as a team. The starting point is that you decide, and your decision is on the record.

While the check runs

For a single change the check is quick. For a large set of changes approved together, the check may run over many items, so Kanonik runs it in the background and brings the set to you when it is ready, rather than making you wait on a loading screen. You see the progress as it works, and the set arrives for your approval with every verdict already in hand. However many items you are working with, the check runs on all of them, and you approve them knowing what each verdict said.

More help

Browse every article in the Help center. For anything else, email [email protected] and a person who works on the product answers.