Cost modelling.

#1. Where costs come from

Every activity’s cost contribution splits into three buckets that sum to its total. The Risks tab surfaces the breakdown per node.

• fromResources — resource hours × hourly rate, plus per-use fees. Driven by duration and resource assignments.
• fromFixed — node-level fixed costs (permits, materials, license-per-run fees). Independent of duration.
• fromCrash — additional fees from a selected crash option (see §4). Zero otherwise.

#2. Resource rates

Each resource pool has up to four cost-related fields. All optional; absent fields contribute zero.

• costRate — per working hour. Multiplied by hours-worked on each activity the resource is assigned to, plus the assignment count.
• costPerUse — one-time fee per assignment instance. Mobilisation charges, fixed-fee setups, per-engagement minimums.
• hourlyRateDistribution — rate uncertainty for Monte Carlo. The deterministic schedule keeps using costRate; per iteration, MC samples the rate from this distribution and applies it to all of the resource’s hours that iteration. Useful when a contractor’s rate isn’t pinned — e.g. triangular(min: 80, mode: 100, max: 150).
• currencyOverride — 3-letter ISO 4217 code. When set, this resource’s cost fields are denominated in the override currency, not the project’s. See §8.

#3. Fixed costs on activities

Activities and decision nodes can carry a fixedCost object alongside their resource assignments:

• fixedCost.value — the deterministic charge.
• fixedCost.distribution — optional. Triangular, PERT-beta, or normal on the value. Sampled per Monte Carlo iteration; the deterministic schedule uses the static value.

Loop semantics. Fixed costs on activities inside a loop body charge per iteration by default: re-permit, re-test, re-certification. Set fixedCostOnce: true on the node when the fee is genuinely one-time across iterations (an asset already paid for, being re-used).

With a distribution AND a loop body, Monte Carlo samples the cost value once per iteration and multiplies by the sampled loop count — the unit cost is uncertain, the count is uncertain, the product reflects both.

#4. Activity crashing

Crashing is the project-management term for compressing an activity’s duration by spending more — overtime, expedited materials, additional staff. Less time, more cost. Caladia models the trade-off per activity so the simulation can show what each compression option costs you.

An activity can declare one or more crashOption entries:

• duration — the compressed duration (must be smaller than nominal, same unit).
• additionalCost — one-time fee added to fromCrash when this option is selected.
• An optional resource-rate multiplier (default 1.0) that scales fromResources while the option is active. Common values:
  • 1.0 — pure expedite. Resource cost shrinks linearly with the compressed duration; the vendor surcharge sits in additionalCost.
  • 1.5 — time-and-a-half overtime.
  • 2.0 — double-time / weekend OT or a premium contractor.
  • nominal / compressed — “preserve effort”: same total resource cost packed into less wall-clock at a higher rate.

Select an option via selectedCrashIndex; the node’s duration and resource cost both update. Unselected, the node behaves as if it has no crash options. The multiplier scales fromResources only — costPerUse and additionalCost are not scaled.

Example. “Ship in four days instead of seven via overtime — $5k flat plus 1.5× rate on the team’s hours.” One crashOption: duration 4d, additionalCost: 5000, multiplier 1.5.

#5. The cost tornado

The Risks tab shows two tornadoes from the same Monte Carlo run:

• Schedule tornado — activities ranked by |ρ| against the project finish date.
• Cost tornado — activities ranked by |ρ| against the project total cost.

The same activities can rank very differently between them. An activity on a parallel chain that rarely sits on the critical path might dominate the cost tornado (its resource is expensive, its fixed cost is uncertain) while being middle-of-the-pack on schedule. Or the inverse: a tight-distribution activity on the critical path drives schedule risk while contributing little cost variance.

Schedule risk points to where to add buffer or re-estimate. Cost risk points to where to renegotiate rates, push for a flat fee, or reduce scope.

#6. The cost S-curve

Cumulative cost over the project timeline with P10–P95 bands shaded around the central curve. Rendered on the Simulate tab alongside the schedule S-curve and histogram.

The shape tells you when the spend happens:

• Front-loaded: procurement / mobilisation-heavy projects. Most of the cost commits early.
• Back-loaded: execution-heavy work; resource hours land late.
• Wide bands mid-project: long-running expensive activities with uncertain durations.

Used for pacing payment milestones, identifying cash-flow inflection points, and comparing scenarios on burn rate rather than just total cost.

#7. Budget and the probability tile

Set an optional top-level budget on the project (non-negative number, in project currency) and the verdict bar grows a fourth tile: “% chance of meeting budget.” It’s the cost distribution’s CDF evaluated at the budget value — the fraction of Monte Carlo iterations that finished at or under the budget.

Useful for communicating cost risk as a single number: “82% chance of finishing under $1.2M.”

Set the budget at the externally-committed number (customer commitment, board-approved figure, contract ceiling), not your own P80 cost. At the P80 cost the probability is by definition 80%; the tile only carries information when the budget is a real constraint.

#8. Multi-currency and FX pinning

For projects with international teams or vendors invoicing in non-project currencies:

• Each resource can carry an optional currencyOverride (3-letter ISO 4217). When set, that resource’s costRate, costPerUse, and hourlyRateDistribution are denominated in the override currency, not the project’s. Storage is verbatim.
• The cost engine returns project-currency totals; FX conversion happens at the engine boundary.
• The verdict bar and tornado can display in the project currency or any other bundled currency.

FX snapshots are pinned at save time via the project-file’s fxSnapshotVersion field. Reopening a 2024 plan in 2026 uses the 2024 rates the file was authored against; files never auto-upgrade on load. See File-format reference · Version-pin policy.

The optional fxRateOverrides field overrides specific rates on top of the snapshot. Sparse map of ISO code → foreign-per-1-USD-base; absent entries fall through to the snapshot.