# Understand Policy Decisions When a transaction is blocked, requires approval, or is allowed, the outcome is decided by your [transaction policy](/user-guide/policies). The **Policy Explanation** view shows you *which* rule decided the outcome and *why* — a human-readable, per-rule breakdown of how your transaction was evaluated, so you can confirm expected behavior or debug an unexpected one without contacting support. Who can see the explanation Policy Explanation is available to **admins**, who can view policy rules. **Traders** don't see policy rules, so they can't view the explanation directly — instead, a trader can copy a link to the explanation and share it with an admin, who can analyze it further. See [Share an explanation](#share-an-explanation-traders). ## What's supported - Policy Explanation covers **transaction policies**. It is not available for [AML policies](/user-guide/aml/aml-policies). - Explanations are available for transactions whose policy hasn't changed since evaluation. ## Where to find the explanation You can open Policy Explanation at two points in a transaction's lifecycle: - **Before you create a transaction (prediction).** When you preview a transfer, swap, or allowance revocation on the web console or the browser extension, Fordefi shows the policy decision. Click **Explain this match** to see which rule applied and why. - **After a transaction exists.** Open the transaction, go to the **Timeline** tab, and click **Explain this match** to see which rule matched and why other rules did not. In both cases you're taken to the Policy Explanation screen, where the explanation is shown as an overlay on the familiar policy rules view. Viewing on mobile The Policy Explanation screen is designed for desktop. On mobile, Fordefi shows a link to the explanation instead of the full view — open it on a desktop browser to see the breakdown. ## The Policy Explanation screen The screen has two parts: - **The policy rules list** (left): The same ordered list of rules from your [transaction policy](/user-guide/policies#policy-structure), with a status badge on each rule showing how it was evaluated against this transaction. - **Transaction Inputs** (right): A fixed panel showing the exact values that were fed into the policy for this transaction (initiator, origin, recipient, amount, and so on). For each condition type, it shows the transaction's value plus any related grouping or enrichment, so you can see the transaction exactly as the policy engine saw it. alt Because the policy is evaluated top to bottom and [the first matching rule wins](/user-guide/policies#policy-structure), reading the list from the top tells the whole story: the rules above the match did not apply, the matched rule set the outcome, and the rules below it were never reached. Empty and not-applicable values To keep the panel readable, conditions that don't apply to the transaction are shown compactly (for example, as a dash) rather than as long "none" entries. ### Rule evaluation statuses Each rule in the list carries one of the following status badges: | Status | Meaning | | --- | --- | | **Matched** | The transaction satisfied all of this rule's conditions. This is the rule that determined the outcome. Only one rule matches. | | **Unmatched** | The transaction did not satisfy at least one condition, so the rule was skipped and evaluation continued to the next rule. | | **Skipped** | The rule was never evaluated because an earlier rule already matched. Rules below the matched rule are always skipped. | | **Indeterminate** | A condition could not be evaluated for a temporary, system-level reason (not a policy mismatch) — for example, a failed simulation, an unavailable asset price, or an RPC outage. Fordefi could not confirm whether the rule matched. | alt The **Default policy rule** at the bottom of the list matches any transaction, so it applies whenever no rule above it matched. See [the default rule](/user-guide/policies#policy-structure). ### The matched rule's condition breakdown Expand the matched rule to see how each of its conditions (matchers) was evaluated — Initiator, Origin, Transaction type, Recipient, Asset, Amount, ABI, EVM Typed Message, Cosmos Message, and so on. Each condition shows its own status so you can see exactly why the rule matched. A rule's overall status is composed from its conditions: - **Matched**: Every *required* condition matched. - **Unmatched**: At least one condition definitively did not match. (This is enough to fail the rule, even if other conditions were Indeterminate.) - **Indeterminate**: No condition definitively failed, but at least one required condition could not be evaluated, so the match can't be confirmed or ruled out. Indeterminate conditions on a decided rule A rule can still resolve to Matched or Unmatched while one of its conditions is Indeterminate. When that happens, the Indeterminate condition is still surfaced with its reason, so you understand exactly what could and couldn't be evaluated. ### Unmatchable values Some transactions can't produce a value for a given condition. When that happens, the input is marked **Unmatchable** with an explanation, so you understand why the transaction can only match rules where that condition is set to **Any**. The most common case is the **recipient**. A recipient is unmatchable for transaction types that don't specify a recipient in a standard way: | Transaction type | Why the recipient is unmatchable | | --- | --- | | EVM Personal Message | Personal messages don't specify a recipient — they aren't associated with any DApp address or counterparty. | | Non-EVM message | Non-EVM message types don't carry recipient information in a standard way. | | Black-box transaction | The payload is opaque, so no recipient can be extracted. | The **transaction amount** can also be unmatchable or effectively infinite: - **Infinite (no price)**: The outgoing token has no price, so its value can't be compared against an amount condition. - **Infinite (unlimited allowance)**: An unlimited allowance has no fixed amount to compare. - **Unmatchable (by type)**: The transaction type has no amount to evaluate. In each case the input states the reason explicitly instead of showing a raw or misleading value. ## Act on the explanation ### Open and edit the policy (admins) When an outcome doesn't match your intent, open the relevant rule directly from the explanation and adjust it — for example, widen an amount, add a recipient, or reset an exhausted periodic amount. See [Edit transaction policy](/user-guide/policies/create-a-policy-rule). Policy changes require [Admin Quorum](/user-guide/admin-quorum) approval. ### Share an explanation (traders) A trader who is blocked by policy can copy the explanation's link and send it to an admin. The admin opens the link on desktop to view the full breakdown and, if needed, adjust the policy. Explanations reflect the policy at evaluation time An explanation is only shown while the transaction policy hasn't changed since the transaction was evaluated. If the policy was edited in the meantime, Fordefi shows a snapshot disclaimer, because the current rules may no longer reflect how this transaction was decided. Learn more: - [Set policies](/user-guide/policies) - [Rule conditions and actions](/user-guide/policies/policy-rules-conditions-and-actions) - [Edit transaction policy](/user-guide/policies/create-a-policy-rule) - [Best practices for policies](/user-guide/policies/best-practices)