CAP·SAR · Schedule Assurance Review
The integrated schedule is the one artifact the sanction rides on: every package, every purchase order, the tie-in window, and the in-service date resolve to it. CAP·SAR works that schedule in full and hands your team a prioritized correction plan before the baseline locks at sanction, while the logic can still be fixed.
Deep analysis in. A short, prioritized plan out.
The problem
A schedule with broken logic is a paper map in a nice frame: it shows the route, but it cannot tell you the bridge ahead is out. Sound logic is what lets a schedule behave like a live map instead, rerouting and re-forecasting the in-service date the moment a vendor slips. Most project baselines lock at sanction without anyone stress-testing the logic underneath, and three failures hide there in plain sight.
If the driving chain does not run through procurement and the window to the business milestone, the date on the cover is not the date the logic supports.
Delivery sits on the plan as a date, not as the end of a chain from IFC through order to receipt, so a late drawing never moves it until the crane is waiting.
On a coupled project the tie-ins have to fit the outage. If the fragment is not bounded, the schedule cannot tell you it does not.
What makes it different
CAP·SAR rebuilds your schedule’s logic from first principles with a calendar-aware critical-path engine, then reads it three ways that a settings audit cannot.
Every long-lead item traced from issued-for-construction through the purchase order to receipt on site, so a late drawing shows up as a late crane before the crane is booked.
We trace the driving chain backward from the business milestone, not the network’s last bar, and report how far it actually reaches through real work and through the window.
We separate the planned duration from the real built-in reserve to the date you committed to, and flag a finish that logic does not actually drive.
Leveling, and the real driver
Contingency to the committed date
Beyond the checks
The same engine that grades the schedule also stress-tests it. These are the two numbers a steering team actually asks for at sanction: how likely is the date, and what do we watch once the critical path is confirmed.
The schedule, simulated
Duration risk simulated down the driving path, thousands of runs. Against a fourteen-month commitment the P80 lands five weeks late, driven by the exchanger delivery: exactly the finding you want before sanction, not after. Illustrative.
Near-critical exposure
After “is the critical path real,” the next question is which chain becomes it. These are the ones a two-week vendor slip promotes, ranked, so your team watches the right work.
Every check we run
The core is the same public-framework set the turnaround practice runs, DCMA 14-point, GAO, AACE, and PMI, because topology, float, and the critical-path cascade are the same discipline on any schedule. The project extension carries what turnarounds lack: engineering and procurement logic, gate milestones as anchors, cost loading, payment linkage, and the window. Each check is weighted by how much it puts the in-service date at risk, and the calibration bands are a project’s own. Nothing is a proprietary score you cannot see inside.
| Check | What it catches | |
|---|---|---|
| Configuration & integrityshared core | ||
| A1 | Scheduling settings | The scheduling options are set so the forward and backward pass can be trusted. |
| A2 | Calendars | Work patterns are real, and no calendar quietly runs more hours than its name implies. |
| A3 | File & status integrity | One data date, clean actuals, nothing corrupting the calculation. |
| Network logicshared core | ||
| B1 | Open ends | Every activity has something driving it, so a slip actually propagates. |
| B2 | Dangling logic | No activity tied on only one side, hiding its true impact on the finish. |
| B3 | Relationship types | Finish-to-start dominant; overlaps modeled honestly, not by convenience. |
| B4 | Lags | Delays built into the logic are justified, not padding the plan. |
| B5 | Leads / negative lags | No negative lags papering over missing sequence detail. |
| B6 | Hard constraints | Dates driven by logic, not pinned by constraints that mask the real risk. |
| B7 | Redundant & circular logic | No loops or duplicate ties distorting the calculated path. |
| Float & critical pathshared core | ||
| C1 | Negative float | The plan is achievable as drawn, not already behind on day one. |
| C2 | Unexplained high float | No activity floating longer than the whole project with no reason it should. |
| C3 | Critical-path validity & reach | The critical path is continuous, real, and reaches the in-service date you promised. |
| C4 | Near-critical & merge exposure | The paths about to become critical, and the points where many converge, are visible. |
| C5 | Float distribution | The criticality profile is sane, not a network with no real spine. |
| Durations & milestonesshared core | ||
| D1 | Activity durations | No oversized activities hiding sequence, detail, and risk. |
| D2 | Level of effort | Hammocks and LOE are bounded, not silently inflating the critical path. |
| D3 | Milestones | Gates, mechanical completion, PSSR, and in-service milestones are structured and tied on both sides. |
| Resources, leveling & densityshared core | ||
| E0 | Leveling state | Whether the schedule was resource-leveled, determined forensically from the file. |
| E1 | Resource loading | The work that should carry crews and hours actually does. |
| E2 | Assignment integrity | No broken, zero-unit, or impossible resource assignments. |
| E3 | Leveling coherence | The leveled dates and the underlying logic agree with each other. |
| E4 | Resource density | The manpower curve is physically achievable, not a wall of parallel work. |
| Coding & traceabilityshared core | ||
| F1 | Code completeness | Phase, area, system, discipline, and package coding present, so the plan can be sliced and audited. |
| F2 | WBS structure | A clean, meaningful hierarchy, not empty scaffolding. |
| F3 | Traceability | Activities tie back to work packages and purchase orders and carry unique, legible names. |
| Project extensioncapital projects | ||
| P1 | Engineering & procurement logic | Issued-for-construction before fabrication, purchase order before delivery, delivery before install: the sequence the field actually depends on. |
| P2 | Gate milestones as anchors | G3, G4, mechanical completion, PSSR, and in-service exist as milestones, tied on both sides, and the plan re-lays from them. |
| P3 | Cost & resource loading | The baseline carries the hours and the money the control estimate says it does, so earned value can be read against it later. |
| P4 | Milestone-payment linkage | Payment milestones tie to real completion, not to dates a contractor can hit without finishing the work. |
| P5 | The window fragment | On a coupled project, the in-window scope is bounded by the window start and end, and the pre-window work is verified complete before it. |
| P6 | Permit & weather windows | Seasonal and permit constraints are modeled as what they are, not as constraints that mask the real driver. |
The engine settings are valid, so the calculated dates can be trusted at all.
The critical path is continuous, made of real work rather than level of effort, and reaches the in-service date.
One data date and clean actuals, so the measurement rests on solid ground.
How it reads out
A schedule can be well built and still not ready, so we report quality and readiness separately. You see how good the model is, and, independently, whether it is safe to lock as the sanction baseline.
An absolute maturity grade across every element. Project schedules are longer and lower-density than turnaround ones, so the bands are calibrated to projects and the grade is honest.
When readiness is withheld, the report says exactly why, in the language a scheduler can act on rather than a code.
Why you can trust the output
Every figure in the review is computed by the engine, never by a language model. The interpretation on top has to earn its way out, twice, before it reaches your team.
The CPM engine and the checks produce every figure in the report. The model reads them and explains them; it cannot write one.
A finding may only cite numbers that exist in its own evidence. A figure that cannot be traced back to the engine removes the finding, automatically.
A second pass is built to argue against every finding from the same data. Only the findings it cannot knock down reach your report.
Ask any vendor what happens to an AI finding that is wrong. Here, it never renders.
What you get
The analysis is exhaustive. What comes back to your team is not: a clear, prioritized plan that maps each issue to its fix, early enough to make the changes before sanction freezes the baseline and the date is committed.
The correction plan is the decision document: each finding, why it matters, and the specific fix, in priority order. The workbook behind it is the line-by-line repair manual, every flagged activity with its issue and acceptance criteria.
And the findings do not expire with the review. At closeout, CAP·SPR traces the defects flagged here to the specific as-built activities they delayed and the days they cost. The defects we flag now are the ones we can later prove mattered.
CAP·SAR runs as a standalone review, or as the schedule engine inside the CAP·AR3 sanction readiness review, where it feeds the final investment decision.
What changes
Your guide
CAP Intelligence is an independent assurance practice built from the owner’s side, across refining, petrochemicals, industrial gas, LNG, and power, as the owner accountable for the capital outcome and as the consultant brought in to protect it. It is the capital-projects practice of STO Intelligence LLC, and shares one spine with its turnaround practice.
Our methods stay at public-framework level, AACE, CII front-end planning practice, PMI, DCMA, and GAO, so every finding is defensible and nothing is a black box. You own the standard, not a proprietary score you cannot see inside.
Why CAP Intelligence
Empathy for the seat you are in, sanctioning a project on a schedule you cannot see inside. Authority to check it: a real CPM engine, public frameworks, a project-calibrated standard, and owner-side experience of what a late long-lead item does to a window.
Where this goes
The correction plan fixes this schedule. The same engine runs inside the CAP·AR gate reviews when you want the whole package checked, CAP·SPR proves at closeout which findings mattered, and the discipline that prevents them lives on in CAP·PATH + CAP·CORE, the standard you own, run live.
Send us the P6 file for the project you are taking to sanction. We will show you where the logic holds, where it does not, and what to fix before you lock the baseline.