Stale Decisions: When Earlier Approval No Longer Authorizes the Action

What becomes stale?

The historical decision does not disappear. A reviewer still approved a particular action under particular conditions. What changes is whether that decision remains applicable to the present situation.

For example, approval to send a report to an internal team does not necessarily authorize sending the same report to an external recipient. The content may be unchanged, but the disclosure boundary is different.

Several conditions can make an earlier decision insufficient:

• The subject changed: the reviewed document, code, configuration, or data was revised.
• The destination changed: the action now targets a different account, recipient, environment, or publication surface.
• The action changed: a preview becomes a public release, or a one-time operation becomes a recurring one.
• A relevant assumption changed: a dependency is no longer available, a required check failed, or circumstances contradict the basis of approval.
• The authority changed: approval was withdrawn, permissions changed, or a governing rule now requires a different reviewer.

Not all of these are technically the same condition. A withdrawn approval is revoked; an approval outside its allowed time window is expired. Keeping these reasons distinct helps people understand why execution stopped and what would make continuation legitimate.

Staleness is not simply age. A decision can become stale seconds after review if its subject changes. An older decision may remain applicable when its scope, conditions, and any time limits still hold.

Defining the scope of approval

An approval is easier to validate when it identifies what the reviewer actually authorized. A general “approved” flag often leaves too much unstated.

Depending on the workflow, an approval record may need to identify:

• The artifact and revision reviewed.
• The intended action.
• The destination or recipient.
• Relevant settings, limits, or preconditions.
• The reviewer and the authority under which they approved.
• When approval was given and whether it expires.
• Any permitted changes that do not require renewed review.

For a publishing workflow, this could mean approving article revision 12 for publication on a specified website. For a deployment, it could mean approving a particular build for a staging environment, not every later build and not production.

Some approvals deliberately cover a bounded class of actions rather than one exact artifact. A reviewer might authorize a scheduled process within stated limits. In that case, validation should check those limits rather than require an identical payload on every run.

The important distinction is between explicit latitude and assumed permission. The broader treatment of human approval and stale decisions explains why approval needs to remain attached to the state and conditions reviewed.

An example: an approved article changes

An editor reviews an article and approves revision 12 for publication on a public website. Publication is scheduled for the following morning.

Before the scheduled run, another contributor changes a factual claim and replaces an internal reference with a link to an external service. The document is now revision 13, but its general approval flag remains set.

If the publisher checks only that flag, it may publish material the editor never reviewed.

A more reliable workflow preserves the relationship between the approval and revision 12. When execution encounters revision 13, it can:

• Hold publication of the changed revision.
• Show the differences since the approved revision.
• Explain which changes require review.
• Request a new decision from an authorized reviewer.

Publishing the preserved revision 12 may be another option, but only if it remains the intended artifact and still satisfies current conditions. The workflow should not silently publish an older revision merely because that revision once had approval.

The hold is not a rejection of the contributor’s edits. It preserves the boundary between editing content and authorizing its publication.

Recognizing meaningful changes

Requiring complete review after every inconsequential change can make oversight burdensome without improving decisions. Ignoring all changes makes oversight ineffective. A useful policy identifies which differences matter to the action being authorized.

Renewed review is commonly appropriate when a change affects:

• Factual claims, conclusions, commitments, or instructions.
• Recipients, audiences, destinations, or access permissions.
• Money, quantities, timing, or operational limits.
• Security settings or deployment environments.
• Disclosures, consent language, or other consequential conditions.

Other differences may fall within explicitly permitted latitude, such as a narrowly defined formatting adjustment. Even here, context matters: a presentation change can hide a warning, alter reading order, or make a control difficult to use.

There is no universal rule that “formatting is harmless” or “small edits do not count.” Define permitted changes narrowly enough that reviewers and implementers can understand them.

Automated comparison can identify changed fields or text. It cannot always establish their significance. Where interpretation is uncertain, the workflow can hold the action and ask for judgment rather than treating an uncertain classification as permission.

Checking approval before execution

Approval validation belongs near the consequential action, not only at the beginning of a workflow. A check performed before a long queue or an editing stage may no longer describe the state that eventually reaches execution.

A practical validation sequence is:

1. Resolve the intended action. Identify the exact artifact, destination, and settings the system will use.
2. Find the applicable approval. Confirm that its scope covers this action.
3. Check current conditions. Verify relevant versions, permissions, preconditions, time limits, and revocation state.
4. Preserve the checked state. Prevent an unnoticed substitution between validation and execution.
5. Record the result. Retain enough evidence to explain what was authorized and what actually happened.

What identifiers and hashes can establish

Version identifiers and content hashes can help connect approval to a specific artifact. A hash can establish that bytes match the approved snapshot. It does not establish that the content is accurate, the destination is appropriate, or the reviewer had sufficient authority.

Likewise, a document identifier may refer to a continuing document whose contents change. It is not necessarily a revision identifier.

Avoiding a gap between checking and acting

A workflow can validate revision 12 and then accidentally read revision 13 during publication. This is a time-of-check/time-of-use problem: the checked state differs from the state used.

Depending on the system, immutable snapshots, revision-specific reads, conditional updates, or locking can help prevent that substitution. The appropriate mechanism depends on which state the workflow controls and which guarantees the destination supports.

Where the workflow cannot verify an essential condition, it should make that uncertainty visible. A previous approval is not a substitute for missing execution-time evidence.

Resuming interrupted work

Resuming a workflow requires two separate questions:

1. What has already happened?
2. What is still authorized to happen?

The first concerns state and evidence. The second concerns permission. Neither answers the other.

Suppose publication was approved, the request was sent, and the connection failed before confirmation arrived. Renewing approval does not establish whether the article already exists. Conversely, confirming that publication did not occur does not establish that the old approval still covers a revised article.

Recovery should first account for partial completion and uncertain outcomes, then validate authorization for the remaining action. Retry safety addresses whether repeating an operation could duplicate its effects; approval validation addresses whether that operation remains permitted.

A retry mechanism should not silently treat changed content or a changed destination as the original approved intention.

Making renewed review useful

A request for renewed approval should explain the decision needed, not merely display another confirmation button.

Useful review information includes:

• The previously approved state.
• The current proposed state.
• The differences that triggered the hold.
• Any consequences already known to have occurred.
• The specific action a new approval would authorize.

For example: “Revision 12 was approved for this website. Revision 13 changes the conclusion and an external link. Publication has not started. Review revision 13 to authorize publication.”

If the earlier outcome is uncertain, say so instead of claiming that nothing happened. If the person reviewing lacks the necessary authority, route the decision appropriately rather than accepting a convenient confirmation. These are practical uses of holds, exceptions, and escalation.

Preserve earlier decisions as history. A new approval should make clear what it replaces or newly authorizes, without rewriting the record of the original review.

A practical stale-decision review

When examining an approval workflow, ask:

• Can we identify exactly what the person reviewed?
• Does approval specify the action and destination?
• Are permitted changes explicit?
• Can relevant changes invalidate approval or trigger a hold?
• Do checks occur close enough to execution to remain useful?
• Will execution use the same state that was checked?
• Are resumed and retried actions checked again where necessary?
• Can a reviewer see what changed and what has already happened?

The aim is not to ask people for permission repeatedly. It is to preserve the meaning of the permission they already gave.

An earlier decision remains useful when it still applies. When the action moves beyond its scope, the workflow needs a new basis for proceeding—not merely the continued presence of an “approved” flag.