Approval-State Binding: Keeping Execution Connected to What Was Reviewed

Approval needs a clear reference

An approval is not simply a property of a file or task. It expresses a relationship: a person with appropriate authority permitted a particular action involving something they reviewed, under particular conditions.

A label such as “Approved” compresses that relationship. Compression is useful for an interface, but the underlying system needs enough detail to recover what the label means.

For example, these are different decisions:

• “This draft is ready for another editor to review.”
• “Publish this saved revision to the public website.”
• “Replace the existing public page with this revision tomorrow morning.”

The document might be identical in all three cases. The authorized action is not.

This is why identifying approved content is necessary but insufficient. A workflow must also preserve the connection between that content and the intended action.

The related problem of stale decisions is broader: an earlier decision may cease to apply because circumstances have changed. Approval-state binding focuses on a narrower question—whether execution remains connected to the state and action that received approval.

What needs to stay connected

The necessary detail depends on the workflow. Publishing an article, releasing software, and approving a payment do not require identical records. They do share several useful questions.

Artifact identity

Which document, package, record, or other object did the person review? A filename alone may not distinguish multiple copies.

Reviewed revision

Which version or snapshot was presented? A stable document identifier can identify the document across its lifetime without identifying its state at the moment of approval.

Authorized action

Was the person approving publication, scheduling, replacement, transfer, deletion, or another operation?

Target and destination

Which page, account, environment, recipient, or external system was the action intended to affect?

Approver and authority

Who approved the action, and did they have authority to approve it? Identifying a person does not by itself establish their permission.

Conditions

Did approval depend on a scheduled time, an unchanged amount, a completed check, or another condition that must still hold?

These details need not all appear in one crowded confirmation dialog. They do need to remain connected in the workflow, with the consequential details understandable to the person making the decision.

Three distinctions help keep the design clear:

• Authorization scope asks what the permission covers.
• Evidence freshness asks whether the information supporting the decision still applies.
• Approval-state binding asks whether the action being executed matches the particular state and action approved.

A workflow can preserve one of these relationships while losing another. It might submit exactly the approved document to an unauthorized destination, or execute the approved action after its supporting evidence has become outdated.

A publishing example

Consider an editor reviewing revision 18 of an article in a preview. The editor approves replacing an existing public page with that revision.

Before publication, another contributor saves revision 19. If the publication step simply fetches “the latest article,” the system may publish revision 19 under an approval that belonged to revision 18.

No one necessarily acted carelessly. The workflow allowed a mutable reference—“latest”—to stand in for a specific reviewed revision.

A clearer sequence

1. The review surface identifies the saved revision being shown.
2. The approval records that revision, the publication action, and the destination page.
3. The publication step uses that approved revision rather than resolving “latest” again.
4. Relevant changes produce a visible hold, a new review, or another explicitly defined response.
5. The workflow records the submission result and, where needed, checks the resulting public state.

This does not mean revision 18 should always be published. A newly discovered error might make it unsuitable. Binding preserves the meaning of the earlier approval; it does not require the workflow to proceed when there is a reason to stop.

There can also be a mismatch before approval. If the preview shows unsaved editor text while the publication step reads the saved file, the person may approve content that the system never submits. The relationship between captured state and live state therefore matters on both sides of the decision.

Technical mechanisms and their limits

Several established techniques can support this relationship. They solve different parts of the problem rather than providing interchangeable guarantees.

Revision identifiers and immutable snapshots

A revision identifier gives the workflow a specific version to reference. An immutable snapshot preserves that version rather than allowing its contents to change in place.

This works only if the identifier reliably resolves to the same state and execution actually uses it. Recording revision 18 is not enough if a later step silently substitutes the current draft.

Content hashes

A cryptographic content hash can help detect whether bytes differ from a recorded version. It can be useful when an artifact moves between storage, review, and execution systems.

But a hash does not explain what those bytes mean, whether the person understood them, or what action they authorized. Nor does a hash prove that the review interface displayed the artifact faithfully.

The chosen representation matters too. A hash of the article body does not cover a changed destination, attachment, or publication setting. If those details matter to approval, the binding needs to account for them separately or include them in a defined approval record.

Even an unchanged HTML file can produce a different visible result when its templates, styles, scripts, or external resources change. The appropriate review boundary depends on whether the person is approving text, rendered appearance, interactive behavior, or some combination.

Version checks and conditional writes

Optimistic concurrency controls can reject an operation when the current version differs from an expected version. An HTTP conditional request using If-Match, for example, can help prevent updating a resource that has changed since it was read, when the server implements the condition appropriately.

Such a check protects a particular resource operation. It does not automatically establish that the submitted content was reviewed or that the destination was authorized. Those relationships still need to be carried through the workflow.

Digital signatures and protected approval records

A digital signature can provide evidence that a particular key signed a defined record and that the signed data has not changed. A protected approval record can preserve the artifact reference, action, target, and approver together.

Neither mechanism proves comprehension. Their value also depends on how keys, identities, permissions, and records are managed. Signing a vague instruction such as “publish the latest version” preserves that instruction without removing its ambiguity.

Which changes need renewed review?

Not every technical difference requires a person to repeat the entire review. But a system should not silently decide that every small-looking change is harmless.

A useful starting point is to ask whether the change affects the meaning, consequences, or stated conditions of the approval.

• Content changes: revised claims, removed qualifications, new attachments, altered amounts, or changed links may require renewed review.
• Destination changes: moving from a test environment to production, or from one recipient to another, changes what the action does even when the content stays identical.
• Operation changes: creating a draft is not equivalent to publishing it; creating a new page is not equivalent to overwriting an existing one.
• Dependency changes: a different template, configuration, or referenced file may alter the outcome without changing the main artifact.
• Presentation changes: apparently cosmetic changes can affect reading order, visibility, or accessibility and should not automatically be dismissed.

Some workflows permit defined transformations after approval, such as normalizing line endings or applying a reviewed publication template. That can be reasonable when the transformation is bounded, understood, and included in what the approval permits.

A difference report can help a reviewer assess a change. It should also identify changes outside the document body, such as a new destination or publication setting. A text comparison alone cannot reveal every consequential difference.

Check at the execution boundary

A check made during approval may be too early to protect a later action. The artifact or target can change between the check and its use.

This resembles the established time-of-check to time-of-use problem: a condition verified at one moment may no longer hold when an operation relies on it.

Where possible, the system should execute from the approved immutable input and enforce relevant preconditions as part of the operation. Simply checking a mutable file and then reopening it later leaves room for a different version to be used.

Across external systems, a single atomic operation may not be available. The workflow then needs to make its limits explicit: what was fixed locally, what the receiving system accepted, and what remains unverified. This is part of governance at the point of action, where evidence and authority must apply to the operation actually being attempted.

A mismatch should create a useful hold

If the current state no longer matches the approved state, the interface should explain the difference and offer an appropriate next step. That might mean reviewing the changed revision, restoring the approved snapshot, correcting the destination, or cancelling the action.

A silent substitution weakens approval. An unexplained error makes recovery difficult. A useful hold preserves both the work and the reason execution stopped.

Submission is not outcome verification

Even a correctly bound action can fail or produce an unexpected result. An external service may accept a request before completing it, transform submitted content, or apply it to a state that has changed.

Keep these claims separate:

• The person approved a defined action.
• The system submitted inputs matching that approval.
• The receiving system accepted the request.
• The intended external result was confirmed.

As with other workflows, network success is not task success. Evidence of a valid submission should not be presented as proof of a completed outcome.

Questions for reviewing a workflow

To examine an existing approval process, follow one real item from review through execution:

1. What did the person see? Identify the actual revision and whether the review surface represented it accurately.
2. What did they authorize? Name the operation, destination, and relevant conditions.
3. What can change afterward? Include content, copies, settings, targets, and dependencies.
4. What does execution read? Check whether it uses the approved snapshot or resolves a mutable reference again.
5. Where is a mismatch detected? Determine whether the check remains effective through the action.
6. What happens when the match fails? Look for an understandable hold and a clear route to renewed review.
7. What does the completion message prove? Distinguish submission, acceptance, and verified outcome.

The goal is not to attach more approval labels to a workflow. It is to preserve the meaning of the decision already made.

A dependable approval process can answer three questions plainly: what was reviewed, what was authorized, and whether the action performed still matched both.