Logic Density and Quality
Last reviewed 9 September 20261,683 words8 min read
How much logic is enough
🟩 In one line: A clean Level 3 construction schedule runs at roughly 1.8–2.5 relationships per activity, with 90%+ of links Finish-to-Start, under 5% lags, and zero open ends — but the number is a symptom, not the target. Density tells you whether the network was built or drawn; only reading the driving path tells you whether it's right.
👤 Who this is for: Mid-level planners being told their logic is "too thin" or "too dense"; juniors wanting a number to aim at; reviewers writing a comment they can defend. You should know relationship-types-explained, open-ends, dangling-activities, redundant-relationships.
First, let's be honest about why this page exists
Two failure modes, opposite directions. A tender programme with 400 activities and 380 relationships — half the network is bars sitting on dates with one link each, and the critical path is whatever the constraints say. And the over-corrected version: 4,000 activities with 12,000 relationships, everything linked to everything, and nobody can answer "what's driving this date?"
Reviewers use density because it's countable in thirty seconds. You should know your numbers before they do, and you should be able to explain why yours are what they are.
🟨 The standard — what "good" looks like
| Source | What it says (paraphrased) |
|---|---|
| DCMA 14-Point, Metric 1 (Logic) | ≤5% of incomplete activities missing a predecessor or successor |
| DCMA 14-Point, Metric 2 (Leads) | Zero negative lags |
| DCMA 14-Point, Metric 3 (Lags) | ≤5% of relationships have lags |
| DCMA 14-Point, Metric 4 (Relationship Types) | ≥90% of relationships should be FS |
| GAO Schedule Assessment Guide, Best Practice 2 (Sequencing) | All activities logically sequenced; no unjustified constraints or dangling logic |
| PMI Practice Standard for Scheduling, 3rd ed. | Every activity except start and finish has at least one predecessor and one successor; logic reflects real dependencies |
| AACE RP 49R-06 | Network must produce a continuous, traceable longest path from data date to completion |
| Typical Gulf client specifications | Frequently: max 4–6 relationships per activity; no SF; no negative lag; 100% logic (stricter than DCMA's 5%) |
Working benchmarks (not from any standard — field norms, use as a sense check):
| Measure | Healthy range | Read it as |
|---|---|---|
| Relationships ÷ activities | 1.8 – 2.5 | Below 1.5: network is thin or full of dangles. Above 3.0: redundancy likely |
| % FS | 88 – 98% | Below 85%: SS/FF chains — check for dangles |
| % with lag | 0 – 5% | Above 10%: lags doing the job of activities |
| % negative lag | 0% | Any is a comment |
| Open ends | 2 (start + finish milestone) | Anything else is a fix |
| Max relationships on one activity | ≤ 8 | Except integration milestones, which need justification |
| Constraints | ≤ 5% of activities, SOoA and FOoB only | Everything else stripped |
| Activities on longest path | 5–15% of total | Below 3%: constraints are driving, not logic |
🟢 Rule to remember: 2 relationships per activity, 90% FS, 5% lags, 0 open ends. Hit those and the argument moves from your logic to your durations — which is where it should be.
How it actually works
Getting the numbers out of P6.
| Number | Where |
|---|---|
| Activity count | Status bar, or group by nothing and read the total |
| Relationship count | Tools > Schedule > View Log doesn't give it; export TASKPRED and count rows, or use the Relationships tab in a report, or a checker tool |
| Open ends | Schedule Log after F9 lists activities without predecessors/successors |
| % FS | Export TASKPRED, count pred_type = PR_FS ÷ total |
| Lags | Export TASKPRED, count rows where lag_hr_cnt ≠ 0 |
| Constraints | Activities view, add Primary Constraint column, filter not blank |
| Longest path | Schedule Options > tick Calculate multiple float paths or filter Longest Path = Yes |
Practical route: export the XER, open TASKPRED in a parser or Excel copy, and you have all of it in five minutes (xer-in-excel).
Density by schedule level. The benchmark changes with the level, and reviewers who apply Level 3 numbers to a Level 2 rollup are wrong.
| Level | Typical activity count | Relationships/activity | Notes |
|---|---|---|---|
| L1 | 15–40 | n/a — usually a P6 layout rollup | No logic of its own |
| L2 | 100–300 | 1.5–2.0 | Summary logic; more SS/FF legitimately |
| L3 (contract baseline) | 1,000–6,000 | 1.8–2.5 | The number that matters |
| L4 (site working) | 5,000–20,000 | 1.8–2.5 | Same discipline, more detail |
| L5 (short interval) | Varies | Often none — pull-planned | Last Planner territory |
Density by sector. Not all networks are the same shape.
| Sector | Typical ratio | Why |
|---|---|---|
| High-rise building | 2.0–2.4 | Repetitive floor chains, clean FS |
| Infrastructure / linear | 1.7–2.1 | Long chains, few merges |
| Oil & gas EPC | 2.2–2.8 | Heavy E-P-C interfaces, more merge points |
| Shutdown / turnaround | 2.5–3.5 | Dense, short-duration, many parallel constraints |
| Fit-out | 2.2–3.0 | Many trades in the same space |
| Data centre / MEP-heavy | 2.3–3.0 | Systems-based commissioning logic |
What density doesn't tell you. A network can hit every benchmark and still be wrong: soft logic tagged as hard, durations unjustified, out-of-sequence progress unaddressed, a critical path that runs through a summary bar nobody builds. Density is a hygiene check. Read the longest path and ask a site engineer whether it's the job (schedule-quality-vs-schedule-realism).
🟥 Where people go wrong
- Adding links to hit a ratio. Reviewer says 1.4; planner adds 600 links to reach 2.1, half of them to the completion milestone. The ratio passes; the network is worse. Fix the dangles and open ends and the ratio moves on its own.
- Applying DCMA thresholds to a Level 2. A 180-activity summary programme will have SS/FF overlaps and won't hit 90% FS. Say which level you're reviewing before you quote a metric.
- Counting relationships including completed activities. DCMA metrics apply to remaining/incomplete work. A file with 60% complete and 4% open ends among the remaining is fine even if the raw count looks worse.
- Chasing 100% FS. Genuine overlaps exist. Blockwork and MEP first fix on the same floor overlap by design. Use SS+FF pairs and explain; don't fake it with FS and a negative lag.
- Ignoring the max-relationships-per-activity outlier. One activity with 90 successors is usually a milestone doing the job of a WBS, or redundancy. Sort descending on successor count before every submission.
- Treating a clean scorecard as acceptance. Clients increasingly run Fuse-type checks and accept on the score. Don't rely on it — the first update where the critical path is obviously wrong undoes it.
⚖️ When you're challenged
"Your logic density is 1.6 — too thin." "That's the raw ratio across all 4,100 activities including 900 completed. Among incomplete activities it's 2.1. The 1.6 comes from completed work where we don't add logic retrospectively. Here's the breakdown."
"Only 78% of your relationships are FS. DCMA wants 90%." "Agreed, and 12% of that gap is the finishes floor cycle where trades genuinely overlap — SS with matching FF pairs, so no dangles. The remaining 10% is legacy from the tender file and is corrected in Rev 1."
"Every activity should have four relationships minimum." "That's not a standard anywhere and it produces redundancy. The requirement is that every activity has something driving its start and something driven by its finish. Ours do — zero open ends, zero dangles, comparison report attached."
"Your checker score is 92%. Good enough." "The score is fine. The thing I'd rather you looked at is the longest path — it runs through façade procurement, not structure, and that's the conversation for this month."
📄 Related pages
- Open ends — the first thing to fix
- Dangling Activities — the count density won't show
- Redundant Relationships — the other direction
- DCMA 14-point assessment — the metrics quoted here
- Leads and lags — the 5% and the zero
- Critical path vs longest path — why path length matters
- Schedule quality vs schedule realism — the limits of all of this
- How to review a schedule — density as step one of ten
✏️ Worked example
A mixed-use development in Dubai, Level 3 baseline, before and after a two-week logic clean-up:
| Measure | Rev 0 | Rev 1 | Target |
|---|---|---|---|
| Activities | 3,840 | 3,840 | — |
| Relationships | 5,120 | 8,260 | — |
| Ratio | 1.33 | 2.15 | 1.8–2.5 |
| Open ends (incomplete) | 214 | 2 | 2 |
| Dangling finishes | 380 | 0 | 0 |
| % FS | 71% | 91% | ≥90% |
| % with lag | 14% | 4% | ≤5% |
| Negative lags | 62 | 0 | 0 |
| Constraints | 340 (9%) | 61 (1.6%) | ≤5% |
| Activities on longest path | 62 (1.6%) | 310 (8.1%) | 5–15% |
| Forecast completion | 12-Mar-27 | 04-Apr-27 | — |
The last two rows are the point. Before the clean-up, only 62 activities were on the longest path because constraints — not logic — were holding the dates. After, the path is 310 activities long and continuous from data date to completion, and the honest completion date is 23 days later. That 23 days was always there; the network was hiding it.
📖 References
- DCMA 14-Point Assessment, Metrics 1–4
- GAO, Schedule Assessment Guide (GAO-16-89G), Best Practice 2
- PMI, Practice Standard for Scheduling, 3rd ed.
- AACE RP 49R-06, Identifying the Critical Path
- Oracle, P6 Professional User Guide — Scheduling; Schedule Log
From the field
Experience from working planners. Unreviewed — read it as experience, not guidance.
Add what you know about logic density and quality. What worked, what the consultant pushed back on, what you would do differently next time. A paragraph is plenty.
Contributors get their name and one link on the site — your own templates, course or consultancy. We take nothing and hold nothing.
Add your experience