Constraint actions: warn, suggest, and block

When you attach constraints to a policy, each one declares an action that decides what happens if it fires on a response: warn, suggest, or block. When several constraints fire at once, G8KEPR does not stack their effects — it resolves them by priority and applies a single outcome to the response.

The three actions

• ▸`warn` — The response is allowed through unchanged. The constraint match is recorded so you can review it later. Use this to observe a rule in the wild before enforcing it.
• ▸`suggest` — The response is allowed through, but G8KEPR returns a safer, corrected alternative alongside it. Your application can present the suggestion, swap it in, or ignore it. Use this for soft guardrails where a human or agent stays in the loop.
• ▸`block` — The response is stopped and never returned to the caller. G8KEPR returns a policy denial instead. Use this for hard rules you never want crossed.

How priority resolves multiple matches

Actions are ranked from least to most restrictive: warn < suggest < block. When more than one constraint fires on the same response, the most restrictive action wins, and only that outcome is applied.

1. 1.G8KEPR evaluates every constraint on the policy against the response.
2. 2.It collects the action of each constraint that matched.
3. 3.It applies the single highest-priority action — a block always overrides a suggest, and a suggest always overrides a warn.
4. 4.Every match is still recorded, even the ones that were overridden, so the full picture appears in your logs.

Choosing an action

• ▸Start new rules on warn to measure how often they fire without affecting traffic.
• ▸Promote to suggest when you want a corrected output but not a hard stop.
• ▸Reserve block for violations that must never reach the caller.

To see which constraints fired on a given response and the action that was applied, check your verification logs or review your policy configuration.