Human Approval and the Problem of Stale Decisions

What human approval actually authorizes

Approval is a decision about a defined proposal. It is not automatically permission for every later action associated with the same task, file, or project.

Consider the difference between these two records:

• “Stephen approved the article.”
• “Stephen approved revision 12 for publication on the specified website, using the reviewed title, body, images, and visibility settings.”

The first records a general status. The second preserves the scope of the decision.

Depending on the workflow, that scope may include:

• The artifact: the exact document, configuration, transaction, or other item reviewed.
• The action: publish, send, deploy, transfer, delete, or another defined operation.
• The destination: the website, recipient, account, environment, or system affected.
• The limits: amount, audience, access level, quantity, timing, or other constraints.
• The conditions: facts or safeguards on which the decision depended.

This is part of making human-in-the-loop systems meaningful. A person must have a genuine opportunity to review the consequential action, not merely supply a reusable “approved” flag.

How an approval becomes stale

An approval becomes stale when a relevant change makes it unsafe to assume that the earlier decision still covers the proposed action. Staleness concerns applicability, not just age.

An approval given seconds ago can already be stale if the destination changes. An older approval may remain applicable if its scope, conditions, and governing policy still hold.

Common sources of change include:

• Content changes: an approved message receives a new attachment, claim, link, or recipient list.
• Destination changes: a staging deployment becomes a production deployment.
• Permission changes: a private document becomes publicly accessible.
• Environmental changes: a dependency, account configuration, or operational condition differs from what was reviewed.
• Authority changes: approval is revoked, an account is suspended, or policy requires a different reviewer.
• Timing changes: the action moves outside an approved window or relies on information that is no longer current.

These changes do not all carry the same significance. The important question is whether the proposed action remains inside the scope of the original decision.

An example: an approved article changes

An editor reviews revision 12 of an article and approves it for publication. Before the scheduled publication runs, another process updates the document to revision 13, adding a paragraph and changing an external link.

If the publisher checks only whether the article has an “approved” status, revision 13 may go live without anyone reviewing its changes.

The failure is not that approval was absent. It is that approval was attached to the article’s continuing identity rather than the version the editor actually reviewed.

A more reliable workflow can take either of two approaches:

• Publish the approved snapshot: publish revision 12, while keeping revision 13 as an unapproved draft.
• Require review of the changed proposal: pause publication and show the editor what changed between revisions 12 and 13.

The appropriate approach depends on editorial policy. Either way, the interface should make clear which version will become public. A preview of revision 12 should not silently authorize publication of whatever happens to be current later.

Technical version controls support this boundary, but they do not replace editorial review and responsibility.

Binding approval to the reviewed state

A useful approval record connects the human decision to a stable description of the proposal. This is sometimes called a version-bound decision.

The record may contain:

• A unique approval identifier.
• The reviewer’s identity and the time of the decision.
• The artifact version or immutable snapshot reviewed.
• The authorized action and destination.
• Relevant limits, prerequisites, and expiration conditions.
• Any withdrawal, replacement, or use of that approval.

A version identifier or content hash can help establish whether an artifact has changed. Neither, by itself, proves that the whole proposal remains unchanged. The same document can be sent to a different recipient; the same software package can be deployed with different permissions.

The review therefore needs to cover the action’s relevant context as well as its content.

Where external information cannot be frozen, preserve what the reviewer saw and identify what must be checked again. For example, approving a purchase within a price limit need not authorize a later purchase above that limit.

This distinction resembles the relationship between captured state and live state: the review records one moment, while the operating environment may continue to change.

Checking approval before execution

Approval should be checked at the point where it matters: before the consequential action occurs. Checking only when work enters a queue leaves later changes unexamined.

A practical execution check asks:

1. Does the approval refer to this artifact or proposal?
2. Does it authorize this action, destination, and set of limits?
3. Have any relevant conditions changed?
4. Has the approval expired, been withdrawn, or already been used where only one execution was authorized?
5. Does the action still satisfy current permission and policy requirements?

There can still be a gap between checking and acting. A document might change immediately after validation, or a permission might be withdrawn before execution. In software, this is a form of time-of-check to time-of-use problem.

Where supported, systems can reduce that gap through immutable execution inputs, conditional writes against an expected version, or transactions that keep validation and the protected change together.

Those mechanisms have boundaries. A local database transaction does not automatically make an action in an external service atomic. When systems cannot enforce the whole boundary together, the workflow needs explicit handling for uncertain outcomes and partial completion.

If a relevant mismatch is detected, the workflow should pause or use an explicitly defined alternative—not silently substitute a newer proposal under the old approval.

When to ask for approval again

Not every change requires a complete new review. Reconfirmation should follow the significance of the change and the scope of the original authorization.

A workflow might permit a defined formatting adjustment while requiring renewed approval for a changed claim, payment amount, recipient, deployment environment, or access setting. Those distinctions should be established deliberately, rather than improvised by the process seeking permission to continue.

When renewed approval is needed, show the reviewer:

• What was previously approved.
• What changed and why it matters.
• The exact action now proposed.
• Which earlier conditions still hold and which do not.

A useful prompt might say: “You approved revision 12 for public publication. Revision 13 changes the conclusion and adds an external link. Review these changes before publishing revision 13.”

This is more informative than “Approval expired. Approve again.”

Time limits can be appropriate, but they are only one control. A recent approval does not excuse a material change, and an arbitrary expiration timer does not establish whether a decision remains applicable.

Delays, retries, and partial completion

Approval and execution often happen at different times. Work may wait in a queue, lose a connection, or resume after an interruption.

A workflow timeout establishes that a component stopped waiting. It does not establish whether the approved action happened. Asking for approval again without checking the outcome can leave the human authorizing a duplicate action unknowingly.

Before retrying a consequential operation, determine whether the earlier attempt completed, remains in progress, or has an unresolved outcome. Idempotency can help prevent repeated attempts from duplicating effects, but it does not make stale approval valid. Retry safety and authorization validity are separate checks.

Partial completion needs similar care. If a person approved a batch of ten actions and six completed, the remaining four may still be authorized if the original scope and conditions remain intact. Repeating all ten, adding replacements, or changing destinations requires separate consideration.

Reversing completed work may also require its own authority. Permission to perform an action does not necessarily include permission to delete its result or initiate a compensating transaction.

A practical approval workflow review

To examine an approval workflow, follow one proposal from review through execution and ask:

• Can the reviewer see the actual content, destination, and consequences?
• Does the approval identify the reviewed version and authorized action?
• Which changes invalidate approval, and which are explicitly permitted?
• Can the proposal change without the approval status changing?
• Is approval checked again before execution?
• Can execution use the approved snapshot rather than an unreviewed live version?
• Can the reviewer withdraw approval before the action occurs?
• Are delays, retries, and partial outcomes handled without assuming success or failure?
• Can someone later establish what was approved and what actually happened?

The purpose is not to ask people to approve more often. It is to make each approval mean something precise enough to guide the work.

Human judgment remains useful when the workflow preserves its boundaries. An earlier “yes” should carry forward only as far as the proposal and conditions it actually covered.