> ## Documentation Index
> Fetch the complete documentation index at: https://docs.walletsuite.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Policy Decisions
> Every signing intent is evaluated, stamped with a decision id, and recorded, including the denials.
Every signing intent that reaches WalletSuite is evaluated by the policy decision point before any share is released. Each evaluation produces a **decision record**: a durable row in the signing-intents ledger that says what was requested, what the policy decided, and why. Allowed and denied intents alike are recorded. The denials are first-class evidence, not dropped requests.
This is the artifact a compliance or treasury reviewer asks for. You can show not only what your agents signed, but every request the policy stopped and the exact rule that stopped it.
These are **decision records** in an append-only audit ledger. They capture the authorization decision at the point the policy engine makes it. They are not a substitute for on-chain confirmation. Pair them with the transaction hash to prove end-to-end execution.
## What every decision records
The policy decision point stamps each intent with a fresh decision id and the outcome. The same fields are present whether the intent was allowed or denied.
| Field | What it records |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- |
| `policyDecisionId` | A fresh identifier for this one evaluation. Allow and deny rows both carry one, so every decision is traceable to exactly one evaluation |
| `decision` | `allow` or `deny` |
| `reason` | The stable reason string for the outcome (see below) |
| `matchedRuleId` | The allowlist rule that admitted the operation, when a rule was involved. Null for chain-layer allows and for denials |
| `state` | The intent lifecycle state. A denied intent lands in `denied` and stays there |
| `chain` | The chain the intent targeted |
| `operationType` | The typed operation the intent resolved to |
The record lives in the partitioned `signing_intents` ledger, org-scoped and time-ordered. A denied intent persists with the same provenance an allowed one carries, so the history of stopped requests is as complete as the history of signed ones.
## A denied intent never releases the share
The decision record is not advisory: when the policy denies an intent, WalletSuite persists a `denied` row, and the record and the enforcement are the same event — no signature is produced, so a denied intent cannot be signed. See [Policy Gates → What a Deny Does](/core-concepts/policy-gates#what-a-deny-does).
An allowed intent is the mirror image. The evaluation stamps its `policyDecisionId`, records the matched rule, and unlocks one signature bound to that exact payload. See [Signing Intents](/mpc/signing-intents).
## Decision reasons
Every outcome carries a stable reason string. Treat these as part of the contract. They surface in the ledger and drive downstream reporting.
| Reason | Outcome | Meaning |
| ------------------------- | ------- | -------------------------------------------------------------------- |
| `no_rules_configured` | allow | The org has no active allowlist rules, so the allowlist layer passes |
| `allowlist_match` | allow | An active rule matched the operation |
| `chain_not_entitled` | deny | The intent's chain is outside the chains the caller is entitled to |
| `entitlements_unresolved` | deny | The caller's chain entitlement could not be resolved |
| `unclassified_operation` | deny | The operation could not be typed |
| `no_matching_rule` | deny | Rules are active and none admitted the operation (deny-by-default) |
Your allowlist rules are opt-in and deny-by-default once armed, and every intent is bounded by the chains you're entitled to. See [Policy Gates](/core-concepts/policy-gates#how-rules-work).
## Evaluation modes
The decision point runs in `off`, `shadow`, or `enforce` — see [Policy Gates → Off, Shadow, Enforce](/core-concepts/policy-gates). In every mode the decision record is written, so shadow proves how the policy would behave against real traffic before it starts blocking.
## Related
Create, list, and deactivate the allowlist rules that drive decisions.
How a cleared decision unlocks one signature.
The hash-chained signing-layer log that complements platform decision records.
How a policy denial surfaces to the caller.