Give AI a job. Set its limits.
ZAK checks whether a connected action is allowed before it happens. Keep the request, permission, evidence and result together.
Illustrated scenario · no live execution
Why did we release it?
Start with the decision record.
- Who approved?
- The appointed release owner.
- Approved what?
- Release 42 to the customer portal.
- Which rule?
- Release rule, version 7.
- What did they see?
- The change, functional checks, security review and rollback plan.
- AI permission?
- Prepare only. The release service had separate authority to deploy version 42.
- What happened?
- The release service recorded deployment of version 42 at 09:14.
Put it to work.
Start with what needs to happen. Make the next decision clear.
The request
Identify the exact action, actor, affected resource and intended result.
Authority and evidence
Resolve who can permit that action and what evidence the current rule requires. Missing authority cannot be supplied by an AI recommendation.
The decision
The checks let work proceed, limit it, stop it or hold it for review.
Technical detail: the decision
Deterministic admission checks allow, restrict, deny or defer the action. An admitted capability carries out the permitted work.
The receipt
Keep a record of what was allowed and why. Record what happened as well. Permission to act is not proof that the action finished.
Technical detail: the receipt
Bind the recorded decision to its request and basis. Record execution outcomes separately where the action requires them. Verification depends on the actual receipt class, signer and storage path.
The connection
Governor API and MCP are entry points into this execution spine. Your team must connect the actual action boundary and confirm its enforcement and evidence requirements.