A task graph must encode evidence and effect dependencies as well as subgoal names

For each node, record preconditions, input identities, intended result, and a check that establishes completion. An analysis result can depend on a particular source revision, while a publishing action can require validation of the exact artifact to be published. A predecessor marked done without a matching version or evidence is not enough. Distinguish blocked preconditions from a failed attempt and from a completed effect. These states determine whether a node can be retried, skipped, or safely reused during replanning.

Edges express necessary ordering from data flow, validation, authorization, or shared-state effects. An ideal duration-weighted DAG gives a lower-bound schedule with sufficient resources; actual tools can queue or contend. If a tool returns before the effect completes, the node's completion boundary must include the required later confirmation. Do not start a consumer merely because a request was submitted. The graph should represent the external postcondition that matters rather than only the order of agent messages or internal plan statements.

Two branches that only inspect immutable snapshots may be independent. If one changes a configuration, deletes an artifact, or updates a record the other reads, that assumption fails. A conservative conflict check uses their read and write sets, but those sets must include the actual external resources and versions. Commutative operations or transactions can permit more concurrency under additional semantics. A vague label such as research and edit does not describe those effects precisely enough to decide whether parallel execution preserves the intended task.

Keep speculation distinct from real-world actions. Exploring two possible plans in local state does not authorize both branches to publish or mutate shared state. A durable workflow may retry an activity after uncertain completion, so effectful operations need an idempotency or reconciliation contract. Temporal documentation distinguishes observing one completed activity from the possibility that its code executes more than once. A plan or workflow checkpoint therefore does not by itself guarantee exactly-once external effects; retain operation IDs and verify the appropriate service postcondition.

Test a predecessor failure, a changed source after analysis, a lost effect acknowledgment, and two branches touching the same external state. Verify which descendants remain valid and which require new checks. Preserve successful immutable work where its inputs still match, but do not reuse a result only because its node has a familiar name. Measure completed-task success and duplicate or unsupported effects alongside elapsed time. A faster plan that omits a required validation or assumes an unobserved effect succeeded is a changed correctness contract rather than a clean scheduling improvement.

The queue lab models backlog, not dependency readiness. Reset, set both λ=4 and μ=2, predict backlog four initially and five after one Step, then inspect. Reset and set both λ=1 and μ=3 for backlog three after one Step and zero at two seconds. Its fluid formula is max(0,4+(λ−μ)t), with no DAG or external effects. The separate stable M/M/1 residence readout has Poisson/exponential assumptions. It illustrates service pressure only; actual node readiness and safe parallelism follow the explicit task and resource dependencies.