ScheduleInsight Example report ← All examples Pricing Analyse your schedule free
Report setting — the contract layer, verdict language and section 07 change with it. Default NEC4.
ScheduleInsight · Programme Assurance Review

Tower C — Commercial Tower & Podium

Programme revision R12 · monthly submission review
NEC4 ECC Option A — acceptance under clause 31

DO NOT ACCEPT
RESUBMISSION REQUIRED · CL.31.3 (b) AND (c)
58/ 100
Submitted by
Calderwood Construction Ltd
Assessed for
Meridian Estates — Project Manager
Data date
28 February 2026
Compared with
R11 — data date 31 Jan 2026
Baseline
R8 — accepted 12 Sep 2025
Activities
3,842 (2,914 incomplete)
Assessment
4 layers · 41 checks
Reply due (cl.31.3)
14 March 2026
Report reference
SI-2026-02-TOWERC-R12-0447
ScheduleInsight
Parsed on-device · file never uploaded
Tower C · Programme R12 · Assurance Review28 Feb 2026

Contents

Report
1Executive position and acceptance decision3
2Score and gate outcome4
3Movement since R115
4Technical health6
5Execution readiness7
6Completeness of the programme9
7Contract test — NEC4 clause 31.310
8Forecast credibility11
9Conclusion and required actions12
10Method, basis and limitations13
Appendices — supporting detail
ATechnical health register — 18 checks14
BScore components and gate rule register15
CExecution interface matrix16
DCompleteness register17
ERevision comparison — undeclared changes18
FCorrective action register19
GEvidence and provenance20
HReconciliation and responsibilities21
How to read this report

Sections 1 to 10 carry the analysis and the reasoning. Every number in them is supported by a register in the appendices, named at the point it is used, so a finding can be traced to the activities that produced it without leaving the document.

Section 1 is written for the signer and is sufficient on its own to make the acceptance decision. Sections 2 to 8 are for the project controls reviewer. The appendices are the working detail for the planner correcting the programme.

ScheduleInsight · Programme Assurance Review2
1 · Executive positionTower C · R12

01 Executive position and acceptance decision

DO NOT
ACCEPT
RESUBMISSION
REQUIRED

R12 should not be accepted. Two of the four reasons for non-acceptance in clause 31.3 are made out on the face of the programme, and the Project Manager should notify them by 14 March.

The finding that changes the decision is not a schedule metric. Planned Completion has moved 49 days later than R11. Twelve of those days are covered by notified compensation events. The remaining 37 days appear in R12 with no notification, no compensation event reference and no explanation in the accompanying narrative. Twenty-three activities carry planned dates different from R11 with no corresponding change record, fourteen of them on the driving path.

Accepting R12 as submitted would move the Accepted Programme 49 days to the right, of which 37 days have never been justified. That is not a drafting error to be picked up next month; it is the point at which the Accepted Programme stops being a reliable reference for assessing compensation events.

Decision required from
Project Manager
Notify by
14 March 2026
Reasons to cite
cl.31.3 (b) and (c)
Resubmission window
7 days
Must-fix items
6 — two carried from R11
Composite score
58 / 100 — gate is 65

The four things to raise in the reply

ScheduleInsight · Programme Assurance Review3
2 · Score and gate outcomeTower C · R12

02 Score and gate outcome

The composite is the weighted sum of four layers and nothing else. There is no base allowance — a programme with no merit scores zero rather than starting part-way up the scale — and no rounding in the submitter's favour. Weights and thresholds are configurable per organisation and are recorded with the assessment, so any score can be reproduced from the source file and the versions in Appendix G.

Gate rules

Named rules decide the verdict independently of the number, so a single inflated layer cannot carry a programme through. Four of the six rules were triggered. Rules that did not fire are recorded alongside those that did, in Appendix B, so the gate can be audited in both directions.

Triggered

GR-01 composite 58 against a minimum of 65 · GR-02 17 activities in negative float where the tolerance is zero · GR-03 six leads against a zero-tolerance check · GR-05 Planned Completion moved 37 days beyond the notified change.

Not triggered: GR-04 contract-mandatory content absent — three items are absent, but none is individually gate-blocking at this stage · GR-06 open ends 5.0% against a 10% tolerance.

ScheduleInsight · Programme Assurance Review4
3 · Movement since R1131 Jan → 28 Feb 2026

03 Movement since R11

A submission review that cannot compare revisions is a health check with a different name. R12 is assessed against R11 activity by activity, and against the accepted R8 baseline, so the question is not only whether this programme is sound but what was changed to make it look that way.

Planned Completion
+49 days

14 Aug 2027 → 02 Oct 2027. Notified compensation events account for 12 days (CE-041, CE-044). 37 days are undeclared.

Dates changed with no record
23

23 activities carry planned dates differing from R11 with no compensation event, early warning or narrative entry. 14 are on the driving path. Listed in Appendix E.

Network churn
+214 / −38

214 activities added, 38 removed, 96 re-logicked — 9% of the network in one cycle. High for a monthly update and unexplained in the narrative.

Performance
0.93

SPI(t) 0.93, BEI 0.91, CPLI 0.94. All three below 1.0 for a third consecutive revision.

Figure 2 — Composite score by revision
Two revisions of improvement, then a reversal. R12 is the first submission since R9 to score below its predecessor and the first to fall back under the gate. Schedule quality typically decays two to three revisions before a completion date moves; here the quality drop and the date movement have arrived in the same cycle, which suggests the date was held artificially in R10 and R11 rather than genuinely recovered.
ScheduleInsight · Programme Assurance Review5
4 · Technical healthL1 · 73 / 100 · 40% weight

04 Technical health

The DCMA 14-point checks plus four supplementary indices, at the thresholds configured for this contract. Severity is weighted by the number of activities affected and by whether the check is zero-tolerance, so the layer score is not a pass-count conversion. The full register, with each measured value, threshold and movement since R11, is Appendix A.

10 PASS
5 WATCH
3 FAIL
within tolerance at or approaching threshold breached

The direction of travel is the finding

Taken as a snapshot, ten of eighteen checks pass and the layer scores 73 — respectable for a live production programme. Taken against R11, the picture is different: fifteen of the eighteen checks moved the wrong way this revision and not one improved. Individually most remain inside tolerance. Collectively that is a network being degraded by update pressure rather than maintained.

Three movements matter more than the rest:

Not assessed

Resource loading is absent from this export, so resource-conflict analysis and duration-realism testing are out of scope for this revision and are reported as N/A rather than estimated. CPLI, BEI and Missed Tasks are calculated here because an approved baseline (R8) is present; where no baseline exists these return N/A rather than a plan-based substitute.

ScheduleInsight · Programme Assurance Review6
5 · Execution readinessL2 · 64 / 100 · 25% weight

05 Execution readiness

Whether the phases actually hand off to one another in the logic. A programme can pass every quality check and still fail to connect construction to commissioning — quality checks test how the network is built, not whether it joins up.

How this is derived — no mapping, no configuration

1 · Every activity is classified into one macro-phase, using a fixed precedence: an activity code whose values match the phase lexicon, then an unambiguous action word in the activity name, then the WBS path, then an object or area word in the name. The name is split across two steps because programmes routinely file “Practical Completion” under the last trade’s WBS branch — the branch says where the bar sits, the verb says what it does. The precedence never varies, so the same file always classifies the same way.

2 · Only interfaces that can exist are expected. The sector is derived from the file — commercial building, process or industrial plant, or infrastructure — and selects the phase sequence. Every sector shares the same front (design, procurement, fabrication, delivery) and the same back (testing, commissioning, handover) and differs only in the middle: a plant runs civils, structural steel, equipment, piping and E&I where a tower runs substructure, superstructure, envelope, MEP and fit-out. Where no sector clearly wins, the middle collapses to four coarse bands rather than assessing a plant against a tower’s phase order. An interface A→B is tested only where both phases are present in the file and A precedes B — the engine never reports a missing handoff to a phase the project does not have.

3 · Required paths are counted from the network, not assumed. For A→B, the required count is the number of boundary points: activities in B with no predecessor inside B, plus activities in A with no successor inside A. A point counts as present when a path crosses the boundary — directly, or through a short run of unclassified milestones and hinge activities belonging to neither phase. An activity that belongs to some other phase is not a hinge, and no path is counted through it.

4 · Confidence is graded by the classification source — activity code High, WBS Medium, name lexicon only Low — and reported per interface. A Low-confidence result is a prompt to improve activity coding, not a finding against the programme.

Nothing in this section requires the user to tag activities, map phases or set anything up. Where the coding is too thin to classify with confidence, the engine says so rather than guessing.

Figure 3 — Interface health across eight phase handoffs
Design → Procurement92
Procurement → Fabrication88
Fabrication → Delivery81
Substructure → Superstructure96
Superstructure → Envelope74
Envelope → Fit-out58
Fit-out → Testing & commissioning25
T&C → Handover0
Health is the proportion of required handoff paths present in the logic. Phases on this file were classified from the activity code “PHASE” for 3,104 activities and from the WBS path for the remaining 738, so seven of the eight interfaces carry High or Medium confidence. Required, present and missing counts, and the classification basis per interface, are in Appendix C. Mean health across the eight interfaces is 64.
ScheduleInsight · Programme Assurance Review7
5 · Execution readinessL2 · 64 / 100 · 25% weight

Well built at the front, disconnected at the back

The first four interfaces are sound: design releases into procurement, procurement into fabrication, fabrication into delivery, and the substructure hands over to the superstructure cleanly. This is a competently built programme through to the frame.

From the envelope onward the handoffs thin out, and beyond fit-out they effectively stop. Thirty-six of the forty-eight required links from fit-out into testing and commissioning are missing, and there is no logic at all between commissioning and handover.

This is why the completion date is unreliable in a way the float figures do not reveal. The last four months of the programme are not a network — they are a list of dates. Slippage in fit-out has no path along which to propagate to the completion milestone, so the date will hold on paper while the work behind it slips, and then fail all at once. It also means the negative float in section 4 understates the problem: float can only be calculated along logic that exists.

ScheduleInsight · Programme Assurance Review8
6 · CompletenessL3 · 45 / 100 · 20% weight

06 Completeness of the programme

Whether the programme contains what a commercial tower under NEC4 must contain. The quality checks in section 4 tell you whether a schedule is well built; this tells you whether it is finished. Presence alone earns no credit — content must be logic-linked into the network to count, because an activity with no predecessor and no successor models nothing.

How the requirement list is chosen

The engine detects the project type from the WBS vocabulary, activity-name lexicon and calendar profile — here commercial building, confidence 96% — and loads the content requirements for that type, plus the requirements the selected contract form adds. The user picks nothing. Where project-type confidence falls below 80% the engine reports the ambiguity and tests only the requirements common to the candidate types.

Figure 4 — Eleven content requirements
Key
Dates
Terminal
float
H&S
holds
Access
dates
Statutory
approvals
Temp
works
Sub
design
Time
risk
Long
lead
T&CHand
over
Three present, four partial, four absent. Full register with the evidence behind each state in Appendix D.

What is missing, and why each matters

Read together with section 5

The absent content and the empty interfaces are the same defect seen from two directions. The programme models the building of the tower and stops. Everything between practical completion of the fit-out and handing the building over — commissioning systems, witnessing, defects, O&M, client training — occupies eleven activities and forty working days, with almost no logic. On a project of this size that phase realistically runs to four months.

ScheduleInsight · Programme Assurance Review9
7 · Contract testL4 · 25 / 100 · 15% weight
ScheduleInsight · Programme Assurance Review10
8 · Forecast credibility10,000 iterations

08 Forecast credibility

The deterministic completion date is one outcome of a network with uncertain durations, not a commitment. A Monte Carlo simulation of 10,000 iterations runs automatically over the R12 network as part of every review, and places the submitted date well down the resulting distribution.

How this runs — automatically, on engine defaults

No risk workshop is required and none was held. Where the file carries duration ranges — optimistic and pessimistic user fields, or a linked risk register — the engine uses them. This file carries none, so ranges were assigned automatically by risk class: each activity is banded from its phase, duration, activity type, remaining-versus-original duration and position relative to the critical path, and given a three-point range for that band. Long-duration procurement is ranged wider and right-skewed; short fixed inspections are ranged tightly. Correlation groups are applied within phases so the simulation does not sample independently and understate the spread.

Bands, skews and correlation are part of the versioned rule pack in Appendix G, so the same file always produces the same distribution.

Figure 5 — Completion date distribution
P22 — submitted 02 Oct 2027 P50 29 Oct 2027 P80 04 Dec 2027 earlierlater 63 working days between the submitted date and an 80% confidence date
This is a screening distribution, not a QSRA. It is built from generic ranges the engine assigned, not from estimates anyone on this project stood behind, and it models duration uncertainty only — no discrete risk events. Treat the percentiles as an indication of how much optimism sits in the deterministic date, not as a number to commit to a board. Inputs and iteration settings in Appendix G.

The submitted completion date has roughly a one-in-five chance of being met. That is not unusual for a deterministic CPM date — merge bias alone pushes most of them into the P10–P30 band — but a commitment made on 02 October 2027 is a commitment to the optimistic tail.

The distribution understates the risk

The simulation can only sample the network it is given. The absent commissioning, handover and long-lead content identified in section 6 is not in the model, and the missing interfaces in section 5 mean late-phase slippage has no path along which to propagate. The real distribution is therefore wider and later than shown. Treat the P80 above as a floor, not a forecast.

To turn this into a defensible forecast: supply three-point ranges for the activities that matter, add the discrete risk events from the project risk register, and re-run once the corrective actions in section 9 are complete. That is the full QSRA, and it is a separate exercise from this screening run.

ScheduleInsight · Programme Assurance Review11
9 · Conclusion and required actionsTower C · R12

09 Conclusion and required actions

R12 is a competent construction programme with an incomplete back end, submitted with 37 days of unexplained date movement. The first is a technical problem with a known fix. The second is a governance problem, and it is the reason for non-acceptance.

Read together, sections 3 to 8 describe a single pattern rather than a list of defects. The programme is well built through to the frame and thins out steadily thereafter — interfaces degrade from 96 to zero across the sequence, the content that belongs in the final phase is absent, and the completion date that this thin back end produces has moved 49 days without explanation. The technical checks in section 4 are the symptom; the missing late-phase model in sections 5 and 6 is the cause.

Two of the six must-fix items were raised against R11 and remain open. A defect surviving two submissions has stopped being a technical finding and become a governance one: it indicates the review comments from the last cycle were not worked, which is itself worth raising in the reply.

What has to change before R13

Two further items are recommended rather than mandatory — adding long-lead procurement, and producing a change log for the 23 altered activities. The complete register, with verification tests and carried-forward flags, is Appendix F.

On re-submission

R13 will be assessed against R12 and against the accepted R8 baseline. The six must-fix items are re-tested automatically and each closes only when its verification test passes — not when it is reported as done. Items still open at R13 will carry a second-revision flag.

ScheduleInsight · Programme Assurance Review12
10 · Method, basis and limitationsTower C · R12

10 Method, basis and limitations

What the score is

Four layers, weighted 40 / 25 / 20 / 15, each scored 0–100 from the checks in sections 4 to 7. The composite is their weighted sum, with no base allowance and no rounding in the submitter's favour. Weights, thresholds and gate rules are configurable per organisation and are recorded with the assessment, so a score can be reproduced exactly from the source file and the versions in Appendix G.

What the score is not

The weighting is ScheduleInsight's. It is informed by DCMA-EA PAM 200.1, the GAO Schedule Assessment Guide, AACE RP 29R-03 and the NEC4 ECC, but no external body prescribes these weights. Individual checks cite recognised sources; the composite does not, and it should not be presented as a certification. It is a consistent instrument for comparing one revision with the next.

Data limitations

This assessment reads a static XER export plus the R11 and R8 files. Metrics that require data these files do not carry are shown as N/A and are never estimated. Resource loading is absent, so resource-conflict analysis and duration-realism testing are out of scope. CPLI, BEI and Missed Tasks are calculated because an approved baseline is present; where none exists they return N/A rather than a plan-based substitute.

The assessment reads the schedule files only. It does not read the contract, the Scope, the accompanying narrative, the early warning register or the compensation event register. Where this report refers to a compensation event it is reading the CE reference recorded against the activity in the schedule — the finding that 37 days are undeclared means no CE reference is present in the file, and should be confirmed against the CE register before the notification is issued.

Status of this report

This review supports the Project Manager's decision under clause 31. It does not make that decision, does not determine entitlement to time or money, and does not replace review of the accompanying narrative and the contemporaneous records. It is not a forensic delay analysis: it identifies that dates moved, not who caused the movement or who bears the risk.

ScheduleInsight · Programme Assurance Review13
Appendix A · Technical health registerSupports section 4

A Technical health register — 18 checks

Measured values at the R12 data date against the thresholds configured for this contract, with the movement from R11. Activity-level lists for every failed and watched check are available in the Excel export, keyed by the check number below.

#CheckR11R12ThresholdΔResultAffected
01Missing logic (open ends)4.6%5.0%< 5%↑0.4WATCH146
02Leads (negative lags)66zeroFAIL6
03Lags2.9%3.1%< 5%↑0.2PASS119
04Relationship types (non-FS)13%14%< 20%↑1PASS1,082
05Hard constraints2.4%3.1%< 2%↑0.7FAIL119
06High float (> 44 d)8.9%9.4%< 10%↑0.5WATCH274
07Negative float417zero↑13FAIL17
08High duration (> 44 d)3.9%4.2%< 5%↑0.3PASS122
09Invalid dates00zeroPASS0
10Resource loadinginfoN/A
11Missed tasks6.1%8.4%< 5%↑2.3FAIL245
12Critical path testpasspasscontinuousPASS318
13CPLI0.970.94≥ 0.95↓0.03WATCH
14BEI0.940.91≥ 0.95↓0.03WATCH
15Out-of-sequence progress711zero↑4WATCH11
16Logic density2.42.52.0–3.5↑0.1PASS
17Milestone coverage2.6%2.6%> 2%PASS100
18SPI(t) — earned schedule0.960.93≥ 0.95↓0.03WATCH
ScheduleInsight · Programme Assurance Review14
Appendix B · Score and gate rulesSupports section 2

B Score components and gate rule register

The composite is reproducible from the values below and the rule pack versions in Appendix G.

LayerBasisRawWeightContribution
L1 · Technical health18 checks, severity-weighted (Appendix A)7340%29.2
L2 · Execution readinessMean of 8 interface health scores (Appendix C)6425%16.0
L3 · Completeness11 content requirements (Appendix D)4520%9.0
L4 · Contract complianceNEC4 cl.31.3 four-reason test (section 7)2515%3.8
Base allowance — not applied by design0.0
Composite score58.0

Gate rule register

Rules are evaluated after the composite. The most severe triggered rule sets the verdict; rules that did not trigger are shown so the gate can be audited in both directions.

RuleConditionThresholdMeasuredEffect if triggeredState
GR-01Composite below acceptance minimum≥ 6558Cannot acceptTRIGGERED
GR-02Negative float present at submission017Cannot accept cleanTRIGGERED
GR-03Zero-tolerance check failed (leads)06Conditions mandatoryTRIGGERED
GR-04Contract-mandatory content absentnone3Cannot baselinenot applied
GR-05Completion moved beyond notified change≤ 5 d37 dEscalate to PMTRIGGERED
GR-06Open ends above tolerance< 10%5.0%Cannot acceptnot applied
ScheduleInsight · Programme Assurance Review15
Appendix C · Execution interface matrixSupports section 5

C Execution interface matrix

Required paths are derived from the WBS and activity coding for each phase pair. Health is present ÷ required, expressed 0–100.

InterfaceReqPresentMissingHealthClassified fromConfidence
Design → Procurement10092892Activity code PHASEHigh
Procurement → Fabrication7566988Activity code PHASEHigh
Fabrication → Delivery74601481Activity code PHASEHigh
Substructure → Superstructure5048296Activity code PHASEHigh
Superstructure → Envelope58431574Activity code PHASEHigh
Envelope → Fit-out67392858WBS pathMedium
Fit-out → Testing & commissioning48123625WBS pathMedium
T&C → Handover220220Name lexiconLow
Mean health49436013464

Confidence reflects the reliability of the phase classification, which depends on activity coding. Low confidence on the final interface reflects there being too few coded handover activities to classify with certainty — the absence is itself the finding.

ScheduleInsight · Programme Assurance Review16
Appendix D · Completeness registerSupports section 6

D Completeness register

Present = content exists and is logic-linked. Partial = present but incompletely represented or not linked. Absent = no supporting activities.

RequirementStateEvidenceScore
Key Dates & sectional completionPRESENT6 Key Dates, all logic-driven100
Planned Completion & terminal floatPRESENT15 d terminal float shown separately100
Statutory inspections & H&S holdsPRESENT22 activities, logic-linked100
Access & possession datesPARTIAL4 of 7 access dates modelled50
Statutory approvals / building controlPARTIALPresent but not linked to the work they gate50
Temporary works & crane strategyPARTIALCrane erect and dismantle only50
Subcontractor design deliverablesPARTIAL3 of 9 packages represented50
Time risk allowanceABSENTNo provision identified — cl.31.2 requirement0
Long-lead procurementABSENTNo curtain wall, lift or switchgear lead time0
Testing & commissioning structureABSENTNo system-level T&C activities0
Handover, O&M & soft landingsABSENTSingle 10 d activity, no predecessors0
Layer score — mean of 1145
ScheduleInsight · Programme Assurance Review17
Appendix E · Revision comparisonSupports section 3

E Revision comparison — undeclared changes

Activities whose planned dates differ between R11 and R12 with no compensation event reference, early warning or narrative entry recorded against them. Fourteen are on the R12 driving path. Extract of 12 of 23 rows, sorted by impact on Planned Completion; the complete register is in the Excel export.

Activity IDNameWBSR11 finishR12 finishMoveDriving
TC-CW-4120Curtain wall install — L18 to L24Envelope14 Apr 2702 Jun 27+35 dYes
TC-CW-4090Curtain wall install — L12 to L17Envelope26 Feb 2708 Apr 27+29 dYes
TC-FO-5210Fit-out — L18 to L24 ceilingsFit-out03 Jun 2712 Jul 27+27 dYes
TC-ME-6040Riser installation — zone 3MEP19 Mar 2723 Apr 27+25 dYes
TC-FO-5240Fit-out — L18 to L24 finishesFit-out30 Jun 2703 Aug 27+24 dYes
TC-ME-6110AHU set and connect — roof plantMEP07 May 2704 Jun 27+20 dYes
TC-ST-3080Core slipform — L20 to roofSuperstructure11 Dec 2605 Jan 27+18 dYes
TC-CW-4150Curtain wall — podium glazingEnvelope21 May 2711 Jun 27+15 dNo
TC-ME-6070Switchgear energisationMEP02 Jul 2716 Jul 27+10 dYes
TC-FO-5310Lift car fit-out and commissioningFit-out13 Aug 2727 Aug 27+10 dYes
TC-EX-7020External works — plazaExternal18 Jun 2725 Jun 27+5 dNo
TC-ST-3120Steel erection — podium roofSuperstructure09 Oct 2614 Oct 26+3 dNo

Reconciliation of the 49-day movement

SourceReferenceDaysStatus
Notified compensation eventCE-041 — late access, podium7DECLARED
Notified compensation eventCE-044 — design change, L18 riser5DECLARED
No reference recorded23 activities — see above37UNDECLARED
Total movement in Planned Completion49
ScheduleInsight · Programme Assurance Review18
Appendix F · Corrective action registerSupports section 9

F Corrective action register

Every item carries an owner, a due date and the verification test that closes it. An item closes when its test passes on re-analysis, not when it is reported as done. Items unresolved from R11 are flagged.

IDSeverityFindingRequired correctionOwnerDueVerification test
CA-01MUST37 days of undeclared completion movementProvide CE references covering the movement, or restore the R11 dates.Planning Mgr21 MarCE register reconciles to Planned Completion
CA-02MUSTPlanning Mgr21 MarAllowance present and separately reported
CA-03MUST17 activities in negative floatResolve by logic correction, constraint removal or agreed date change.Planning Mgr21 MarCheck 07 returns zero
CA-04MUSTT&C and handover absent; interfaces 7–8 emptyDevelop system-level testing, commissioning and handover with logic into completion.Construction Mgr04 AprInterfaces 7–8 health ≥ 70
CA-05MUST6 leads (negative lags) R11Replace each with SS/FF logic and a positive or zero lag.Planner21 MarCheck 02 returns zero
CA-06MUSTHard constraints 3.1%, up from 2.4%Review all 119; remove any not tied to a Key Date, access date or statutory deadline.Planner21 MarCheck 05 below 2%
CA-07SHOULDLong-lead procurement absentAdd curtain wall, lift and switchgear procurement with lead times and delivery links.Procurement04 AprCompleteness item returns present
CA-08SHOULD23 dates altered with no recordProduce a change log for the 23 activities; withdraw or justify each.Planning Mgr21 MarChange log accepted by the PM
CA-09SHOULDEnvelope → Fit-out interface at 58Add the 28 missing handoff links between envelope completion and fit-out start by zone.Planner04 AprInterface 6 health ≥ 75
CA-10MONITORSPI(t), BEI and CPLI below 1.0 for 3 revisionsNo correction required at submission. Report recovery trajectory in the R13 narrative.Planning MgrR13Trend reviewed at the next gate
ScheduleInsight · Programme Assurance Review19
Appendix G · Evidence and provenanceReproducibility

G Evidence and provenance

Everything required to reproduce this assessment, or to challenge it.

Report reference
SI-2026-02-TOWERC-R12-0447
Generated
2026-03-02T09:14:22Z
Source file
TowerC_R12_2026-02-28.xer
Source SHA-256
a41f7c02e8b9…d31c9d2e
Comparison file
TowerC_R11_2026-01-31.xer
Comparison SHA-256
6b28de41a0f7…8ac41b70
Baseline file
TowerC_R8_Accepted_2025-09-12.xer
Baseline SHA-256
1f90b7c4e223…55de0a19
Analysis hash
7c30ab19
Data date
2026-02-28 (read from file)
Calendar basis
Read from file — 5 calendars
Parser version
XER/PMXML parser 3.1
Rule pack
DCMA-aligned 2.4 · NEC4 pack 1.1
Scoring config
SI acceptance gate 2.0
Risk engine
Monte Carlo 1.6 · 10,000 iterations
Processing
In-browser — file never uploaded
ScheduleInsight · Programme Assurance Review20
Appendix H · ResponsibilitiesReproducibility

H Reconciliation and responsibilities

Reconciliation

The cover, report body, appendices and Excel export are generated from one model. Every count below agrees across all four outputs.

CheckBodyAppendixExcelResult
Total activities3,8423,8423,842AGREE
Incomplete activities2,9142,9142,914AGREE
Negative float activities171717AGREE
Hard constraints119119119AGREE
Undeclared date changes232323AGREE
Missing interface paths134134134AGREE

Who acts on this report

RoleRequired action
PlannerClear the leads, negative float and surplus hard constraints; add the missing envelope-to-fit-out links; re-run the schedule calculation.
Planning ManagerReconcile the completion date movement against the CE register; identify time risk allowance; produce the change log for the 23 altered activities.
Construction ManagerDevelop the testing, commissioning and handover sequence at system level with logic into completion.
Project ManagerNotify non-acceptance by 14 March citing cl.31.3 reasons (b) and (c); set the resubmission date; confirm correction owners.

Example report using illustrative project data. Primavera and P6 are trademarks of Oracle Corporation. NEC4 is a trademark of Thomas Telford Ltd; JCT of The Joint Contracts Tribunal Ltd; FIDIC of the Fédération Internationale des Ingénieurs-Conseils. DCMA, GAO and AACE marks belong to their respective owners; ScheduleInsight is independent and is not affiliated with or endorsed by any of them.

ScheduleInsight · Programme Assurance Review · Tower C R1221

Produce this from your own schedule.

Every figure in this report is derived from the submitted programme — no activity tagging, no phase mapping, no risk workshop. The file is parsed in your browser; nothing is uploaded and nothing is retained.

Analyse your schedule free All report examples See pricing