The rule changed on Friday. The AI didn’t.
Monday’s release puts a new connection live without its required security review. A very productive morning.
Before the releaseWithout the check
The release goes ahead.
The system uses the old instruction. A new connection goes live before the newly required security review.
Rule updated
Release queued
With ZAK checking the action
The missing review comes first.
ZAK checks the release against the current requirement. The missing security review keeps the release on hold.
Yesterday’s permission may not cover today’s action.
Rule updated
Release queued
Here is where
the ending changes.
01
The work is ready.
The team lead has reviewed a software release. It is scheduled for Monday.
02
A new instruction arrives.
On Friday, the release rule changes: a new external connection also needs security review.
03
Go back to the decision to release.
The required evidence must match the action and applicable rule. A person reviews the difference before work moves on.
Where could this happen
in your work?
Start with one action you would like to delegate. Work out the permission, the connection and the evidence it needs.
What would this require in practice?
This situation requires a connected source, a rule requiring current evidence, and a check at release. Detection and timing depend on that integration; it does not imply ZAK discovers every external change.
The scenes show the decision being explained. They are not screenshots of a connected product or records of a customer incident.
Read the scope and limits