Approval Binding

The defect

Almost every approval queue stores this:

  approvals: { requestId, approvedBy, approvedAt }

So the record says "Dana approved request 41." It does not say **what request 41 said when Dana approved it.** The requester edits the amount, the recipient, the SQL, the deploy target — and the approval is still sitting there, still valid-looking, now authorising something nobody agreed to.

Nothing errors. The audit log is complete and entirely misleading: a correct approval, by a real approver, at a real time, for content that no longer exists.

  const decision = evaluateApprovals(editedRequest, [danasApproval], policy, { now });
  // { allowed: false, reason: "payload_changed",
  //   detail: "1 approval(s) were given for a different version of this request…" }

payload_changed is reported before insufficient_approvals, deliberately. "Insufficient approvals" sends somebody off to collect a second signature for content nobody has reviewed.

The other four, all variations on "who actually agreed"

| refused | because | |---|---| | self_approval | the requester approved their own request (off by default; enabling it should be deliberate) | | insufficient_approvals | counted distinct humans — one person holding two roles is one person | | stale_approval | a six-week-old approval authorising today's deploy | | already_executed | two approvers clicked at once; for a payment or a migration, the second run is the incident |

The quorum rule is worth dwelling on. Counting approval rows turns a two-person policy into a one-person policy that still reads as two in the audit log — the same person, two roles, two clicks. A Set on the approver is the entire difference.

Hashing, where a false alarm is as costly as a miss

Keys are sorted recursively before hashing. JSON.stringify preserves insertion order, so the same request built by two code paths would otherwise hash differently, every approval would look tampered with, and everyone would learn to click through the warning — which costs you the signal exactly when it is real.

Array order is preserved, because for a list of recipients or migration steps the order is the content.

What it does not do

| not included | why | |---|---| | Storing approvals, or a UI | decision logic only; it fits whatever queue you have | | Deciding who may approve | that is your authorisation system's job — this consumes the result | | Notifying approvers | no transport |

approvalContext() returns the hash for display. An approval UI that never shows what is being approved, in a form the approver can compare later, is how the drift above goes unnoticed for months.