Appendix: illustrative delivery studies

The study slate uses a reference network and declared modifications to isolate delivery mechanisms. Every input is fictional, every output comes from the canonical Delivery atlas compute function, and every printed scalar is bound to its frozen input or output. The cases are not project observations. Their purpose is to make a reader’s inference testable: identify what changed, inspect what remained constant, reproduce the result and state the limit of the conclusion.

The reference parallel network produces expected duration 19.00 weeks. Supply and receiving both follow design, and assembly waits for both. The serial-release study changes only receiving’s predecessor from design to supply. Its duration is 25.00 weeks. The comparison isolates a topology change under the same task ranges. It demonstrates that sequencing can alter the conditional result without an increase in task durations. It does not establish that the parallel relationship is executable in any actual installation.

The duration-switch study changes only the supply range and produces expected duration 17.00 weeks. The selected path shifts to the receiving branch. The result shows why a local saving cannot be extrapolated indefinitely: another predecessor can become binding. The study contains no acceleration cost or supplier-capacity evidence. Its operational use is to identify the next question, namely whether the proposed shorter supply basis is executable and whether the now-binding branch deserves a separate intervention.

Illustrative. The interface-gate study inserts a readiness decision after assembly and before tests. It produces duration 22.00 weeks. This comparison illustrates omitted work rather than a productivity failure. The gate’s scope and range are authored assumptions. A real decision might have an uncertain outcome, different authority or an external calendar. The study should therefore be used to inspect the mechanism of including a release activity, not as a benchmark for how long approvals normally take.

Illustrative. The tied-branches study gives receiving the same range as supply. Expected duration remains 19.00 weeks and the engine counts 2 critical paths. The selected-path normal reading is 82.9%. This does not represent whole-network confidence. The case deliberately exposes a limitation: more than one branch governs the mean-duration finish while the approximation still evaluates a selected path. A reader should retain the distinction rather than infer equal reliability from an unchanged displayed percentage.

The earlier-target study changes only the deadline. Its duration remains 19.00 weeks and its selected-path reading is 17.1%. This verifies that a target changes interpretation of the approximation while leaving the network dates unchanged. The case is useful in a governance discussion because it prevents an aspirational date from being mistaken for a changed execution plan. A new promise needs an intervention or a different accepted scope, not merely a new deadline value.

Illustrative. The deterministic-path study sets each task range to its base most-likely value. Its duration is 19.00 weeks, standard deviation 0.00 weeks and conditional deadline reading 100.0%. The output follows the engine’s zero-variance rule. It supplies no empirical certainty. The case removes variation by assumption while retaining all the app’s other exclusions. It therefore demonstrates a computational boundary rather than a warranty of delivery.

Illustrative. The zero-milestone study adds a root release event with duration 0.00 weeks. Project duration remains 19.00 weeks. A milestone can preserve a meaningful event without adding elapsed work under the entered topology. Its operational credibility still depends on the evidence that the event occurred. An assumed zero-duration approval should not be used to hide review work or uncertain permission. The case distinguishes event representation from a claim about actual administrative effort.

Illustrative. The path-enumeration study replaces the reference with an explicit equal-branch network. Expected duration is 6.00 weeks, the engine counts 64 critical paths and displays at most 50. The case verifies bounded presentation separately from total counting. It does not imply that the displayed list is complete. A reader examining a highly branching project should use the count and the full input, not rely solely on the selected path or visible enumeration.

Boundary cases are useful because they can reveal silent assumptions. A zero duration tests whether a milestone is permitted. Equal branches test counting and uncertainty communication. A deadline equal to a deterministic finish tests the comparison rule. These are actual computational studies with frozen receipts. They should remain distinct from qualitative operational cases, which examine governance and readiness mechanisms outside the app. Both forms of analysis can be useful, but they support different kinds of evidence.

An imported fictional task refers to itself as a predecessor. The actual validator rejects it through cycle detection. The rejection is correct under the DAG contract, but the reviewer still needs to understand its cause. It may be a mapping error from another system or an attempted representation of repeated work. The correction differs. A mistaken identifier should be reconciled; a genuine iterative process needs another representation.

The author receipt preserves the executed rejection rather than creating a null duration and calling that a result. A rejected computation has no supported schedule output. The user should not replace it with the last successful result, because that would attach an unrelated network to the invalid input. Clear failure states preserve the integrity of the evidence chain. They also make input repair easier by identifying the unsupported property.

After repair, recompute the entire network and preserve the reason for the change. A removed edge can materially alter completion, so it is not merely a data-cleaning operation. The review should verify that the new topology expresses the intended release conditions. This case supplies no new numerical output; it explains the disposition of an actual validation class. Its lesson is that model admissibility and operational meaning must be restored together before a plausible chart deserves reliance.

The author ran invalid-input fixtures against the actual compute export. Cyclic dependencies, unknown predecessors, duplicate identifiers, self-dependencies, unordered ranges, negative durations, unsupported fields, nonfinite values and values below the numerical precision floor were rejected. The local receipt records the mutated input or construction basis, rejection message and engine hash. These are development observations of validation behaviour. They are not accepted schedule studies, and no duration or project output is fabricated for them.

A cycle deserves a substantive response. It may mean the input accidentally points backward, or it may mean the intended process contains rework that the acyclic model cannot represent directly. Repairing the first case requires a corrected dependency with a reason. The second may require explicit conditional scenarios or another model. Arbitrarily deleting a link to obtain a result changes the argument and should be recorded as such. A clear rejection is preferable to an unexplained plausible output.

An unknown predecessor can indicate a stale identifier after renaming or splitting work. The correction should reconcile the intended relationship rather than attach the task to whichever existing identifier looks convenient. A duplicate identifier can cause two obligations to become indistinguishable. These failures protect traceability as well as mathematics. The validation message should prompt review of the package mapping and dependency register, particularly when the input was imported from another planning system.

An ordered range can still be unsupported, but an unordered range has no valid meaning under this contract. The app therefore rejects it before calculation. Negative and nonfinite durations are likewise inadmissible. Unsupported fields are rejected because silently ignoring a calendar or resource field would invite a user to believe it affected the result. This strictness is useful for a small transparent tool. It makes the boundary inspectable rather than giving an impression of functionality that is not implemented.

The invalid receipts should be retained with the author evidence, while the public replication bundle supplies only valid frozen studies for reopening. A practitioner can use the rejection messages to repair input safely and recompute. The broader release decision still needs scope, evidence and authority. A valid schema is necessary for this calculation, but not sufficient for an external commitment. The appendix closes that distinction explicitly so passing validation is not confused with acceptance of the delivery plan.

A positive total float does not become zero because the supplied schedule is expressed at a small magnitude. The small-distinct-paths fixture has independent deterministic activities A and B, at 1e-09 and 9e-09 weeks, against target 5e-09. The selected critical activity is B. Activity A has total float 8e-09 weeks and is not critical. These implausibly small calendar values deliberately test the engine; they do not recommend a scheduling measurement resolution.

Illustrative. The equal-decimal-paths fixture tests a different distinction. A path with supplied durations 0.1 and 0.2 weeks and a direct path with duration 0.3 weeks have the same exact canonical decimal total. The engine therefore records 2 critical paths and duration 0.3 weeks. Its deterministic selected-path deadline result is 1 at the same 0.3 target. A positive increment to the direct path makes it strictly longer. The arithmetic does not estimate duration uncertainty; the normal approximation remains limited to its selected path when a nonzero range is supplied.