eduKate Singapore

How to Categorise Dependencies | Type, Direction, Criticality, Timing, Substitution and Failure

A dependency exists when one thing relies on another for completion, validity, operation, meaning or survival.

Tasks depend on approvals. Software depends on libraries. Schools depend on teachers and infrastructure. Claims depend on evidence. Processes depend on inputs. Systems depend on energy, networks and other systems. The word depends covers several different structures, and those structures matter when something fails.

The main classification axes

  • Type: resource, temporal, technical, informational, legal, organisational, logical?
  • Direction: what depends on what?
  • Criticality: does failure degrade or stop the dependent?
  • Timing: prerequisite, concurrent, ongoing, delayed?
  • Substitution: can another dependency take over?
  • Visibility: explicit, inherited, hidden?
  • Propagation: how far does failure travel?
  • Ownership: who controls or monitors the dependency?
  • Recovery: how quickly can the dependency be restored or bypassed?

This article complements How to Categorise Relationships: dependency is one important relation family, while this page focuses on operational forms of reliance and their consequences.

Dependency is not the same as association

Two things can be related without one requiring the other. Dependency implies that changing or removing one can affect the ability of the other to function, proceed or remain valid.

Direction should always be explicit

If Task B depends on Task A, the reverse does not automatically follow. Ambiguous arrows create planning errors.

Prerequisite dependencies control sequence

Approval before publication, foundation before structure, and basic arithmetic before algebra are examples where one state must exist before another can begin reliably.

Resource dependencies require supply

People, money, materials, energy, data, tools and space can all be dependencies when work cannot proceed without them.

Technical dependencies require compatibility

Software packages, interfaces, protocols, hardware, operating systems and data formats may create hard technical reliance.

Informational dependencies require knowledge

A decision may depend on a forecast, a calculation may depend on input values, and a claim may depend on evidence whose provenance and freshness matter.

Logical dependencies connect propositions

A conclusion can depend on premises. If one premise fails, the argument may need revision even though the conclusion could still happen to be true for another reason.

Legal and authority dependencies constrain legitimacy

A permit, mandate, consent or approval can be a dependency even when every physical resource is available.

Organisational dependencies cross boundaries

One team may rely on another for data, review, manufacturing, support or release. These handoffs need owners and service expectations.

External dependencies reduce direct control

Suppliers, regulators, weather, markets and third-party platforms can be essential while remaining outside the dependent system’s authority.

Internal dependencies can still be fragile

Ownership inside one organisation does not guarantee availability, capacity or good coordination.

Hard dependencies stop progress

If the dependency is absent, the dependent task or system cannot proceed in an acceptable way.

Soft dependencies affect quality or efficiency

Work may continue with degradation, extra cost or lower confidence when a preferred support is unavailable.

Single-point dependencies create concentration risk

One supplier, one expert, one server, one credential or one data source can become a single point of failure.

Redundant dependencies improve resilience

Multiple independent suppliers, backups or routes reduce the chance that one failure stops the system.

Redundancy is useful only when it is independent

Two suppliers using the same upstream factory may look redundant while sharing the same hidden point of failure.

Substitutable dependencies can be rerouted

If another resource, tool or provider can fulfil the same role with acceptable performance, failure is easier to contain.

Partial substitutes create degraded modes

A backup may preserve core function while reducing speed, precision, capacity or convenience.

Temporal dependencies create lead time

Some dependencies are available only after curing, shipping, training, approval or data accumulation. Availability today and availability eventually are different states.

Concurrent dependencies must remain available during operation

Electricity, network access and active authentication are examples where dependency is continuous rather than one-time.

Version dependencies can silently break systems

A system may depend not only on a component, but on a specific version, interface or behaviour of that component.

Hidden dependencies are especially dangerous

Inherited scripts, undocumented experts, copied datasets and informal workarounds can support critical work without appearing in the official architecture.

Circular dependencies create deadlock risk

If A waits for B while B waits for A, neither can progress. Some cycles are legitimate feedback structures; others are planning defects.

Dependency chains amplify upstream failure

A small upstream outage can disrupt many downstream systems if the graph is deep and highly connected.

Dependency criticality should be measured by consequence

Ask whether loss creates delay, degraded service, financial loss, unsafe operation or total failure.

Time to failure matters

A system with a three-day buffer has more response time than one that fails immediately when the dependency disappears.

Time to recovery matters too

A critical dependency that can be restored in minutes differs from one requiring months to replace.

Dependency ownership should be explicit

The dependent team, supplier, platform owner and risk owner may all hold different responsibilities.

Monitoring should focus on material dependencies

Not every minor relation needs live telemetry. Critical, volatile and externally controlled dependencies deserve stronger observation.

Change impact begins with dependency mapping

Before replacing a component, rule or dataset, identify what depends on it so downstream consequences are not discovered after release.

AI can infer dependency candidates

Models can extract “requires”, “uses”, “blocked by” and “depends on” relations from text, but inferred edges should remain linked to evidence and confidence.

A practical dependency record

  • dependency ID;
  • dependent entity;
  • dependency entity;
  • dependency type;
  • direction;
  • hard or soft;
  • criticality;
  • timing and lead time;
  • substitutes;
  • buffer;
  • failure consequence;
  • time to recovery;
  • owner;
  • evidence and source;
  • version.

The deeper idea

Dependencies are where systems stop being isolated objects and become vulnerable networks of reliance.

To categorise dependencies well is to know what relies on what, how critically, for how long, with what substitutes, and how far failure can propagate if the dependency disappears.

Final answer

Categorise dependencies by type, direction, criticality, timing, substitutability, visibility, propagation, ownership and recovery. Keep dependency separate from mere association, identify single points of failure and hidden shared dependencies, and use the dependency map to improve sequencing, resilience and change control.

Continue through the series

Explore the connected learning guides

Choose the question that brought you here. Open one useful guide, try a small task, and stop when you have what you need.

Take one question further

The same learning habit can travel across subjects, while each subject keeps its own methods. These routes help you notice a difficulty, understand one part of it, and return to something you can do.

A word is familiar, but using it is difficult.

Move from recognising a word to retrieving it in a new context. Understand vocabulary plateaus.

Try it without the guide: Choose one word you already know. Close the guide and use it in a new sentence. Explain why it fits; try another context tomorrow.

A piece of writing has ideas, but the reader loses the thread.

Make the order of events and the links between sentences clear. Explore composition writing.

Try it without the guide: Choose one short paragraph. Read the relevant explanation, close it, and revise the paragraph. Ask someone to tell you what happened and why.

The Mathematics seems familiar, but marks still disappear.

Find the first point where the working stops being reliable. Find Secondary 4 A-Math mark leakage.

Try it without the guide: For a Secondary 4 A-Math question you have attempted, locate the first uncertain line. Repair that step, then try a comparable question without the worked answer.

A Science fact is remembered, but the explanation is incomplete.

Connect the evidence to a scientific idea and the resulting change. Follow the Primary Science learning route.

Try it without the guide: Choose a familiar Primary Science example. Explain the evidence, the idea and the result without notes. Then change one condition and explain your prediction.

Two accounts of the world seem to disagree.

Check the question, source, date and evidence before combining claims. Explore the World Knowledge research library.

Try it without the guide: Take one claim. Find the source best placed to support it, note its date, and state what remains uncertain. Return to your original question.

There is plenty of help, but independence is hard to see.

Check what the learner can understand and do after support is removed. Understand how education works.

Try it without the guide: Choose one small task the child has practised. Agree on a calm, brief attempt without prompts. Use what happens to choose one next step, then stop.

For the structure behind these connections, read the eduKateSingapore runtime manifest and the eduKate ecosystem boot contract. The reader map describes public navigation; those manifests preserve the wider ownership and return rules.