This guide shows how to find the tasks that decide the project's finish date and how much room every other task has. You can get these numbers from a scheduling run or from dates you already have, without scheduling.
Analytics are off by default. Ask for them with an AnalyticsOptions value, which has two flags: critical_path and slack. The same value goes into three places:
SolveOptions.analytics, for schedule and Project::solve. The analytics describe the freshly scheduled dates.
PreviewOptions.analytics, for Project::preview. The analytics describe the previewed dates.
AnalyzeOptions.analytics, for Project::analyze. The analytics describe dates you supply, or the project's current dates, as they are. Nothing gets scheduled.
When you set at least one flag, ScheduleResult.analytics holds an Analytics value. With both flags off, the field is None.
The engine computes the numbers from two plans. The first plan is the dates being analyzed. For the second, the engine schedules the same tasks backward from the latest finish, which gives each task its latest possible start. The gap between the two is the slack:
Total slack is how far a task can slip before the project's finish date moves. It's the latest start minus the planned start.
Free slack is how far a task can slip before it pushes any successor. It's the smallest margin over the task's outgoing links, never more than the total slack. A task with no successors has free slack equal to its total slack.
A task is critical when its total slack is zero or less. A link is critical when both of its tasks are critical and the link is binding, so its target starts exactly when the link allows. Critical lists the critical task and link ids, and slack holds one TaskSlack per task.
A few rules shape the output:
Slack is in the configured duration_unit (days by default) and counts working time on each task's calendar. A weekend between two tasks doesn't add slack.
Only leaf tasks and milestones get a slack entry. A summary has no slack, and it's critical when any of its non-summary descendants is.
With use_progress, completed tasks (progress == 1) report zero total and free slack, but they're never critical.
A dependency cycle makes the numbers meaningless. status is then AnalyticsStatus::Invalid, and both lists are None.
Both build and docs wait for design. build takes three days and docs takes one, so design and build form the critical path, joined by link l1. docs reports total 2 free 2: it can slip two working days before the project end moves.
Project::solve takes the same SolveOptions. The flags are part of the solve cache key, so solve(None, ..) with analytics turned on recomputes from the accepted dates instead of returning a cached result without them.
Set the flags in PreviewOptions to see how an edit would change the critical path.
useplen_core::{
AnalyticsOptions, DateTime, LinkData, LinkType, Patch, PreviewOptions, Project, ProjectData,
SchedulingChanges, SolveOptions, TaskData, TaskUpdate,};fntask(id:&str, start: DateTime, duration:f64)-> TaskData{letmut task =TaskData::new(id);
task.start_date =Some(start);
task.duration =Some(duration);
task
}fnfs(id:&str, source:&str, target:&str)-> LinkData{
LinkData {
id: id.into(),
source: source.into(),
target: target.into(),
link_type:LinkType::Fs,
lag:0.0,
lag_unit:None,}}fnmain()->Result<(), Box<dyn std::error::Error>>{let monday =DateTime::from_ymd_hm(2026,8,10,8,0).ok_or("invalid date")?;let data = ProjectData {
tasks:vec![task("design", monday,2.0),task("build", monday,3.0),task("docs", monday,1.0),],
links:vec![fs("l1","design","build"),fs("l2","design","docs")],..Default::default()};letmut project =Project::default();
project.solve(Some(data),&SolveOptions::default())?;// What if the docs take five days instead of one?
letmut longer =TaskUpdate::new("docs");
longer.duration =Patch::Value(5.0);letmut changes =SchedulingChanges::default();
changes.tasks.update.push(longer);let options = PreviewOptions {
analytics: AnalyticsOptions {
critical_path:true,
slack:true,},..Default::default()};let result = project.preview(&changes,&options)?;let analytics = result.analytics.ok_or("analytics not requested")?;ifletSome(critical)=&analytics.critical_path {let ids:Vec<String>= critical.tasks.iter().map(|id|id.to_string()).collect();println!("critical: {}", ids.join(", "));}for s in analytics.slack.iter().flatten(){println!("{}: total {} free {}", s.task, s.total, s.free);}Ok(())}
With five days of docs, the critical path moves to design, docs, and build now has two days of slack. The project itself doesn't change. For more on previewing, see Previewing changes.
Use Project::analyze when you already have dates, for example from your own database or a gantt chart, and want the critical path for those exact dates.
useplen_core::{
AnalyticsOptions, AnalyzeOptions, DateTime, LinkData, LinkType, Project, ProjectData, TaskData,};fntask(id:&str, start: DateTime, duration:f64)-> TaskData{letmut task =TaskData::new(id);
task.start_date =Some(start);
task.duration =Some(duration);
task
}fnmain()->Result<(), Box<dyn std::error::Error>>{let monday =DateTime::from_ymd_hm(2026,8,10,8,0).ok_or("invalid date")?;let thursday =DateTime::from_ymd_hm(2026,8,13,8,0).ok_or("invalid date")?;// "build" starts a day after "design" ends. A solve would pull it back to Wednesday.
let data = ProjectData {
tasks:vec![task("design", monday,2.0),task("build", thursday,3.0)],
links:vec![LinkData {
id:"l1".into(),
source:"design".into(),
target:"build".into(),
link_type:LinkType::Fs,
lag:0.0,
lag_unit:None,}],..Default::default()};let project =Project::default();let options = AnalyzeOptions {
analytics: AnalyticsOptions {
critical_path:true,
slack:true,},};let result = project.analyze(Some(&data),&options)?;assert!(result.updates.is_empty());let analytics = result.analytics.ok_or("analytics not requested")?;ifletSome(critical)=&analytics.critical_path {for id in&critical.tasks {println!("critical task: {id}");}}for s in analytics.slack.iter().flatten(){println!("{}: total {} free {}", s.task, s.total, s.free);}Ok(())}
Only build is critical. design has one day of total and free slack, because build starts a day later than the link requires. Link l1 isn't critical: it isn't binding, and design isn't critical.
analyze takes &self and never changes the project. With Some(&data) it validates and reads the data but doesn't install it. Invalid data fails with Error::Input, as in Error handling. The result has no updates and no planner conflicts, and its baseline_id is None.
After the edit, the critical path is design, docs. analyze doesn't change the project's solved status, so the project still needs solve(None, ..) before preview works again. The baseline_id is set only when the project is solved and has no unsolved edits. That's how you tell whether the analytics describe the accepted baseline.
The output shows each rule from the concept section:
critical: review, phase, release
spec: total 0 free 0
review: total 0 free 0
release: total 0 free 0
phase is critical because its child review is. It has no slack entry, since summaries never get one.
spec is complete, so it reports zero slack. It still isn't on the critical path.
The critical task list follows the scheduling graph order, not input order. Look tasks up by id instead of relying on their position.
If the links form a cycle, the solve returns unchanged dates and lists each cycle in result.cycles. The analytics then come back as Invalid with no lists. Fix the cycle and run again. For the rest of the result, see Reading results.