The short answer

A protected action changes an external system or durable state. Before execution, validate its current identity, scope, assignment, policy, expiry, approvals and effect-specific safeguards. Missing or stale required evidence should prevent the action from proceeding.

Define the exact effect you are protecting

“Update the account” is too broad to evaluate reliably. The host needs to know which account, which change, which actor and which payload are involved. Approval and replay controls lose meaning when the requested operation changes without a new decision.

The protected-action reference places current authority and effect checks before execution. Treat that as the boundary where the application's permission model meets the actual connector.

Planning and agreement are not effect permission

The authority guide distinguishes coordination from execution and external effects. A plan may identify a useful action, and collective agreement may certify a coordination decision, while a required external-action check still denies execution.

In an illustrative supplier workflow, the collective can agree which quote is preferred without authorizing purchase. Model the purchase as its own exact effect. This lets the application explain why analysis completed while a consequential operation remained pending.

Fencing rejects authority that has become stale

Ownership can change between planning and action. Revalidate the relevant assignment, lease or fence so a delayed executor cannot rely on superseded state.

For a deployment review, inject a pause just before the external write, change the ownership through the supported lifecycle and then resume the old executor. Inspect the actual effect boundary. A check performed only at the beginning of a long run may not represent the state at the time of the write.

The downstream sink must enforce its own guarantees

The integration controls example demonstrates one fixed local receipt protected by a PostgreSQL unique key. Its documented scope does not establish arbitrary remote exactly-once effects.

Your real sink must bind operation identity to payload and scope, apply its own atomic rules and reconcile uncertain outcomes. If a service does not support a useful idempotency or lookup mechanism, the host may need to pause for reconciliation. Reusing an operation ID is only meaningful when the receiving system enforces its semantics.

Test denial with the same care as success

  • Attempt execution with missing approval.
  • Reject a provider that cannot enforce the required checkpoint.
  • Deny at the checkpoint and inspect that no effect occurred.
  • Change payload or scope while retaining an old operation identity.
  • Retry after a deliberately uncertain acknowledgement.
  • Attempt continuation under stale ownership.

These suggested cases help distinguish a working success path from a meaningful control boundary. Retain receipts and rejection reasons without copying sensitive payloads into public logs. The effect's real outcome is stronger evidence than a UI label saying it was protected.

Sources and further reading

Documentation reviewed . Consult the linked documentation for current implementation details.