STO·SAR · Schedule Assurance Review
Is your critical path real, and does it reach the startup you promised?
The execution schedule is the one artifact the whole event rides on: every crew, permit, and the restart date resolve to it. STO·SAR works that schedule in full and hands your team a prioritized correction plan before baseline lock, while the logic can still be fixed.
Deep analysis in. A short, prioritized plan out.
Graded against public standards, not a vendor tool
The problem
Most schedules get approved because they look complete.
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 finish the moment something moves. Most execution schedules are baselined without anyone stress-testing the logic underneath, and three failures hide there in plain sight.
If the driving chain does not run to the business milestone, the date on the cover is not the date the logic supports.
Add crews to a resource-driven event and it compresses; to a logic-driven one and nothing moves. You need to know which you have.
Float is not contingency. We measure the real reserve between the plan and the date you committed to.
What makes it different
A CPM engine, not a checklist.
STO·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.
Leveled or not, and what really drives the date
P6 overwrites the evidence when it levels, so we determine the leveling state forensically, then measure how much of the duration is logic versus resource limits.
The path to the startup you promised
We trace the driving chain backward from the business startup milestone, not the network’s last bar, and report how far it actually reaches through real work.
Reserve measured, not assumed
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 numbers a checklist cannot produce.
The same engine that grades the schedule also stress-tests it. These are the two numbers a steering team actually asks for: how likely is the date, and what do we watch once the critical path is confirmed.
The schedule, simulated
committed date
Duration risk simulated down the driving path, thousands of runs. Against a 35-day commitment the P80 lands a day late: 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-day slip promotes, ranked, so your team watches the right work.
Every check we run
Twenty-five checks, six categories, three gates.
Each check is measured against public frameworks, DCMA 14-point, GAO, AACE, and PMI, and weighted by how much it puts the restart at risk. Nothing is a proprietary score you cannot see inside.
| Check | What it catches | |
|---|---|---|
| Configuration & integrity10 of 100 points | ||
| A1 | Scheduling settings | The P6 options are set so the forward and backward pass can be trusted. |
| A2 | Calendars | Work patterns are real, and no calendar is quietly set to run more hours than its name implies. |
| A3 | File & status integrity | One data date, clean actuals, nothing corrupting the calculation. |
| Network logic35 of 100 points | ||
| 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 are 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 path22 of 100 points | ||
| 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 entire event with no reason it should. |
| C3 | Critical-path validity & reach | The critical path is continuous, real, and reaches the startup 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 & milestones10 of 100 points | ||
| 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 | Feed-out, handover, and startup milestones are structured and tied on both sides. |
| Resources, leveling & density12 of 100 points | ||
| 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 & traceability11 of 100 points | ||
| F1 | Code completeness | Phase, unit, system, and discipline 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 orders and carry unique, legible names. |
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 promised startup.
One data date and clean actuals, so the measurement rests on solid ground.
How it reads out
Two answers, never blended into one.
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 sanction.
An absolute maturity grade across all 25 elements. The industry median sits in Developing, so the grade is honest and the headroom is real.
When readiness is withheld, the tool says exactly why, in the language a scheduler can act on rather than a code.
Why you can trust the output
Findings that survived a challenge.
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 engine writes every number
The CPM engine and the 25 checks produce every figure in the report. The model reads them and explains them; it cannot write one.
Untraceable figures kill the finding
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.
Refuted findings never render
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
A correction plan handed over before baseline lock.
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 the baseline is frozen and the date is committed.
schedule
25 checks
+ workbook
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, STO·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.
STO·SAR runs as a standalone review, or as the schedule engine inside a STOAR3 gate review, where it feeds the final sanction.
What changes
The difference before baseline lock.
Without STO·SAR
- ×A critical path no one confirmed actually reaches the startup date
- ×Broken logic found in execution, when the fix costs days you do not have
- ×Contingency everyone assumed but the schedule never carried
With STO·SAR
- ✓A driving path verified to reach the startup you committed to
- ✓Logic corrected before baseline lock, while it is cheap to change
- ✓The real reserve to your date, measured and stated
Your guide
We have sat in the seat, on both sides of the table.
STO Intelligence is an independent assurance partner, founder-led by 25 years across refining, petrochemicals, and LNG, as the owner accountable for the outcome and as the consultant brought in to protect it.
Our methods stay at public-framework level, DCMA 14-point, GAO, AACE, and PMI, so every finding is defensible and nothing is a black box. You own the standard, not a proprietary score you cannot see inside.
Why STO Intelligence
Empathy for the seat you are in, staking a whole plant on a schedule you cannot see inside. Authority to check it, a real CPM engine, public frameworks, and a founder who has owned the restart date.
Where this goes
One review fixes one event. The system is the prize.
The correction plan fixes this schedule. The same engine runs inside a STOAR gate review when you want the whole event checked, STO·SPR proves at closeout which findings mattered, and the discipline that prevents them lives on in STO·PATH + STO·CORE, the standard you own, run live.
Run an independent engine over your schedule.
Send us the P6 file for the event you are planning now. We will show you where the logic holds, where it does not, and what to fix before you lock the baseline.