Section 1 is the decision and the arithmetic behind it — the rule applied, the values measured, and which term of the rule the submission failed. Section 2 states the conditions of acceptance: the three failures that must be corrected in R13. Section 3 records the watch-items that do not block acceptance but will if they persist.
Appendix A is the full 18-check gate register — every check, its measured value, the target applied and the result, so the contractor can reproduce the decision rather than take it on trust. Appendix B records the acceptance rule as configured, and the provenance of the file assessed.
Programme R12 is accepted with comments. It is broadly sound and fit to be worked to, but it carries three failed checks that must be corrected at the next revision.
The submission passes the score term of the acceptance rule comfortably — 73 against a required 65 — and passes the warning term exactly. It fails on one term only: three failed checks against a permitted one. That single failure is what separates this decision from a clean acceptance, and section 2 states what has to change.
| Term of the acceptance rule | Required | Measured | Result |
|---|---|---|---|
| Schedule Quality Score | ≥ 65 | 73 | PASS |
| Failed checks | ≤ 1 | 3 | FAIL |
| Warnings | ≤ 4 | 4 | PASS |
Two of the three failures — 17 activities carrying negative float and 6 leads — mean the programme cannot be read at face value: negative float says the arithmetic already does not close, and leads let successors start before their predecessors finish. Accepting without conditions would put the owner's name to dates that the network itself does not support. The comments are the mechanism for accepting the programme as a working document while keeping that reservation on the record.
Three checks failed. Each is a condition of this acceptance and is to be corrected in R13.
What it means. Seventeen activities carry total float below zero, which is the network reporting that it cannot achieve a date it has been told to achieve. Negative float is not a delay in itself; it is the symptom of a constraint or a logic path that contradicts the rest of the programme.
What to do. Trace each of the seventeen to its driver — in this programme they resolve to the hard constraints at check 14 — and either relax the constraint, re-sequence the path, or accept the date change and reforecast. Do not suppress the symptom by extending durations elsewhere.
What it means. Six logic links carry a negative lag, allowing a successor to begin before its predecessor finishes. A lead is a shortcut around logic that has not been modelled: the real overlap may be legitimate, but the programme does not show what it is.
What to do. Replace each lead with the relationship it stands for — usually a start-to-start link with a positive lag, or a split of the predecessor into the portion that actually has to finish first. Six links is a contained correction and should not survive into R13.
What it means. Mandatory-start and mandatory-finish constraints override logic: a constrained activity holds its date whatever its predecessors do, which is what produces the negative float at condition 1. At 3.1% the programme is materially constraint-driven rather than logic-driven.
What to do. Reduce to below 2% by removing constraints that duplicate contractual dates already modelled as milestones, and retaining only those the contract genuinely imposes. Where a hard constraint must stay, record why in the schedule basis so the next reviewer does not re-open it.
Conditions 1 and 3 are cause and effect: the hard constraints produce the negative float. Correcting the constraints should clear the majority of the seventeen negative-float activities without any other change. Condition 2 is independent and is the smaller job. A single focused revision should close all three.
Four checks returned warnings. Under the configured rule they do not prevent acceptance — the submission is at the limit of four, not over it — but a fifth warning at R13 would.
Target <5%. Sitting exactly on the threshold — no headroom at R13.
Target zero. Work progressing against the logic as modelled.
Target ≥1.0. The critical path is shorter than the time available to it.
Both target ≥1.0. Execution and progress agree: no recovery yet.
Missing logic sits exactly on the threshold at 5.0%. This is the warning most likely to become a failure: a single revision that adds activities without adding their logic will cross it. It is recorded here so that the contractor knows there is no headroom, not because the current figure is objectionable.
Eleven out-of-sequence activities indicate work progressing against the logic as modelled. Each one is either a real change in method — in which case the logic should follow it — or a progress-reporting error. Both are corrections; neither is a delay.
CPLI 0.94, BEI 0.91, SPI 0.93. All three performance indices sit below unity and agree with one another, which is the more reliable signal: the programme is not currently recovering, and the critical path has less length available than it needs. These are the indices to watch across R13 and R14 rather than to act on in a single revision.
Clearing the three conditions moves the submission to a clean ACCEPT provided the warning count does not rise above four. Leaving any one condition unresolved holds it at ACCEPT WITH COMMENTS at best; a fall in score below 65, or a fourth failure, would put it into REJECT. The rule is applied identically at every revision, so the contractor can predict the outcome before submitting.
The acceptance gate applies the organisation's configured acceptance rule to the 18-point schedule-quality assessment — the DCMA 14-point checks plus four supplementary indices — and returns one of three outcomes. ACCEPT where every term of the rule is met. ACCEPT WITH COMMENTS where the score is within ten points of the minimum and the failures are within two of the permitted number. REJECT otherwise. The bands are fixed; the thresholds are not.
The minimum score, the maximum failed checks and the maximum warnings are set per organisation, because an acceptance standard is a commercial position rather than a technical constant. A framework owner running many small works packages and a single-project client on a complex build should not be held to the same number, and a generic threshold applied to both would be arbitrary in one of the two cases. The rule applied to this submission is recorded in full at Appendix B so that the decision can be audited against the standard in force on the day it was made.
The value of a gate is that it is the same gate every time. Because the rule is stated numerically and evaluated mechanically, the same programme submitted twice returns the same verdict, and two contractors submitting comparable programmes are held to one standard. Where the reviewer disagrees with an outcome, the disagreement is with the rule — which can be changed deliberately and for the future — rather than with an individual judgement made once and unrecorded.
This scorecard measures the structural quality of the programme as a network. It does not read the Works Information, does not verify that the scope is complete, does not confirm that durations are achievable, and does not check that the sequence is buildable. A programme can pass every check and still be wrong about the project. The verdict is an aid to the acceptance decision under the contract; the reviewing party remains responsible for accepting, conditionally accepting or rejecting the submission, and for the consequences of that decision.
Assessment performed on-device against Programme R12 as submitted. No file was uploaded and no copy is retained — see Appendix B for the file provenance recorded at the time of assessment.
Every check with its measured value, the target applied and the result. Checks 1–14 are the DCMA 14-point assessment; 15–18 are the supplementary indices. The three checks marked FAIL are the conditions of acceptance at section 2.
| # | Check | Value | Target | Result |
|---|---|---|---|---|
| 1 | Missing logic (open ends) | 5.0% | <5% | WARN |
| 2 | Logic density | 2.5 | 2.0–3.5 | PASS |
| 3 | Finish-to-start relationships | 86% | >80% | PASS |
| 4 | Lags | 3.1% | <5% | PASS |
| 5 | Leads (negative lags) | 6 | Zero | FAIL |
| 6 | Out of sequence | 11 | Zero | WARN |
| 7 | Negative float | 17 | Zero | FAIL |
| 8 | Near-critical (float ≤ 10d) | 8.2% | <10% | PASS |
| 9 | High float (> 44d) | 9.4% | <10% | PASS |
| 10 | Critical path percentage | 12% | <15% | PASS |
| 11 | CPLI | 0.94 | ≥1.0 | WARN |
| 12 | High duration (> 44d) | 4.2% | <5% | PASS |
| 13 | Insufficient detail | 3.8% | <5% | PASS |
| 14 | Hard constraints | 3.1% | <2% | FAIL |
| 15 | Soft constraints | 4.4% | <5% | PASS |
| 16 | Milestone coverage | 2.6% | >2% | PASS |
| 17 | BEI (baseline execution index) | 0.91 | ≥1.0 | WARN |
| 18 | SPI (schedule performance index) | 0.93 | ≥1.0 | WARN |
| Weighted Schedule Quality Score | 73 | ≥ 65 | PASS |
The score is a weighted composite, not the proportion of checks passed — which is why 11 passes out of 18 returns 73 rather than 61. The weighting is published on the methodology page and is identical for every schedule assessed.
The acceptance rule as configured at the time of assessment, and the provenance of the file assessed. Both are recorded so the decision can be reproduced later against the standard actually in force, rather than against whatever the standard has since become.
| Parameter | Value | Effect on the verdict |
|---|---|---|
| Minimum Schedule Quality Score | 65 | Below 65 the submission cannot be accepted; below 55 it is rejected outright. |
| Maximum failed checks | 1 | More than 1 blocks clean acceptance; more than 3 forces rejection. |
| Maximum warnings | 4 | More than 4 blocks clean acceptance. |
| Comments band | −10 / +2 | Fixed. Score within 10 of the minimum and failures within 2 of the maximum returns ACCEPT WITH COMMENTS. |
Thresholds are set on the Criteria tab and apply to every submission assessed by the organisation until changed. This submission was measured at 73 · 3 fails · 4 warnings, meeting the first and third terms and failing the second.
| Item | Recorded value |
|---|---|
| Submitted file | TowerC_R12.xer |
| Format | Primavera P6 XER |
| Data date | 28 February 2026 |
| Activities assessed | 3,842 |
| Logic links assessed | 9,610 |
| Baseline attached | R10 — approved 30 November 2025 |
| Assessment date | 28 February 2026 |
| Assessed by | Meridian Estates — Owner's PMO |
| Processing | On-device — file not uploaded, not retained |
Activity and link counts are those read from the submitted file, not from any prior revision. Where a count differs from the contractor's own figure the difference is usually filtered or excluded activities; the assessment reads every activity present in the file.
Every report in the set is built from a Primavera P6 or Microsoft Project file, parsed in your browser. Nothing is uploaded and nothing is retained.