How Superintelligence Works | Order and Dependencies — Why the Right Steps in the Wrong Order Fail

How does superintelligence work when an AI assistant has to complete several tasks in the right order? It may know every step and still fail if it prints a poster before the wording is checked, sends an invitation before the venue is confirmed, or reports a project finished when the final inspection has not happened. Intelligent planning requires more than a list of sensible actions.

The central mechanism is dependency-aware planning. A dependency says that one task must be completed, or a particular condition must be satisfied, before another task can safely begin. Some tasks can proceed together, some must wait, and some may need revisiting after evidence changes. Learning to represent those relationships is useful for students organising projects, teachers planning events and AI systems carrying out multi-step work.

This guide uses a completely fictional school science-exhibition project with seven tasks, exact durations, a critical path and sixteen checkable claims. None of the dates or timings describes an actual project or a deployed agent. “How Superintelligence Works” is the name of the learning series, not a claim that contemporary systems have achieved artificial superintelligence.

1. A list is not yet a plan

“Research the topic, draft the display, book the space, print the poster and set everything up” is a list of activities. It says little about what can happen at the same time, which tasks depend on earlier approvals or what a delay would affect. A usable plan needs these relationships.

An AI may create a polished checklist with every necessary item and still misunderstand the operational sequence. This is a different failure from forgetting a task: the ingredients are present, but their relationships are wrong.

2. What is a prerequisite?

A prerequisite is a requirement that must be met before some later step. For a school poster, accurate content must be drafted before that final content can be printed. For a venue-dependent display, the booked space may need to be confirmed so that the print size is appropriate.

A prerequisite should be grounded in the actual workflow. A system that assumes every task depends on every earlier task may waste time. Another system that assumes all tasks are independent may start work before the necessary information exists.

3. What is a dependency graph?

A dependency graph represents tasks as nodes and required orderings as directed connections. If task B requires task A, write A → B. The arrow says A must be completed before B can begin in the defined workflow.

When these connections do not form a loop, the graph is a directed acyclic graph, or DAG. Such graphs are widely used for scheduling, data processing and software build tasks. The graph does not itself prove that the listed requirements are correct; it only makes the declared structure explicit.

4. Why a cycle is a warning

Suppose an organiser says the topic must be approved before the poster can be printed, while another instruction says approval cannot happen until the final printed poster exists. Those requirements form a cycle. The project may be stuck unless one step is redefined, an approval of a draft is permitted or a different route is authorised.

An AI planner should flag the cycle rather than repeatedly attempt tasks in a loop and call the retries progress. A cycle may represent a genuine contradiction in requirements, not a need for more persistence.

5. Parallel work is possible when dependencies permit it

After a topic is approved, a pupil might research content while a teacher books an exhibition space. These activities need not wait for each other if the workflow allows them to proceed independently. Starting both can reduce the total project time.

But parallel work is not always safe. If two tasks edit the same document or reserve the same scarce resource, they can conflict. The dependency model should include those constraints instead of treating independence as a universal assumption.

6. Create the fictional Cedar Science Exhibition

Imagine a fictional Cedar School planning a small science exhibition. The organiser defines seven tasks, A through G. Each duration is an invented number of equal work units, not a forecast of real elapsed days. All work starts at time zero, and the unit-count model deliberately ignores weekends, holidays and staff availability.

The task list is complete for this toy calculation. There are no hidden approval steps. The purpose is to learn how task dependencies determine the earliest possible finish, not to promise when a real exhibition would open.

7. Seven tasks and their prerequisites

A — Confirm the topic: duration 1 unit, no prerequisite.
B — Research trustworthy sources: duration 3 units, requires A.
C — Draft and review the poster: duration 2 units, requires B.
D — Book the display space: duration 2 units, requires A.
E — Print the final poster: duration 1 unit, requires both C and D.
F — Set up the display: duration 1 unit, requires E.
G — Complete final safety review: duration 1 unit, requires F.

8. Draw the actual connections

The graph contains A → B, B → C, A → D, C → E, D → E, E → F and F → G. Notice the fork after A: both B and D can begin. Notice the merge before E: printing waits for C and D.

That merge is especially important. A model might check that the poster draft is ready and overlook that the booked space determines the final format. In this invented workflow, either missing prerequisite prevents E from starting.

9. Calculate the earliest finish of A

Task A begins at time zero and takes one unit. It finishes at time one. That is the earliest that either B or D can start, because both require A.

The calculation uses a simple convention: work starting at time t and lasting d units completes at t + d. A finish time is the boundary when the next dependent task may begin, not a separate full work unit.

10. Calculate the research branch

B starts at time one and takes three units, so it finishes at time four. C depends on B, starts at time four, takes two units and finishes at time six.

This creates the longer initial branch A → B → C. Its elapsed duration is one plus three plus two, or six work units before the poster draft is ready for final printing.

11. Calculate the venue branch

D also starts after A, at time one. It takes two units and finishes at time three. The venue branch A → D therefore completes three units after time zero.

The two branches are not added as though they ran sequentially. B and D begin together after A, and D finishes earlier. The earliest printing start is controlled by the later of the two required predecessor finishes.

12. The merge before printing

E requires both C and D. C finishes at time six, and D finishes at time three. Therefore E cannot begin until time max(6,3) = 6. E takes one unit, completing at time seven.

A model that adds all branch durations would overestimate the schedule. A model that selects the faster branch would underestimate it. At a merge, the start is governed by the latest required predecessor under this simplified scheduling model.

13. Finish the remaining work

F requires E, so F starts at time seven, takes one unit and completes at time eight. G requires F, so G starts at time eight, takes one unit and finishes at time nine.

The earliest overall completion under the stated assumptions is nine work units. This is a mathematical result about the fictional graph, not confirmation that any project has actually reached its final review.

14. The checked earliest-time schedule

A: start 0, finish 1.
B: start 1, finish 4.
C: start 4, finish 6.
D: start 1, finish 3.
E: start max(6, 3) = 6, finish 7.
F: start 7, finish 8.
G: start 8, finish 9.
Earliest completion of the full plan: time 9.
Parallel activity after A: B and D.
Longest dependency chain: A → B → C → E → F → G.

15. What is the critical path?

The critical path is the chain of dependent activities that controls the shortest possible completion time in the stated model. Here A → B → C → E → F → G has durations 1 + 3 + 2 + 1 + 1 + 1 = 9.

The shorter route through D is A → D → E → F → G, with durations 1 + 2 + 1 + 1 + 1 = 6 if considered without the simultaneous constraint through C. In the actual graph, E still waits for C. The critical path explains why C, not D, controls the earliest start of E.

16. What does slack mean?

D completes at time three in the earliest schedule, while E cannot start before time six because C is not yet ready. D therefore has three time units of scheduling slack before it would delay E, assuming no other constraints.

Slack is not permission to ignore D. If the booking remains incomplete when printing is meant to begin, it becomes a blocker. Slack describes flexibility under the model, not an assurance that delays are harmless under every real-world circumstance.

17. What happens if D is delayed by two units?

If D’s finish moves from time three to time five while all other task finishes remain as specified, E still starts at time six because C finishes at six. The overall earliest completion stays at nine.

The delay consumes two of D’s three slack units. This is a practical reason to examine dependency structure instead of automatically announcing a new deadline after every delay.

18. What happens if D is delayed by four units?

If D’s finish moves from time three to time seven, E must wait until time seven rather than six. E finishes at eight, F at nine and G at ten. The overall earliest completion shifts from time nine to ten: a one-unit delay.

The first three units of D’s additional delay consumed slack. The fourth pushed into the project’s critical sequence. This is why the effect of a delay is not necessarily equal to the delay’s full duration.

19. What happens if C is delayed by two units?

Suppose C finishes at time eight rather than six. D still finishes at three. E starts at eight and finishes at nine, F finishes at ten, and G finishes at eleven. The overall earliest completion shifts by two units.

C lies on the critical path in the original model and has no scheduling slack there. Not all activities have equal influence on the final completion date.

20. Sixteen statements for a simple AI test

The fictional planning desk asks an assistant to classify each claim as SUPPORTED, CONTRADICTED or NOT ESTABLISHED from the plan. The point is to test whether it distinguishes dependency logic from actual work status.

Nothing in the task graph confirms that the room has actually been booked or that a physical safety review has already occurred. Those are external states that require records or actions, even when the planned schedule is mathematically correct.

01. “B can start before A finishes.” — CONTRADICTED.
02. “B and D may run in parallel after A.” — SUPPORTED.
03. “C requires B to finish first.” — SUPPORTED.
04. “E may start while C remains incomplete.” — CONTRADICTED.
05. “F depends on E.” — SUPPORTED.
06. “G depends on F.” — SUPPORTED.
07. “The earliest completion under the model is nine work units.” — SUPPORTED.
08. “D finishes at time three in the earliest schedule.” — SUPPORTED.
09. “B finishes at time four in the earliest schedule.” — SUPPORTED.
10. “A two-unit delay in D must delay the whole project.” — CONTRADICTED.
11. “A two-unit delay in C shifts the earliest completion to time eleven.” — SUPPORTED.
12. “Booking the display space is unnecessary for E.” — CONTRADICTED.
13. “Research and space booking must be sequential.” — CONTRADICTED.
14. “The project is actually complete because every step has a planned finish.” — NOT ESTABLISHED: a schedule is not an execution record.
15. “The venue booking confirmation has been received.” — NOT ESTABLISHED.
16. “All the invented duration estimates are guaranteed to hold in a real project.” — NOT ESTABLISHED.

21. Check the results

Supported statements are 02, 03, 05, 06, 07, 08, 09 and 11: eight. Contradicted statements are 01, 04, 10, 12 and 13: five. Not-established statements are 14, 15 and 16: three. Eight plus five plus three equals sixteen.

Case 14 deserves an explanation: the graph does not establish that the project is actually complete, but absence of completion evidence is not proof that the project is incomplete. The confident completion claim is not established, rather than a verified contradiction about reality. Maintaining this distinction makes the classification logically consistent.

22. The difference between a plan and a completed action

A planner can predict that printing happens at time six. It cannot conclude that a printer actually printed anything without an execution record. Likewise, a task marked “scheduled” is different from a task marked “started”, “completed”, “failed” or “cancelled”.

An AI agent needs state-aware tool results. A polished checklist with green-looking completion language is not evidence that the underlying actions occurred. Responsible systems verify and record the effect of each external operation.

23. How dependencies can be hidden inside documents

A school notice may say “Submit the final proof after the coordinator approves the draft.” The words after and approves encode a prerequisite. If the assistant extracts only “submit final proof”, the resulting plan may omit the approval step.

Useful plan extraction identifies the actor, action, prerequisite and any approval authority for each step. It also retains the original passage so a reviewer can check whether the model has interpreted the condition correctly.

24. Necessary does not always mean immediately preceding

Task A is a prerequisite for C indirectly through B. That does not mean C must start immediately when A finishes. Task B still has to be completed. Prerequisites can be indirect and transitive in a specified task graph.

A system that tracks only direct neighbours might miss distant blockers. Conversely, blindly inferring dependencies that the workflow never required can create false obstacles. The graph should represent the intended work, not a generic assumption that every earlier item matters.

25. Resource conflicts complicate the schedule

Our toy model permits B and D to run in parallel. But what if the same person is required to perform both and can do only one at a time? Then the parallel schedule may not be feasible without extra staff or changed priorities.

This is the difference between a dependency-constrained earliest schedule and a resource-constrained real plan. A critical path calculation alone cannot guarantee the shortest achievable completion when staffing, equipment, budget or opening hours limit the work.

26. Time estimates are not certainties

Task durations in a classroom graph may be fixed numbers for ease of calculation. Real activities vary. A printer can fail, research can uncover a missing source, or a venue booking can require another approval.

A reliable project report distinguishes estimated and actual duration, including uncertainty where appropriate. It should not call time nine a guaranteed opening date merely because the arithmetic for the fictional model is correct.

27. What to do when a prerequisite fails

If D fails because the display space is unavailable, E cannot be treated as ready under our original rule. The team might choose another space, redesign the poster or postpone printing. Those are alternative plans requiring explicit decisions.

An AI that automatically retries the booking forever may waste resources. A good workflow identifies the failed dependency, limits retries, reports the blocker and asks for an authorised alternative when the original plan is no longer feasible.

28. Why retrying can create duplicate actions

Suppose an agent submits a venue reservation request but the network connection breaks before a receipt is returned. It should not assume the reservation failed and blindly submit another identical request if that might create a duplicate booking.

Systems often use durable request identifiers and safe retry mechanisms for this reason. A language model that knows the words “book the room” still needs an application design that distinguishes unconfirmed outcomes, duplicate attempts and verified success.

29. A classroom transfer exercise

A pupil must choose a research question, collect data, make a graph and write a conclusion. The graph depends on the data, and the conclusion depends on the graph and the interpretation of the data. What can happen in parallel? The pupil might draft the background explanation while data collection proceeds, if the chosen research question is already clear.

Now ask what happens if the data are unreliable. The conclusion cannot safely proceed as though the data were trustworthy. The problem is not simply a slow task; a prerequisite quality check may have failed.

30. A household transfer exercise

Imagine baking a cake. You need an oven brought to the required temperature and a prepared mixture before baking can begin. These prerequisites can often be worked on in parallel. Baking then needs the correct time and temperature before the result can be assessed.

A plan that says “turn on the oven, mix ingredients, put the cake in” might be sufficient as a friendly reminder, but a dependable procedure should retain the temperature and readiness requirements. The right level of detail depends on the task and consequence.

31. AI tools can help check a dependency graph

A developer can encode task nodes and prerequisite arrows in data, then use a graph algorithm to check for cycles, identify a valid topological ordering and calculate earliest completion times with known durations. Those deterministic checks are valuable companions to natural-language planning.

The AI can translate a user’s description into candidate nodes and edges, but a human or authoritative workflow should review whether those candidate dependencies are correct. A graph algorithm can be flawless while operating on a misunderstood instruction.

32. The fictional baseline and repair

Suppose a made-up planning assistant gets twelve of the sixteen classification questions right. It assumes all tasks must run sequentially, misses E’s dependency on D, calls a planned finish an actual completion and claims a delay in D always shifts the total finish. The invented score is 12/16 = 75%.

A revised teaching-only assistant draws the graph, checks each prerequisite and distinguishes planned from observed state. Suppose it answers all sixteen correctly. That local 16/16 is a demonstration of the method, not measured evidence of a real model’s ability to manage projects autonomously.

33. Keep scope and authority visible

A school event plan may include activities a student can draft but cannot approve or publish. The dependencies should reflect those authority boundaries: a pupil can prepare a proposed invitation, but sending an official notice may require a teacher’s approval.

Logical task readiness is therefore not permission. Even when an automated planner knows the next step, an agent should use only authorised tools and verify the action’s result before reporting completion.

Frequently asked questions

What is a dependency? A task or condition that a later task requires before it can proceed.

What is a directed acyclic graph? A set of nodes and directed links without a directed cycle.

What is the critical path? The dependency chain controlling the earliest completion under the stated scheduling model.

Do all tasks have to be sequential? No. Independent tasks can often proceed in parallel, subject to resource constraints.

Does a schedule prove the work happened? No. It describes a plan, not independently verified execution.

Can a delayed task leave the overall deadline unchanged? Yes, if it has sufficient slack and no other constraints change.

Should an agent retry a failed booking forever? No. Retrying needs limits, verified state and protection against duplicate actions.

The central lesson

Knowing what must be done is only the beginning. A reliable AI plan knows what must happen first, what can happen together, what cannot start until a prerequisite is confirmed and what a delay will actually change.

The strongest practical habit is to draw the dependency arrows and separate planned progress from verified progress. When those relationships remain visible, a person can challenge a schedule, repair a blocker and prevent an assistant from declaring success before the last real task is complete.