# Rule Validation

Fordefi checks each policy rule as you build it and flags condition combinations
that can never match a transaction. Instead of discovering a misconfigured rule
later, you see the problem at the moment you create or edit the rule.

alt
This matters because a rule that can never match creates a false sense of
security: you may believe a transaction type is protected by a rule that will,
in practice, never take effect. Rule validation surfaces these issues at
creation or edit time.

Validation runs only while you author a rule — when you create or edit it. It
never changes how existing rules are evaluated. See
[Rule Conditions and Actions](/user-guide/policies/policy-rules-conditions-and-actions) for the
full list of conditions and the table of which conditions apply to which
transaction types.

## How validation works

Rule validation surfaces warnings inline, next to the conditions that cause
them. A warning never blocks saving, and Fordefi never changes your rule for
you: you acknowledge the warning and can still save the rule as it is. This lets
you catch a misconfigured rule at authoring time without being forced into a
change you did not intend.

## Incompatible condition combinations

Fordefi warns when a rule combines conditions that can never match a
transaction. Most stem from a condition applying only to specific transaction
types or blockchain families — the same compatibility summarized in
[Conditions and transaction types](/user-guide/policies/policy-rules-conditions-and-actions#conditions-and-transaction-types).

The following are some of the most common:

### ABI

The ABI condition applies only to EVM contract calls. It conflicts with:

- A Transaction type other than Contract call. Because customers use ABI
conditions with the Allowance type to match `approve` calls, that combination
is allowed.
- A non-EVM vault in the Origin condition.
- A non-EVM vault, contact, or DApp in the Recipient condition.
- A non-EVM token in the Asset condition.
- An EVM typed message condition in the same rule.
- A Cosmos message condition in the same rule.


### Cosmos message

The Cosmos message condition applies only to Cosmos contract calls. It conflicts
with:

- A Transaction type other than Contract call.
- A Recipient condition.
- A non-Cosmos vault in the Origin condition.
- A non-Cosmos vault, contact, or DApp in the Recipient condition.
- A non-Cosmos token in the Asset condition.
- An EVM typed message condition in the same rule.
- An ABI condition in the same rule.


### EVM typed message

The EVM typed message condition applies only to the EVM Typed data message
transaction type. It conflicts with:

- Any Transaction type other than EVM Typed data message. Because customers use
this condition with the Allowance type to match permits, that combination is
allowed.
- A non-EVM vault in the Origin condition.
- A non-EVM vault, contact, or DApp in the Recipient condition.
- A non-EVM token in the Asset condition.
- A Cosmos message condition in the same rule.


### Recipient

The Recipient condition conflicts with:

- A Transaction type of EVM Personal message, Non-EVM message, or Black-box
signature.
- A Cosmos message condition in the same rule.


### Asset

The Asset condition conflicts with a Transaction type of EVM Personal message,
Non-EVM message, or Black-box signature.

### Transaction amount and Periodic amount

The Transaction amount and Periodic amount conditions conflict with a
Transaction type of EVM Personal message, Non-EVM message, or Black-box
signature.

## Partially applicable conditions

A single rule can select more than one transaction type. When a condition
applies to some of the selected types but not all of them, validation shows a
non-blocking warning that you must acknowledge before saving. The rule still
matches the applicable types; the condition simply has no effect on the others.

## Editing existing rules

Rules created before rule validation are never modified by Fordefi. A rule
continues to evaluate exactly as it did before validation shipped. Validation
applies only when you author a rule.

When you open an existing rule whose conditions form a combination that
validation would flag on a new rule:

- A banner appears and the affected conditions are highlighted, explaining the
issue.
- You can still save the rule unchanged. This lets you make an unrelated edit
without being forced to re-architect the rule.
- If you resolve the issue during the edit, the banner and highlights clear
automatically, and saving proceeds through the standard validation path.


Creating or duplicating a rule
The same warnings appear when you create a new rule or duplicate an existing
one. As everywhere, a warning never blocks saving — you acknowledge it and can
save.

In the policy rules list and rule detail views, rules that contain a flagged
combination are marked with an inline indicator so you can find and review them
proactively. No action is required from these views.