Skip to main content
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. 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. 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.

​
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. 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.

​
Evaluation modes

The decision point runs in off, shadow, or enforce — see Policy Gates → Off, Shadow, Enforce. In every mode the decision record is written, so shadow proves how the policy would behave against real traffic before it starts blocking.

Managing Policy Rules

Create, list, and deactivate the allowlist rules that drive decisions.

Signing Intents

How a cleared decision unlocks one signature.

Audit Trail

The hash-chained signing-layer log that complements platform decision records.

Structured Errors

How a policy denial surfaces to the caller.