Appendix: network calculation specification

The replication contract is the actual Delivery atlas input schema and compute function. A study contains a target deadline and a task list. Each task has a stable identifier, a human-readable name, optimistic, most-likely and pessimistic elapsed durations, and a list of predecessor identifiers. The app validates the object before calculating. This appendix describes the mechanism so a reader can inspect the frozen input rather than trust a published chart. The public bundle preserves the machine-readable input and output alongside scalar bindings.

Identifiers carry dependency meaning. A predecessor refers to an identifier, not to the task’s display name or position in the list. Renaming a task therefore need not alter topology, while changing an identifier requires reconciliation of its references. The model rejects duplicate identifiers, unknown predecessors and self-dependencies. The paper retains the fictional reference identifiers from design through acceptance. Their simplicity supports inspection; it does not imply that an actual project should use the same naming convention.

Durations use a common continuous elapsed-week basis. Each task range must be nonnegative and ordered from optimistic through most-likely to pessimistic. The actual validator also enforces finite values, field structure, identifier rules and numerical precision limits. A zero duration is valid for a milestone under the stated schema. Tiny nonzero values below the accepted numerical precision are rejected rather than silently rounded into a milestone. These checks protect the calculation’s input integrity; none validates an estimate’s empirical plausibility.

The schema has no resource, calendar, lag, lead, monetary or acceptance-outcome fields. Adding such a field to a study does not make the engine calculate it; unsupported structure is rejected. The wider practitioner records in this paper therefore remain outside the canonical numerical input. They explain how the network can be used responsibly. A replication user should preserve that boundary when importing a known study into the companion tool rather than assuming the narrative’s governance and resource analysis have become automatic outputs.

The target deadline is an interpretation input for the selected-path normal reading. It is not a task constraint that changes the forward and backward dates. The earlier-target study verifies this distinction by retaining the network and changing only the deadline. A user who expects a deadline to drive resource levelling or automatic recovery is asking a different question from the one implemented. The app does not optimise a network to meet a target.

The compute function first validates the input and builds the dependency graph. It determines a topological order so each predecessor is processed before its successor. A cycle prevents such an order and is rejected. This matters operationally: a rework loop cannot be represented directly as an acyclic finish-to-start network. It needs a declared conditional scenario or a different modelling method. Breaking a cycle arbitrarily to obtain an output would change the causal model and should not be treated as a harmless formatting repair.

For each task, the canonical method transforms the entered range into an estimated mean and variance. The printed method is PERT mean = (optimistic + 4 × most likely + pessimistic) / 6. Variance = ((pessimistic − optimistic) / 6)^2. These quantities are conditional on the inputs. The forward pass propagates early dates; the backward pass uses the calculated project finish to derive late dates and float. Reproduction checks the exact output object, not merely whether the displayed project duration resembles an independently typed number.

Illustrative. Critical activities have exactly zero total float under rational PERT means constructed from canonical input decimals. Critical paths connect start to finish through those activities with exact contiguous early times; a small positive gap is not converted into a tie by an absolute tolerance. The canonical reporting method is Every critical path is a start-to-finish path of zero-float activities with contiguous earliest times. At most 50 are displayed. The implementation counts qualifying paths and enumerates a bounded list. Numeric table values, square roots and the normal deadline approximation retain their separately declared display or approximation scope. In a branching network, the path count can exceed the list length. The total count should travel with any display of selected paths. A visible list alone cannot substantiate a claim that every critical route has been reviewed.

Illustrative. The retained method states: Deadline probability uses a normal approximation with variance summed on the first displayed critical path. The corresponding standard deviation is evaluated against the stated deadline. When the selected variance is zero, the implementation uses a deterministic boundary rule. This is a method disclosure, not an endorsement of the approximation for every project. The exclusions in the output remain essential: no dependence, competing-path simulation or warranty of contract completion is supplied.

The optimistic and pessimistic network scenarios are calculated by separate forward passes using the respective task estimates. Their labels refer to the input cases. They do not define statistical confidence intervals or absolute bounds. A task whose scope or approval outcome is absent remains absent in all those passes. A reader should therefore inspect the network and its perimeter before interpreting the envelope. Exact arithmetic cannot reveal missing obligations that the input never declared.

The reference input lists design release, equipment supply, receiving works, assembly, integrated tests and acceptance. Design is the predecessor of supply and receiving. Both are predecessors of assembly. Testing follows assembly, and acceptance follows testing. This is a simple but complete declared topology for the fictional study. It lets a reader see where parallelism exists and which event joins the branches. The table below preserves the numerical inputs through ledgered tokens rather than manually retyping them.

A replication review should begin by matching each task to its narrative boundary. Supply ready means the fictional accepted equipment event, not merely procurement expenditure. Receiving ready means the fictional assembly interface. The initialisation script’s task names and study purposes record those meanings. A user can change labels locally, but changing a boundary requires a new input basis and possibly a new topology. Renaming alone cannot establish that the model now represents a different real obligation.

Next inspect what each comparison changes. Serial-release alters the receiving predecessor. Duration-switch alters supply estimates. Interface-gate adds a readiness activity. Tied-branches alters receiving estimates. Earlier-target alters only the deadline. Deterministic-path collapses ranges. Zero-milestone adds a release event without duration. Path-enumeration replaces the topology with an explicit equal-branch boundary fixture. These changes have different purposes and should not be blended into one claim about a single recovery intervention.

The reproduction bundle includes full outputs, not only the scalar values used in prose. This supports inspection of task dates, float, selected paths, count, warnings, methods and scenario durations. Scalar bindings connect published tokens to exact input or output pointers. The audit reruns the canonical compute function and checks equality with the frozen output. A mismatched output is a substantive reproduction defect that must be resolved before the manuscript can rely on it. Formatting a rounded display does not alter the frozen value.

The bundle is a computational record, not a field data package. It contains no client, observed productivity or actual contract. Its valid numerical comparisons demonstrate mechanisms under stated assumptions. A practitioner applying the method should create a separate authorised input with current scope, resources, calendars and evidence as needed, then use an appropriate execution system for features outside this small engine. The paper’s replication path is useful precisely because its claims are narrow enough to be tested.

A replication user reopens a known fictional study in the companion app. The study's input and model-version metadata determine what can be recomputed. A saved display or exported result is not treated as an independent authority. This protects against stale output after an engine change or a local input edit. The user should inspect the loaded task meanings and the result's warnings before using the comparison.

The scenario vault preserves canonical input-only records. Unsupported versions are rejected rather than silently accepted as if they were equivalent. A valid import is recomputed through the implemented model. The publication's frozen output remains available for exact reproduction checks, while a modified local scenario has its own new result and basis. These are different records. Editing a scenario does not revise the published paper or establish an actual project forecast.

A practitioner using the workflow should give the local scenario a clear purpose and declare changes. The value of the vault is continuity and reviewability, not automatic acceptance. Local persistence requires the user's explicit opt-in; memory use can support a session without external transmission. These platform properties are separate from the schedule mathematics. The replication chain remains narrow: a supported input is recomputed, the conditional output is inspected, and the authority decides what additional evidence is required for reliance.

A reproducible study needs the engine version as well as input and output. The audit records hashes of the compute module, its imported method and shared modules, and the runner. An implementation change can affect validation or output even when the visible app title is unchanged. A retained study should not be reopened under an unsupported model version without warning and recomputation. The public scenario vault preserves inputs and version metadata rather than treating saved outputs as authority.

When the engine changes legitimately, refresh the frozen record through the controlled production procedure and review affected manuscript claims. Do not edit an output JSON by hand to make a comparison pass. Do not duplicate the mathematics in an author script and claim canonical reproduction because it reaches a similar result. The authoring helpers select scalar pointers and write explicit prose; they do not replace the app’s compute function. This separation keeps the numerical authority inspectable.

A reader may compare the app with another scheduling tool. Differences can arise from calendars, resource constraints, relationship types, rounding, milestone rules or uncertainty methods. Reconcile these bases before calling one output wrong. The frozen input is intentionally narrow and continuous. A richer execution programme may be more suitable for a real project, but it should explain how its scope and methods differ. Agreement of a single project duration is insufficient to establish equivalence of the full model.

Validation failures should remain visible. A cycle, unknown predecessor or unordered range is rejected because it prevents a supported computation under this contract. The appropriate response is to repair the declared input with a reason, or choose a model that supports the intended structure. Returning a plausible-looking schedule from invalid input would be worse than a clear refusal to calculate. The invalid-fixture receipts in the next appendix record actual rejection behaviour without publishing an invented project result.

Finally, replication should serve a decision. A reader can reopen the reference study, verify the published values, change a declared assumption and inspect the consequence. The result should be accompanied by the input basis and limits. This creates a transparent evidence-to-model link while leaving the authority’s judgment explicit. The tool does not approve a baseline, a recovery intervention or an external promise. Its value is to make the conditional numerical argument reviewable.