# Scheduling

> A plan that still holds after something changes: the project schedule recalculated under dependencies and people's capacity, and a shift roster built to cover demand - by a solver, with a preview before anything is written

Source: https://aipril.dev/docs/scheduling

## Why the plan stops being true

The plan was right on the day it was approved. Then one task slipped by three days, a designer went
on holiday, and a client moved a milestone forward.

Each change is small. Following it through is not: the slipped task pushes four others, two of them
now land on a person who already has a full week, and the milestone that moved forward depends on
both. Somebody opens the Gantt chart and starts dragging bars. After an hour the dates look
plausible, and nobody can say whether the plan is still feasible - only that it no longer shows red.

Rosters work the same way. Coverage for next week is built by hand from a spreadsheet of who can do
what, then rebuilt when two people call in sick, and a gap nobody noticed shows up on Saturday
morning.

**None of this is a discipline problem.** A plan with a hundred tasks and a dozen people has more
interacting rules than a person can keep in their head while dragging bars.

## What that costs

- **The plan is decoration.** Once it stops being recalculated it stops being believed, and the real
  schedule moves into people's heads.
- **Overload is found late.** Nobody sees that one person is booked at 160% in week three until week
  three.
- **Every replan starts from zero.** Redrawing by hand also moves work that did not need to move,
  and people learn to ignore the new dates.
- **Rosters have holes.** A shift that needs a certified person is covered by somebody who is not,
  because the spreadsheet did not know.

## What is different here

**The plan is recalculated, not redrawn.** Press recalculate and a solver finds a schedule that
satisfies every dependency, every person's capacity, every earliest start and every hard finish at
once. Work that has already started is pinned; tasks with slack stay where they were instead of
jumping around. The plan changes as little as the new facts require.

**Nothing is written until somebody agrees.** The result arrives as a preview next to the current
plan. Apply it, or leave it. If the data changed while you were looking, it will not apply a stale
plan; if you applied and regret it, one step undoes the whole run.

**If there is no feasible plan, it says why.** Instead of a schedule that quietly breaks a rule, you
get the rules that could not be met: which resource, which day, by how much.

**Shifts come from the same engine.** Coverage requirements, skills and unavailability go in; a
roster that covers demand with the right people comes out, to be checked, adjusted by hand and
published.

## Where to go next

- [What you can do](https://aipril.dev/docs/scheduling/what-you-can-do.md) - project recalculation, preview and undo,
  critical path and resource load, and shift rosters from requirement to timesheet.
- [Under the hood](https://aipril.dev/docs/scheduling/under-the-hood.md) - the constraint solver, why the plan is never
  written back on its own, and how the service is kept away from your data.

The first application built on it is [Projects](https://aipril.dev/docs/solutions/projects.md).