Sealed execution

Concept / enforcement

The verifier’s native success type is VerifiedAction. It has no public constructor. A profile decoder accepts that sealed result and produces a typed command.

canonical profile action
  -> pure Auths verification
  -> sealed VerifiedAction
  -> profile-decoded command
  -> atomic replay/budget claims
  -> ExecutableAction<Command>
  -> executor

This prevents a time-of-check/time-of-use split where the application verifies one set of values and executes another.

Downstream checks still apply

Successful proof verification does not claim replay state, reserve a budget, apply transport policy, execute a command, or emit an execution receipt. Those effectful steps belong to auths-proof-apps and must preserve the sealed-action invariant.