How Approvals Fail | Why ‘Approved’ Can Still Be Ambiguous, Stale or Unowned

How approvals fail is more important than it sounds. An approval can exist in an email, a chat message, a meeting, a signature, a workflow button or a spoken sentence and still fail to create a reliable decision.

The weakness is usually not the word approved. The weakness is everything around it.

Who had authority? What exactly was approved? Which version? Under what conditions? For how long? Based on which evidence? Did the approval permit action or merely acknowledge review? Did the underlying inputs change afterwards? If the approval becomes invalid, who notices?

Approval is therefore not a decorative end-state. It is a controlled transition from not-authorised to authorised.

A strong approval system makes authority, scope, evidence, conditions, time and ownership visible. A weak one leaves those elements implicit and hopes that everybody interprets the same word in the same way.

This master guide explains the failure architecture. The three companion explainers go deeper into approval authority, approval evidence and approval revalidation.

The Core Idea: Approval Is Permission to Change State

Before approval, a proposal may be draft, pending, unverified or not yet authorised.

After approval, somebody may spend money, publish information, submit work, begin a project, release a document, change a system, continue a learning route or commit other resources.

That state change is why approval matters.

An approval system is reliable only when the permission is tied to the right decision, the right person, the right evidence and the right version.

The U.S. Government Accountability Office’s Green Book treats authorisation, documentation, segregation of duties and change assessment as parts of internal control. HM Treasury’s current public-money guidance similarly distinguishes delegated authority from cases that require further scrutiny and requires approvals to operate within defined limits.

Failure Mode 1: The Wrong Person Approves

A person may be senior without being the correct decision owner.

Authority can depend on subject, value, risk, location, role, budget, policy or technical competence.

If the approver is outside the decision boundary, the approval may look official while lacking the authority the workflow actually requires.

This is why good systems define decision rights rather than relying on status.

Failure Mode 2: Authority Is Too Broad

A person may have authority to approve one kind of decision but not another.

For example, the same manager may be able to approve routine expenditure inside a limit but not a novel, contentious or high-value commitment.

The principle transfers beyond finance.

A tutor may approve a change in practice routine but not a school pathway decision. An editor may approve style changes but not a legal claim. A student may decide how to organise revision but not rewrite an examination rule.

Authority should be bounded by the decision being made.

Failure Mode 3: Nobody Knows the Limit

Authority that exists only in someone’s memory is fragile.

The user should be able to answer: what can this role approve, up to what limit, in which domain and under which conditions?

HM Treasury’s delegated-authority system illustrates the general control principle clearly: delegated limits are defined so that routine decisions can move locally while exceptional or higher-risk cases receive additional scrutiny.

That mechanism is developed in How Approval Authority Works.

Failure Mode 4: Approval Is Implied From Silence

No reply is not the same as approval.

Silence may mean agreement, absence, overload, uncertainty, missed notification or unresolved objection.

Where the decision matters, the system should not force users to infer consent from non-response.

Current UK public-spending guidance makes this explicit for Treasury approval: approval must be confirmed and cannot simply be implied because no answer arrived.

Failure Mode 5: Review Is Mistaken for Approval

A person may review a document without accepting responsibility for the decision.

Comments such as ‘looks fine’, ‘no issues from me’ or ‘reviewed’ can be interpreted differently by different participants.

The workflow should distinguish review, recommendation, concurrence, approval and final authorisation when those states matter.

A reviewer provides input. An approver changes the permission state.

Failure Mode 6: The Approved Object Is Ambiguous

An approval is meaningless if nobody can identify exactly what was approved.

Was it the document, the budget, the idea, the final PDF, the draft slide deck, the revised scope or only one section?

Version ambiguity is especially dangerous because a valid approval can be attached mentally to the wrong artefact.

The approval should point to a specific object or state.

Failure Mode 7: Conditions Are Lost

Some approvals are conditional.

A proposal may be approved provided one calculation is corrected, one source is verified, one clause is changed or one risk is mitigated.

If the word approved survives but the conditions disappear, the decision is misrepresented.

Conditions should travel with the approval until they are closed.

Failure Mode 8: Approval Arrives Before the Evidence

A weak process asks for approval because the calendar says it is time.

A stronger process asks whether the decision packet is ready.

If required evidence is missing, the approver is not deciding on the intended basis.

This can produce ceremonial approval: the gate is passed without the information that made the gate meaningful.

The approval request should make missing evidence visible before the decision.

Failure Mode 9: Evidence Exists but the Approver Cannot Interpret It

More documents do not automatically create a better decision.

An approval pack can be complete and still be unusable if the decisive evidence is buried.

Good approval design shows the decision, the relevant evidence, the uncertainty, the consequences and the conditions that matter.

The approver should not need to reverse-engineer the request.

Failure Mode 10: The Same Person Creates, Approves and Records

Combining all control roles can be fast.

It can also remove independent challenge.

GAO internal-control guidance has long used segregation of duties as a core control idea: important responsibilities can be divided so that no one person controls every key aspect of a transaction or event.

Not every small decision needs multiple people. The degree of separation should match the consequence and risk.

Failure Mode 11: The Approval Has No Audit Trail

If nobody can reconstruct who approved what and when, accountability becomes memory.

A useful approval record preserves identity, time, object, state and conditions.

FDA guidance on electronic records and signatures illustrates why audit trails matter in regulated settings: a trustworthy record should allow the sequence of creation, modification and deletion to be reconstructed.

The broader mechanism is developed in How Approval Evidence Works.

Failure Mode 12: The Record Can Be Edited Without Trace

An approval attached to a mutable document is vulnerable if the document can change afterwards without the approval state changing.

The system needs some way to detect or prevent post-approval drift.

That may be version locking, checksum, immutable history, a new revision number or a requirement to reapprove changed material.

Failure Mode 13: Approval Has No Effective Time

A decision may be approved now but intended to take effect later.

Or it may be valid only until a deadline.

Without effective time, users can act too early or rely on a decision after its valid window.

Time belongs inside the approval state.

Failure Mode 14: Inputs Change After Approval

This is one of the most common approval failures.

The budget changes. The evidence changes. The scope expands. A new risk appears. The final document differs from the version reviewed.

The old approval may no longer apply.

A mature system defines which changes are material enough to require revalidation.

That is the focus of How Approval Revalidation Works.

Failure Mode 15: Approval Never Expires

Some approvals should remain valid indefinitely. Others should not.

A decision tied to current facts, current prices, a temporary condition or a specific version can become stale.

Expiry is not bureaucracy when the underlying world changes faster than the approval.

The system should define either a time-based expiry or a change-based revalidation trigger where appropriate.

Failure Mode 16: Everyone Approves, So Nobody Owns

Multiple signatures can create an illusion of shared responsibility.

In practice, each person may assume another approver owns the final consequence.

A strong workflow distinguishes consultation from accountability.

Who makes the final decision? Who executes it? Who verifies completion? Who owns the result after approval?

These roles can overlap, but they should not be ambiguous.

Failure Mode 17: Approval Becomes a Queue Instead of a Decision

Sequential approvals can accumulate because each additional signature feels safer.

The result may be delay without additional information or challenge.

Every approval stage should have a distinct purpose.

If two approvers perform the same review with the same evidence and the same authority, the second gate may be duplication rather than control.

Failure Mode 18: Risky Decisions Receive the Same Approval as Routine Ones

A good approval architecture is risk-sensitive.

Routine low-consequence decisions should not require the same route as irreversible, high-value or uncertain decisions.

This is one reason delegated authority matters.

Local decisions remain local until consequence, novelty, uncertainty or scale crosses a boundary.

Failure Mode 19: The Approval Cannot Be Challenged

Approval should not convert a fallible decision into sacred truth.

New evidence may justify reconsideration.

A reliable system has a path for appeal, exception, escalation or re-review when the factual basis changes.

This protects both authority and reality.

Failure Mode 20: The Workflow Measures Approval Speed but Not Approval Quality

Fast approval can be good when the decision is routine and the evidence is ready.

Fast approval can be dangerous when it means the gate has become automatic.

The right metric is not only time-to-approve.

It is whether the approval reliably prevents invalid actions while allowing valid actions to move.

The Three Pillars of a Reliable Approval

1. Authority

The decision must sit with a person or role that is permitted and competent to make it within a defined boundary.

Read How Approval Authority Works.

2. Evidence

The approval must be traceable to a specific object, version, conditions and decision record.

Read How Approval Evidence Works.

3. Revalidation

The system must know when changed inputs, scope, risk or time invalidate the old decision.

Read How Approval Revalidation Works.

A Practical eduKateSG Approval Test

Decision — what exactly is being authorised?
Authority — who may make this decision?
Boundary — what limits apply?
Object — which specific version or item is covered?
Evidence — what information supports the decision?
Conditions — what must still be completed?
Time — when does approval take effect and when does it expire?
Record — can the decision be reconstructed later?
Execution — who acts after approval?
Verification — how do we know the approved action was completed correctly?
Change — which changes trigger reapproval?
Escalation — what happens when authority or evidence is insufficient?

An approval is reliable when those questions resolve into one coherent permission state.

Example: Student Learning Route

A tutor may recommend continuing, advancing, reclassifying or stopping a learning route.

That decision should not be a vague ‘yes, continue tuition’.

eduKate Sengkang’s Tutor Handbook treats the review as an evidence gate: the tutor explains what changed, what remains uncertain and the condition that will justify the next move.

Read The First Review and The Parent Review.

Example: Family Decision

Families also use approval-like decisions when choosing a pathway, tutor, schedule or major change in support.

eduKate Punggol’s Family Decision System separates the real question, facts, assumptions, constraints, affected people and authority before committing.

Read How Family Works | The Family Decision System.

Example: Mathematics

In Mathematics, the comparable mechanism is not authority but independent verification.

A student should not accept an answer merely because it emerged from familiar working. The answer must survive a check that can disagree with it.

Bukit Timah Tutor develops this in A Good Mathematics Check Should Be Able to Disagree With the Working.

The same principle matters in approval systems: approval should challenge the decision state, not merely repeat the creator’s own reasoning.

Example: Recovery

eduKate Yishun’s recovery system treats escalation and release as evidence-based decisions rather than permanent labels.

Support intensifies when local repair repeatedly fails and reduces when capability stabilises.

Read Recovery Atlas.

Example: Publishing

A publishing approval should identify the exact article, slug, version and unresolved conditions.

If a title collision is discovered after approval, the old approval may no longer cover the changed publication route.

If a factual claim changes materially, the final version should return through the relevant verification gate.

The approval belongs to the approved state, not to the author’s general intention.

Across the eduKate Ecosystem

eduKateSG owns the general approval mechanism. eduKateSingapore classifies decisions by stakes, reversibility, time, evidence and authority. eduKate Sengkang makes continuation and release decisions visible across parent, student and tutor. eduKate Punggol carries family decision structure. Bukit Timah Tutor carries independent mathematical verification. eduKate Yishun compares decisions, evidence and results during recovery.