Tying an approval to the exact action

An approval only means something if you can say what the person saw and what later ran. Someone typing "yes" in chat shouldn't authorise whatever the task happens to look like by the time it executes.

Create a proposal object with a stable ID. It holds the target system and object, the current version of the target, the exact proposed fields or command, expected side effects, supporting source references and an expiry. Hash the canonical form of the proposal.

The approval event records the proposal ID and hash, who reviewed it, what authority they had, the time, the decision and any conditions. The interface event can record which version was actually rendered on screen. If the reviewer edits the action, create a revised proposal or mark the final payload as human-authored. Don't leave an approval pointing at a payload that no longer matches it.

At execution time, check again:

• The approval is valid and hasn't been used.
• The reviewer still has authority.
• The proposal hasn't expired.
• The target version hasn't changed.
• The policy version still allows the action.
• The canonical payload hash matches.

Write each check and its result into one execution-decision event. If any check fails, the task goes back to proposal or review, so an old approval never quietly gets applied to something new.

Some policies will let predefined actions through without a case-by-case review. When that happens, record the policy rule and version that gave the automatic authority, so a reviewer can tell a missing approval apart from an action that was legitimately exempt.

Revoking an approval and cancelling a task are events too. They stop future execution, but they might not stop a request that's already in flight. The audit view should show whether the destination later confirmed a change and whether any recovery followed.