Skip to main content
Your policy lives in the repository with the agent. Every push should prove the guarantees it declares still hold against it, in a scratch store, with no network, and fail the build if one does not. That is one workflow step.

​
The policy

runnable

​
The code

Locally, and in the recipe’s directory, the check is one command:
runnable file=run.sh
In CI, the workflow:
Pin CTRLRun/ctrlrun to a release tag once you rely on it.

​
What the agent sees

The agent sees nothing; this is the operator’s check. The build sees:
The first line is on stderr, from G7’s own scenario driving an action with no principal — the guarantee passing, not a problem. Every row names k8s.delete_namespace because verify takes the first action that fits each scenario in alphabetical order; which one appears says nothing about it. The policy line is the resolved absolute path, so yours will differ. Two guarantees are not applicable because the policy has no authority: section; they are listed with the reason and excluded from the denominator. Green means nothing that could be checked was wrong.

​
The receipt

The report is the receipt: --json writes a ctrlrun.verify/v1 document and --junit a JUnit file, and the action uploads both with the badge JSON as one artifact. Exit 0 means every applicable guarantee passed; 1 a failure; 2 a refused or unusable configuration, including mode: observe and a policy in which nothing can be exercised; 3 an internal error.

​
When an AMBIGUOUS appears

Verify’s G5 and G10 make an ambiguous effect on purpose, in the scratch store, and assert that a blind retry is refused. Your store is never opened, so nothing here can leave a real effect ambiguous. An AMBIGUOUS in your own store is the agent’s, and the resolve recipe is for it.

​
Next

Related topics

CookbookVerify in CIWhat verify guaranteesctrlrun verifyExit codes