Join approval to the exact action

Approval is meaningful only when it identifies what the person saw and what later executed. A chat message saying "yes" should not authorise the latest mutable state of a task.

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

The approval event records the proposal ID and hash, reviewer identity, reviewer authority, time, decision and any conditions. The interface event can record which version was rendered. If the reviewer edits the action, create a revised proposal or mark the final payload as human-authored. Do not retain an approval against a payload that no longer matches.

At execution, recheck:

• the approval is valid and unused;
• the reviewer still has authority;
• the proposal has not expired;
• the target version is unchanged;
• the policy version still permits the action;
• the canonical payload hash matches.

Record each check and its result in one execution-decision event. If a check fails, the task returns to proposal or review rather than quietly applying the old approval.

Some policies may allow predefined actions without a case-by-case review. Record the policy rule and version that granted automatic authority. A missing approval should be distinguishable from an action that was legitimately exempt.

Approval revocation and cancellation are events too. They stop future execution but may not stop an in-flight request. The audit view should show whether the destination later confirmed a change and whether recovery followed.