12 confirmations can satisfy a configured threshold. That does not automatically mean consensus finality.

Before a transaction is signed, the policy should say:
• the minimum confirmation count;
• whether an RPC-reported finalized block is required;
• the tolerated reorg depth.

These criteria answer different questions. In PriorSeal, CONFIRMATIONS means the configured count has been reached. RPC_FINALIZED additionally checks that the inclusion hash is still canonical, the endpoint’s finalized height covers the inclusion block, and the confirmation floor is met.

If the endpoint cannot provide finalized data, execution stays PENDING. If the canonical inclusion hash changes, it becomes REORGED. Neither status alone proves an authorization violation.

A reorg tolerance of N requires at least N+1 confirmations. It is a buffer, not a promise that deeper reorgs are impossible. An RPC-finalized receipt records an endpoint’s observation; it is not an embedded consensus proof.

Which would you require in an agent workflow: a confirmation floor, an RPC-finalized signal, or both?