nPlan risk forecasts cannot establish delay entitlement
nPlan documents schedule forecasting, risk analysis, and assisted project-controls workflows. A forecast can focus management attention, but delay entitlement still depends on the adopted contract, approved baseline and updates, status dates, contemporaneous facts, notice, responsibility, causation, concurrency, mitigation, records, and authorized commercial or legal determination.
Editorial figure by Contractor Systems Index. Source context: nPlan official product record.
Treat the forecast as a dated project-controls input
nPlan's official record supports the statement that its products are positioned for construction schedule forecasting and risk analysis. The direct project answer is that a forecast describes possible future schedule behavior from a defined data and model state. It does not establish what has happened, why it happened, which party is responsible, whether notice requirements were met, or whether time or money is due under the adopted contract.
For every forecast, retain the project and contract identifiers, schedule file and native version, approved baseline reference, status date, calendars, coding, activity and milestone identities, logic, constraints, actual starts and finishes, remaining durations, progress rules, out-of-sequence treatment, resource or cost data if used, change and fragnet records, risk register, source documents, missing-data treatment, model and configuration version, run time, output, uncertainty, reviewer, disposition, and later comparison to actual updates.
Separate schedule risk from contractual causation
A model may identify activities associated with risk or forecast a completion distribution without knowing the governing contract, contemporaneous access, design information, submittals, procurement, weather, labor, means and methods, owner direction, contractor performance, third-party events, mitigation, acceleration, or concurrent delay. Those facts require project records and qualified schedule, commercial, technical, and legal analysis.
The project ledger should distinguish predicted risk, observed event, schedule update, potential change, notice, directed work, mitigation decision, critical-path effect, excusable delay, compensable delay, concurrency, approved extension, settlement, and final decision. A risk score should not automatically create a claim, reserve, blame assignment, completion commitment, owner communication, or subcontract action.
Test data quality and model disagreement
A buyer demonstration should use the same schedule before and after a controlled status update, logic correction, calendar change, added constraint, revised progress entry, late activity, missing actual date, changed scope, and approved fragnet. Reviewers should see which inputs materially move the forecast, whether impossible or inconsistent data is flagged, how uncertainty is expressed, and how an authorized planner can disagree without losing the original result.
Add two schedules with different coding and detail, a sparse early-stage plan, a recovery schedule, a contractor and owner schedule with conflicting status, and a project type outside the demonstrated training population. Ask how the product handles data rights, confidentiality, version history, model changes, benchmark comparability, explanation, manual continuation, export, and retirement. Provider-reported dataset scale is not project-specific forecast validation.
Keep professional and contract authority outside the model
The GAO Schedule Assessment Guide supplies public schedule-quality context, and the AIA A201 record identifies one industry contract-form family. Neither source makes AIA A201 applicable to a project, certifies nPlan, or determines causation or entitlement. The executed contract, project requirements, governing law, records, and authorized decision process control the actual matter.
Contractor Systems Index reviewed the sources on August 28, 2026. No material post-August 27 development was established. Buyers should verify product and package, schedule formats, data mapping, model scope, version control, explanation, access, integrations, security, testing, professional review, evidence export, contractual use restrictions, and measured accuracy on a representative project population.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Contractor Systems Index will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.