When the work actually happens.

#1. Working calendars

A calendar in Caladia is four things:

• Working days — a 7-tuple of booleans, Sunday through Saturday. The standard “5-day week” calendar has Monday–Friday on and weekends off.
• Hours per day — the working day length. Lets the scheduler convert between duration units (hours vs days vs weeks) without making the user choose.
• Holiday preset — one of US_FEDERAL, CANADA_FEDERAL, EU_COMMON, or NONE. Pre-baked sets of public holidays the scheduler treats as non-working days.
• Exceptions — arbitrary date overrides. A specific date can be flagged as a holiday (off) or a working day (on, even if it’s normally a weekend). Useful for one-off team events, planned overtime, or company-specific closures.

Holiday presets are version-pinned at save time. When you save a .cala file the preset version is written into the file; reloading later uses that pinned version even if Caladia’s defaults have moved on. Files never auto-upgrade on load.

#2. Resource pools

A resource in Caladia is a pool, not a person. A “QA team” pool with capacity 3 means three QA-shaped slots; activities that need a QA assignment draw from those slots. Capacity is an integer.

Every resource has its own working calendar. A contractor pool can have a different schedule from the in-house team; an offshore team can have its own holidays. The cost engine reads:

• costRate — per working hour, in the resource’s currency. Drives the time-based cost contribution.
• costPerUse — one-time fee per assignment instance. Models mobilisation charges, setup fees, per-engagement minimums.
• hourlyRateDistribution (optional) — lets the rate itself be uncertain. Monte Carlo samples a rate per iteration; the deterministic schedule still uses costRate. Useful when a contractor’s rate isn’t locked in.
• currencyOverride (optional) — pin a resource’s costs in a different currency from the project. An EUR-billed European team inside a USD project keeps EUR storage; FX conversion happens at the engine boundary at display time, using the bundled pinned snapshot.

#3. The effective calendar

An activity has its own calendar (or inherits the project default). A resource has its own calendar. When an activity uses a resource, which calendar governs?

Caladia computes an effective calendar per assignment, then resolves the activity’s effective calendar from the combination of all its assignments. A multi-resource activity ends up with one resolved calendar that respects the assignment-level policies (next section) for every resource it touches.

Practical consequence: different assignments on the same activity can have different conflict policies. A contractor assigned with resourceWins imposes their non-working days on the activity; an in-house engineer on the same activity with intersection can’t override the contractor’s gaps.

#4. Conflict policy

When an assignment’s calendars disagree — the activity says “work this day,” the resource says “off this day” — the policy decides:

• intersection — only days that both calendars consider working count. The strictest setting. Use this when the constraint genuinely needs both: an offsite consultant only working on days the office is open and they’re available.
• resourceWins — the resource’s calendar overrides the activity’s. The resource’s holidays and weekends are respected; the activity bends around them. Sensible default for the “person takes their PTO regardless of the project’s plans” case.
• activityWins — the activity’s calendar overrides the resource’s. Use sparingly — this is “the project says we’re working this weekend; you’re working.” Realistic only for crunch periods you’ve actually negotiated.

Policy is set per assignment, not per project or per resource. The same engineer can be on two activities with different policies if it reflects reality — resourceWins on their primary work, activityWins on a one-off launch weekend.

#5. Utilisation

The Resources tab surfaces a per-resource utilisation chart — for each working day in the project window, the number of assigned units against the pool’s capacity. Days that exceed capacity are flagged. The chart is computed from the deterministic schedule by default; switching to a simulation run shows utilisation as a percentile range across iterations.

Over-allocation isn’t automatically fixed — the scheduler reports it and leaves the decision to you. Two options:

• Re-plan — serialise parallel activities, push out non-critical ones, or split work across more resources. Worth it when the over-allocation is significant or the chart shows it’s structural.
• Use the auto-leveler — shifts the lowest-priority over-capacity activity to resolve a conflict, day by day. Manual priority on each activity is the soft escape hatch (“don’t move this one even if you could”).