How Dependencies Fail | Why Hidden Prerequisites Block Progress

How dependencies fail is the study of what must be ready before something else can work.

A dependency is easy to miss because it often sits one layer beneath the visible problem. A student appears weak at calculus, but the blocking dependency is factorisation. A project stalls at submission, but the missing dependency is an approval. A publication fails, but the real dependency is a verified source, a canonical owner or a working final file.

When the wrong dependency is diagnosed, effort moves in the wrong direction. More work is added downstream while the upstream condition stays broken.

Dependencies matter because sequence matters.

This master guide explains the failure architecture. The three companion explainers go deeper into dependency criticality, dependency timing and dependency substitution.

The Core Idea: A Dependency Is a Condition Another Result Relies On

A dependency can be knowledge, information, a person, a tool, a decision, a resource, a state, a permission or an earlier output.

If B cannot work until A is ready, B depends on A.

Hard dependency — B cannot proceed without A.
Soft dependency — B can proceed, but quality or efficiency falls without A.
Conditional dependency — A is required only in a particular state.
Shared dependency — several later tasks rely on the same A.
Sequential dependency — A must finish before B begins.
Information dependency — B needs a fact, decision or verified input from A.

Dependency failure begins when these distinctions stay invisible.

Failure Mode 1: The Visible Task Is Mistaken for the Root Problem

A visible failure is not automatically the blocking dependency.

If a student cannot find stationary points, the obvious label is differentiation. But if the derivative is correct and the quadratic cannot be factorised, differentiation is not the broken link.

The repair should target the earliest meaningful failure that still controls the target.

Failure Mode 2: Everything Is Treated as a Dependency

A system can over-map.

If every useful resource becomes mandatory, the map becomes too dense to guide action.

The important question is not ‘What could help?’ but ‘What must be ready for this target to work at the required level?’

That distinction is the focus of How Dependency Criticality Works.

Failure Mode 3: The Dependency Exists but Is Not Ready in Time

A prerequisite can be valid and still fail operationally because it arrives too late.

An approval after the publication deadline does not unlock the release. A concept taught after the exam does not support the paper. A dataset delivered after analysis is complete does not help the decision.

Dependency design therefore includes timing.

Read How Dependency Timing Works.

Failure Mode 4: The Dependency Is Assumed Rather Than Tested

People often assume a prerequisite is secure because it was taught before.

Teaching history is not readiness evidence.

A student may have completed fractions without being able to use equivalence independently. A team may have a documented approval process without knowing who currently holds authority.

A dependency should be tested at the level the downstream task needs.

Failure Mode 5: The Dependency Is Too Broad

‘Weak in algebra’ is too broad to be operational.

What exact algebraic relationship blocks the current work?

A broad label encourages broad remediation. A precise dependency supports a small repair.

eduKate Yishun’s academic recovery model uses this principle: identify the smallest dependency whose repair can reopen progress.

Failure Mode 6: Chronology Is Mistaken for Dependency

What came earlier is not always what matters now.

A student who missed three lessons does not automatically need all three replayed.

eduKateSingapore’s missed-school guide asks what the current lesson actually depends on and repairs only the missing prerequisite that changes participation.

Chronological completeness can waste limited recovery time.

Failure Mode 7: One Dependency Serves Many Downstream Tasks

Shared dependencies create leverage.

Factorisation can affect quadratics, functions, calculus and coordinate geometry. Sentence comprehension can affect inference, analysis and answer construction. A source-of-truth decision can affect multiple publishing pages.

When one dependency unlocks several outcomes, it deserves priority.

Failure Mode 8: The Dependency Is External

Some dependencies sit outside the learner or team.

A school timetable.
A parent decision.
A third-party source.
A system login.
A vendor delivery.
A teacher clarification.
A policy rule.
A required approval.

External dependencies need ownership and monitoring because local effort alone cannot make them ready.

Failure Mode 9: The Dependency Has No Owner

A requirement that belongs to nobody will often be late.

The dependency map should identify who makes each condition ready.

The owner is not necessarily the person who later consumes the dependency.

Failure Mode 10: The Dependency Has No Readiness Test

A prerequisite can look complete while remaining unusable.

A student has notes but cannot retrieve the method. A file exists but is not final. An approval was requested but not granted. A source is linked but does not support the claim.

Ready should be observable.

Failure Mode 11: The Downstream Task Starts Too Early

Starting before a hard dependency is ready creates rework.

People draft around missing facts, solve around missing prerequisites or build around unresolved decisions.

Sometimes early parallel work is sensible, but the system should know which parts are provisional and which are safe to execute.

Failure Mode 12: The System Waits for a Dependency That Does Not Need to Block

The opposite failure also occurs.

A team may wait for a helpful input that is not actually required to start independent work.

Dependency clarity prevents unnecessary waiting as well as premature action.

Failure Mode 13: The Chain Becomes a Single Point of Failure

If one prerequisite, person or resource controls many downstream outcomes, the system becomes fragile.

The dependency may be legitimate, but concentration risk should be visible.

Options include earlier preparation, duplication, substitution, cross-training or a fallback route.

Failure Mode 14: The Fallback Is Not Equivalent

Replacing a blocked dependency can preserve progress.

It can also quietly change the outcome.

A substitute source may be lower quality. A substitute teacher may use a method that does not reconnect to school work. A new software tool may change the file interface.

Substitution should preserve the function that matters.

That is the focus of How Dependency Substitution Works.

Failure Mode 15: The Dependency Chain Is Circular

A waits for B. B waits for C. C waits for A.

Circular dependencies can produce perfect inactivity.

The cycle must be broken by choosing one provisional input, changing sequence, lowering a requirement or assigning a decision owner.

Failure Mode 16: The Critical Path Is Hidden

A project may contain fifty tasks, but only a smaller subset determines the earliest possible finish.

The U.S. GAO Schedule Assessment Guide treats valid sequencing and critical-path analysis as core features of a reliable schedule.

The same principle applies to learning. A student can practise many things, but the critical learning path is the chain that controls access to the final capability.

Failure Mode 17: Buffer Is Placed in the Wrong Place

Buffer added downstream cannot always compensate for an upstream prerequisite arriving late.

Protect the dependencies whose delay propagates widely.

A useful buffer sits where uncertainty can still be absorbed before many later tasks are blocked.

Failure Mode 18: The Dependency Changes

A prerequisite map is not permanent.

New tools, new syllabus demands, new people, changed interfaces or changed goals can create new dependencies.

The system should be able to re-map rather than treating the original architecture as sacred.

Failure Mode 19: Repair Becomes Permanent Dependence

A scaffold can temporarily supply a missing dependency.

The danger is leaving it in place after the learner should carry the capability independently.

eduKate Punggol’s work on formula-sheet and tutor dependence shows this transition clearly: support can help early and become a hidden dependency later.

Failure Mode 20: The System Does Not Reconnect After Repair

Repairing a prerequisite is not the final state.

The repaired capability must be reconnected to the downstream task that originally failed.

Foundation work becomes useful when it unlocks current-level work.

eduKate Yishun and SETC both use this bridge-back principle: move backward only far enough to repair the missing link, then return forward quickly.

The Three Pillars of Reliable Dependency Design

1. Criticality

Separate what truly blocks the outcome from what is merely useful. Read How Dependency Criticality Works.

2. Timing

Make the prerequisite ready before the downstream task needs it. Read How Dependency Timing Works.

3. Substitution

When the original path is blocked, replace the required function without quietly changing the outcome. Read How Dependency Substitution Works.

A Practical eduKateSG Dependency Test

Target — what outcome are we trying to produce?
Dependency — what must be true first?
Type — hard, soft, conditional, shared or external?
Criticality — does failure block the outcome or merely reduce quality?
Owner — who makes it ready?
Readiness — what evidence proves it is usable?
Timing — by when must it be ready?
Propagation — what else fails if it is late?
Fallback — can another input preserve the same function?
Recovery — after repair, how do we reconnect to the target?

Example: Additional Mathematics

Target: solve a stationary-point application.

Dependency chain: differentiate → simplify derivative → solve quadratic → interpret stationary point.

If differentiation is correct but factorisation fails, the repair target is algebra.

Bukit Timah Tutor’s SEC Mathematics prerequisite architecture and eduKate Punggol’s A-Math prerequisite map both make this dependency logic explicit.

Example: Secondary English

Target: answer a difficult inference question.

Possible dependency chain: sentence access → reference tracking → literal situation model → evidence selection → inference → answer scope.

SETC’s catch-up system works backward only until the first unstable prerequisite that changes the repair.

Example: Publishing

Target: publish a live article.

Dependencies may include canonical ownership, verified factual claims, correct slug, internal links, final approval and a working final content state.

Some are hard blockers. Others can be repaired later. Criticality determines which must be ready first.

Across the eduKate Ecosystem

eduKateSG owns the general mechanism. How Learning Dependencies Work owns learning-specific prerequisite structure, while Dependency Mapping owns the generic mapping method. eduKate Punggol applies this to A-Math. Bukit Timah Tutor owns SEC Mathematics prerequisite architecture. SETC applies dependency repair to Secondary English. eduKate Yishun repairs the first broken dependency. eduKateSingapore shows how missed teaching becomes a prerequisite problem.