Quick answer: A Primavera P6 baseline is accepted when its logic density leaves no open ends, its constraints and lags are justified rather than used to force a date, its calendars match how work is actually performed, its resource and cost loading reconciles to the contract value, and the accompanying narrative explains the plan rather than just restating the schedule.
Why Baselines Get Rejected
A baseline schedule is not just a file submission — it becomes the schedule of record that every future delay claim, progress payment, and time extension request gets measured against. Owner, agency, and GC reviewers know this, which is why baseline review is typically the most scrutinized submission of the entire project. Most rejections trace back to a short list of recurring issues rather than anything unusual about the specific project.
The Baseline Acceptance Checklist
- Logic density. Every activity except the project start and finish milestones should carry at least one predecessor and one successor. Reviewers run a schedule check for open-ended activities before looking at anything else, because open ends distort float and the critical path throughout the network.
- Constraint justification. Hard constraints — Must-Finish-On, Must-Start-On, Finish-No-Later-Than — should appear only where the contract requires them, typically on interim and final milestones. A baseline loaded with constraints on ordinary construction activities signals that the schedule was built to match a predetermined date rather than modeled from real logic.
- Lag review. Lags used in place of real activities (waiting periods, cure times, lead times modeled as a lag rather than a task) are a common reviewer flag. If the lag represents real work or a real waiting period, it should usually be its own activity so it is visible, tracked, and can carry its own logic.
- Calendar assignment. Every activity should carry the calendar that actually governs it — standard, weather-sensitive exterior work, or activities with fixed non-working periods such as inspection holds. A single default calendar applied to every activity regardless of actual working pattern will misstate duration and float on anything that doesn't match the default.
- Resource and cost loading reconciliation. When the baseline is cost- and resource-loaded, the total loaded value should reconcile to the contract value. Reviewers on public-agency projects check this explicitly, and a schedule loaded well below contract value signals the loading is nominal rather than a real reflection of the cost plan.
- Activity coding and location detail. Activity descriptions should identify the location, area, or building the work occurs in, and activity coding should match whatever work-breakdown or responsibility structure the contract requires. Generic activity names in a schedule with hundreds of similar activities make the schedule unreviewable and undermine delay analysis later.
- Narrative quality. The baseline narrative should explain the sequencing logic, the basis for key durations, how the critical path was determined, and any assumptions the contractor made — not simply restate what the schedule file already shows. A thin or templated narrative is one of the most common reasons a technically sound schedule still gets returned with comments.
Running Your Own Review Before Submission
Before submitting a baseline, run the same checks a reviewer will run: pull the schedule check report for open ends, filter for hard constraints and sort by lag duration, spot-check calendar assignment against activity type, and total the resource/cost loading against the contract value. This is the same discipline covered in more depth in the most common Primavera P6 schedule errors that get flagged in owner review — treating that list as a pre-submission checklist, rather than a post-rejection diagnosis, is what separates a baseline that clears review the first time from one that generates a cycle of reviewer comments.
On federal and other public-agency contracts, these same checks line up closely with the widely used DCMA 14-point schedule check, so running that assessment internally before submission can catch many of the same issues a government reviewer will flag.
If the Baseline Gets Rejected
Treat reviewer comments as a checklist, not a negotiation. Address every comment specifically in the resubmission narrative, even ones that seem minor, because an unaddressed prior comment is the fastest way to trigger a second rejection. Where a comment reflects a legitimate logic or constraint problem, fix the underlying schedule rather than just adjusting the number the reviewer flagged.