# Compare the approval screen with the submitted payload

Review the values a person saw against the values the executor used. This catches hidden fields, stale state and post-approval changes that a polished screen can conceal.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Choose an operation with visible consequences

Use a synthetic address change, external report or other mutation whose target and material fields are easy to inspect. Save the proposal, open the approval screen and capture the server record used to render it.

Compare every consequential field with the execution payload. Include recipients, attachments, defaults and identifiers that may not appear in the main summary. A reviewer cannot approve a hidden destination simply because the visible title looked correct.

Ask how unresolved information is displayed. If the assistant guessed a value, the screen should not make it look verified without evidence.

## Inspect the binding mechanism

Find the proposal identifier and revision attached to the decision. Confirm that the executor loads approved values from trusted storage and rejects changed or stale proposals according to policy.

If the design uses a payload hash, inspect canonicalisation and which fields are included. A hash that omits a recipient or depends on inconsistent serialisation can provide false confidence. It also needs a readable retained proposal so people can later understand the decision.

Review concurrent decisions and repeated execution. The state model should prevent conflicting transitions and duplicate effects using the storage system's actual guarantees.

## Follow alternate paths

Call the mutation endpoint without approval and try an older client request. Inspect background jobs and administrative routes that perform the same effect. Any exception should have a documented authority rule of its own.

Check expiry and target changes at execution time. A disabled button on an old page is not sufficient if the executor accepts the stale decision directly.

Review how the system handles an uncertain downstream result. A retry must remain tied to the same approved operation rather than silently creating a new proposal or effect.

## Ask for failure evidence

Require demonstrations of one changed payload, one unauthorised reviewer and one lost response after execution. Inspect target state and decision records, not only browser messages.

The review should leave a concise statement of what approval covers, what invalidates it and how execution is deduplicated. Those rules are the basis for future changes to fields, destinations and workflow states. A visually clear confirmation screen is valuable, but it is only one part of that contract.

## Sources

- [OWASP: transaction authorisation](https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html)
- [AWS Builders' Library: idempotent APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)