Skip to main content
Every Rule release has a mode: Disabled, Observe, or Enforce. There is no target-wide mode switch. Mode and effect are different: an Allow rule can match without asking for a block.

Modes

Basic manual/CLI creation starts Disabled. Discovery may explicitly create in Observe. Web Activity proposals use Observe, and source-update replacements return to Observe. Check the mode shown before saving or applying a review.

Allow and Block

Before-action rules can express ALLOW or BLOCK. Actions normally use block-only: no blocking match means the action can proceed. Creating an Allow rule moves its covered actions to allow-block, which records explicit Allow, Block or Undetermined outcomes. Only an enforced Block prevents execution; Undetermined is not an enforced deny. An Allow match does not override an enforced Block from another applicable Rule. When only Observe releases block, the effective disposition is Would block; if an Enforce release blocks, it is Block. Test the combined active set as well as the Rule you are reviewing. Allow rules apply before actions, not as an Allow authoring option for response or result rules. An action with an active Allow rule cannot return to block-only until that covering Rule is disabled or archived.

Decisions need an enforcement boundary

The policy API returns a decision. Your SDK callback or direct integration must honor it before the effect. A guard on one path cannot protect another path that bypasses it. An Executed receipt means the handler was invoked, not necessarily that it succeeded. No receipt means the applied outcome is unconfirmed. Traces combine policy evidence with actual runtime reports.

When the contract changes

Only releases whose contract dependencies changed are disabled. Unrelated action catalogue changes do not disable every release. Review affected Rules, recompile and explicitly choose a mode again. Restoring an archived Rule family also leaves it Disabled.

Failure behavior

Evidence upload is best effort and must not fail the host agent. SDK policy guards permit execution on availability failures such as network errors, timeouts, 5xx or rate limits. They do not silently ignore deterministic authentication or malformed-request failures. A valid enforced Block is honored. A client with no Connection key is disabled and executes unguarded. Some additive endpoints have compatibility fallbacks on older servers; see Result filtering, Python, and Codex for their exact boundaries. Verify the integration you use rather than assuming every runtime has the same failure semantics.

Promote with evidence

Use a safe test environment, check matching and non-matching examples, then let an Admin enable Enforce for that release. Repeat a blocked example and verify the protected callback did not run. A Rule’s mode alone does not prove that its enforcement boundary is installed.