What the numbers mean.

#1. Percentiles — P50, P80, P95

Caladia’s Monte Carlo doesn’t return a single answer. It runs the schedule thousands of times, sampling each activity’s duration from its distribution, and gives you a probability curve over possible finish dates. The verdict bar surfaces three points on that curve.

• P50 — the median. Half of simulated runs finish on or before this date.
• P80 — the planning number. There’s an 80% chance the project finishes on or before this. Commit to this, not P50.
• P95 — the pessimistic edge. Useful for stress tests and as the upper bound on schedule contingency.

The gap between P50 and P80 is the project’s uncertainty. A tight gap means the plan is well-constrained — the distributions are narrow, dependencies are clean, no single activity dominates the risk. A wide gap is the price of accepting an optimistic baseline.

Cost percentiles work the same way on the cost S-curve. The shape of that curve and where P80 sits is independent of the schedule curve — a plan can have tight schedule risk but wide cost risk, or vice versa. Both surface as verdict-bar tiles.

#2. Critical path

The critical path is the longest chain of dependent activities through the plan. Its length sets the deterministic finish date — and any delay on a critical-path activity propagates one-for-one to the project finish.

In Caladia’s Gantt, critical-path bars are coloured; non-critical bars are softer. The empty space at the end of a non-critical bar is its slack — how much that activity can slip before it becomes critical too.

Two things worth knowing:

• Critical paths can shift. When you re-estimate a duration, add a dependency, or run a what-if scenario, the longest path through the network can switch to a different chain. Caladia recomputes it on every edit.
• Monte Carlo changes the meaning. In a stochastic plan, every iteration may put a different chain on the critical path. The deterministic critical path is just one answer; the more useful question is “which activities are often critical?” That’s the criticality index, next.

#3. Sensitivity — criticality index and ρ

Two related measures, both surfacing on the Risks tab.

Criticality index is, for each activity, the fraction of Monte Carlo iterations in which that activity sat on the critical path. An activity with criticality 0.95 is on the critical path nearly always; one with criticality 0.10 only becomes critical when its neighbours slip enough that the schedule rearranges around it.

Sensitivity ρ (the schedule tornado axis) is the correlation between an activity’s sampled duration and the project’s sampled finish date across all iterations. ρ ≈ 1 means “when this activity runs long, the project runs long.” ρ ≈ 0 means “this activity’s duration has no relationship to the finish.”

The tornado chart ranks activities by |ρ|. The top bars are where to focus scheduling attention: re-estimate, add a buffer, or de-risk. Activities with low ρ but high criticality typically sit on a near-deterministic chain (predictable durations); activities with high ρ but middling criticality are on a parallel chain that occasionally dominates the schedule when it runs long.

The same logic applies to the cost tornado (Risks tab → Cost), with ρ measured against the project’s sampled total cost. The two tornadoes often rank activities differently — the biggest cost driver isn’t always the biggest schedule driver.

#4. Parallelism

If two activities share no dependency, they can run in parallel — overlapping in time. Parallel paths compress the schedule: the project finishes when the longest parallel chain completes, not when the sum of all chains completes.

But parallelism has a cost. Activities that overlap may compete for the same resource, and Caladia’s Resources tab surfaces over-allocation: if Alex is scheduled for two activities simultaneously, that’s a flag, and the assignment’s conflict policy decides what to do (the calendar resolves to the resource’s, the activity’s, or their intersection — whichever you’ve set).

The planning trade-off:

• More parallelism → shorter schedule, more resource pressure, more fragility to single-resource delays.
• More serialisation → longer schedule, calmer resourcing, more robustness but more wall-time before the work is done.

A useful exercise: in a scenario, force a parallel pair to run sequentially (add a dependency or a lag) and compare the P80 finish dates against the original. The delta tells you what the parallelism is worth — and what you’d give up to reduce risk by serialising.