P6 offers two different definitions of "critical," controlled by the project setting PROJECT.critical_path_type. In a simple single-calendar network with no constraints they often produce the same result. They don't always — and when they don't, it matters for delay analysis and claims.
The P6 setting
PROJECT.critical_path_type controls which definition P6 uses when it colours activities as critical in a layout or report. It's a project-level setting, so two schedules — or two updates of the same schedule opened with different settings — can show a different critical path even with identical logic and dates underneath.
CT_TotFloat: float ≤ threshold
Under this method, any activity whose total float is at or below the defined threshold (usually zero, sometimes a small positive number) is marked critical, whether or not it drives the project finish. Above, C's Finish On or Before constraint cannot be met, so B and C carry −1 day of float and are marked critical even though the finish date is driven by A.
CT_DrivPath: the driving path flag
P6 also identifies driving relationships — the ones that actually determine a successor's early dates. With Longest Path selected, P6 traces driving relationships back from the project's finish and marks the activities on that chain as critical. Longest path does not use float values, so negative float created by a constraint elsewhere does not, on its own, put an activity on it. If two chains tie exactly, both relationships can be driving, so the longest path is not always a single chain.
When they agree, and when they don't
On a single-calendar network with no constraints and a zero float threshold, the two methods often produce the same picture. They can diverge when constraints or a project must-finish-by date create negative float away from the driving path, when activities use different calendars (float is measured in each activity's own working time), when the float threshold is set above zero, or when open ends distort late dates.
What DCMA checks
The DCMA 14-point assessment does not refer to either P6 setting. Its Critical Path Test asks whether a delay introduced on the critical path moves the project finish by the same amount, and its Critical Path Length Index compares the remaining critical path length plus float against that length. Whichever definition a schedule uses, state it when reporting results against these checks.
In a delay analysis or an EOT claim, arguing from "the critical path" without specifying which of these two definitions you mean invites the parties to talk past each other — state the method up front, and check which one the contract or the other party's schedule actually assumes.
See this in your file → validate.html