Logic & Relationship Checks
Category weight: 20% of overall score
Checks in this category: 8
Logic checks verify that your schedule has a sound network of relationships. A schedule with missing logic, excessive lags, or unnecessary constraints cannot produce reliable critical path calculations.
Missing Logic
| Field | Value |
|---|---|
| Check ID | missing-logic |
| DCMA Reference | Point 1 |
| Default Threshold | ≥ 95% of activities must have both a predecessor and a successor |
| Severity | Major |
Detects activities with open starts (no predecessors) or open finishes (no successors). Every activity in a schedule should be logically connected — an activity without predecessors can start at day one regardless of context, and an activity without successors cannot drive the finish date.
What triggers a finding: An activity that has no predecessor relationships, no successor relationships, or both.
Exceptions: The first milestone (project start) may legitimately have no predecessors, and the last milestone (project finish) may have no successors. These are typically handled by the threshold — a small number of open-ended activities is acceptable.
Negative Float
| Field | Value |
|---|---|
| Check ID | negative-float |
| DCMA Reference | Point 8 |
| Default Threshold | Any negative float is flagged |
| Severity | Critical |
Detects activities where total float is negative, indicating the schedule is behind — these activities cannot finish by their required dates given current logic and constraints.
What triggers a finding: Total Float < 0 on any activity.
Why it matters: Negative float means the project completion date is at risk. The magnitude of the negative float tells you how many days behind the schedule currently is.
High Float
| Field | Value |
|---|---|
| Check ID | high-float |
| DCMA Reference | Point 11 |
| Default Threshold | Total float > 44 working days; ≤ 5% of activities may exceed |
| Severity | Minor |
Detects activities with unusually high total float, which may indicate missing logic, broken relationships, or activities that have been disconnected from the main schedule network.
What triggers a finding: Total Float exceeds the configured day threshold (default 44 working days).
Why it matters: High float suggests the activity is not properly constrained by the schedule logic. It may be able to slip weeks or months without affecting the project — which often means it should have more relationships tying it in.
Leads Check
| Field | Value |
|---|---|
| Check ID | leads |
| DCMA Reference | Point 3 |
| Default Threshold | ≤ 5% of relationships may have leads (negative lag) |
| Severity | Major |
Detects relationships with negative lag (leads). A lead on a relationship means the successor starts before the predecessor logic would normally allow, which can mask scheduling problems and create unrealistic overlaps.
What triggers a finding: A relationship where the lag value is negative.
Best practice: Replace leads with SS or FF relationships that model the actual work overlap.
Lags Check
| Field | Value |
|---|---|
| Check ID | lags |
| DCMA Reference | Point 3 |
| Default Threshold | ≤ 5% of relationships may have lags |
| Severity | Minor |
Detects relationships with positive lag values. While lags are sometimes necessary, excessive use can hide activities that should be explicitly modelled (e.g., a curing period should be its own activity, not a lag on a relationship).
What triggers a finding: A relationship where the lag value is greater than zero.
Best practice: Convert significant lags into explicit activities so they appear on the schedule, can be resourced, and are visible during reporting.
Negative Lag Check
| Field | Value |
|---|---|
| Check ID | negative-lag |
| DCMA Reference | — |
| Default Threshold | Any negative lag is flagged |
| Severity | Major |
A strict companion to the Leads check — flags every relationship with negative lag regardless of percentage thresholds. Use this when your organization has a zero-tolerance policy for leads.
FS Relationships
| Field | Value |
|---|---|
| Check ID | fs-relationships |
| DCMA Reference | Point 3 |
| Default Threshold | ≥ 90% of relationships should be Finish-to-Start |
| Severity | Minor |
Verifies that the majority of relationships use the Finish-to-Start (FS) type, which is the most straightforward and auditable relationship type. Excessive use of SS, FF, or SF relationships can make the schedule harder to understand and validate.
What triggers a finding: The percentage of FS relationships falls below the threshold.
Hard Constraints
| Field | Value |
|---|---|
| Check ID | hard-constraints |
| DCMA Reference | Point 6 |
| Default Threshold | ≤ 2% of activities may have hard constraints |
| Severity | Major |
Detects activities with hard constraints (Mandatory Start, Mandatory Finish, Must Start On) that override CPM logic. Hard constraints prevent the scheduling engine from calculating dates based on relationships and calendars, which can hide true schedule risks.
What triggers a finding: An activity with a constraint type of CS_MANDSTART, CS_MANDFIN, or CS_MSO.
Best practice: Use soft constraints (Start Not Earlier Than, Finish Not Later Than) instead, which provide date guidance without overriding CPM logic.
Next Steps
- Duration Checks — Validate activity durations
- Quality Overview — Return to the quality overview
- Quality Settings — Adjust thresholds for these checks