Skip to main content
A Rule expresses business policy against a declared action, result collection or candidate response. Write it in plain English, review the compiled behavior and required facts, then choose when it should observe or enforce.

​
Choose the protected boundary

After-action rules require resultSchema and resultCollection on that action. They filter returned items; they do not undo the tool call. Before-response rules require a real delivery guard. Codex hooks do not provide that boundary.

​
Create and review

  1. Open Rules for the agent or integration and start rule creation.
  2. Choose the trigger and scope. For a before-action Rule, choose Allow or Block.
  3. Describe the policy and answer any clarification questions.
  4. Review the generated wording, action scope, required context and readiness.
  5. Save the Rule, then test in Observe before enabling Enforce.
For example: “Block calendar invitations to external attendees unless the authenticated user is an admin.” The identity fact must come from your application, not the model’s claim that a user is an admin.

​
When setup is missing

A policy needing undeclared trusted facts can become a Draft in the Current list. Open Review setup and Setup details to see the required schema and agent instructions. Update the integration and sync its inventory, then finish the draft and use Save as disabled. A draft is not an active release and does not govern traffic. Saved draft wording and scope may be read-only during setup; archive and create a new draft when those need to change. Use the Rule detail panel for configuration, code, testing and version history.

​
Releases and activation

Releases are immutable. Editing a Rule produces a new release and preserves history. Basic manual/CLI creation starts Disabled. Discovery can explicitly create in Observe; Activity proposals in the web use Observe, and replacing a Rule through source-update review returns it to Observe. Review the mode shown before applying a batch. Each release records the contract dependencies it was compiled against. A changed dependency disables the affected release; an unrelated catalogue edit does not disable every Rule. Review, recompile and deliberately reactivate affected releases. An Admin enables Enforce. See Observe & enforce for Allow/Block behavior and failure handling.

​
Propose from evidence

Use Propose a Rule in Business context to select documents, captured activity, or both. Review supporting passages, recorded cases, counterexamples and any configuration still required. Combining sources does not itself prove they corroborate each other. The action catalogue can also support suggestions. Risk classification and proposed Rules are guidance; neither enables enforcement automatically.

​
Archive or restore

Archiving a Rule family disables and hides all its releases from the active set. Restoring the family leaves its releases Disabled. Review and explicitly re-enable the desired release. For action and response Rules, match counters count decisions where that release actually matched, not every evaluation or entire trace. Result Rules have related-result counts and should not be interpreted as the same per-Rule attribution.

​
CLI examples

From a connected repository:
If compilation asks a question, repeat the original input and effect and add --context "your answer". See the CLI reference for discovery, saving proposals and lifecycle commands.