A schedule update is a photograph. Two of them, a month apart, show where a milestone stood at each end of the month. Neither shows what held it in between, and that is often the question a delay claim turns on.
FPM now answers it for every day of a window. For one milestone, it reads which activities controlled it on each calendar day between two updates, when control changed hands, and what in the project record supports each change. AACE's RP 29R-03 calls this reading the as-built critical path.
One Schedule for Every Day
An analyst can read the as-built critical path between two updates by hand: start from the earlier update, enter the actual dates the record holds as of a chosen day, and recalculate. It is careful work, and the tools have not made it practical for every day of every month.
FPM does it for every day. Each day's schedule starts from the earlier update with its data date moved to that day, and gives each activity the status the later update records for it as of that day: not started, in progress, or complete. Nothing recorded after that day is used. FPM recalculates the schedule and reads the milestone's forecast, its driving path, and the open activities at the head of that path.
Plan revisions, such as new logic, re-estimated durations, and added or deleted work, wait for the later update's data date by default. Progress is read day by day, and revisions are applied once, at the data date where the update records them.
A Month at Riverdale
Here is one window from Riverdale, one of our anonymized demonstration projects: the Jul 2017 to Aug 2017 window, and the milestone Support Columns East (BC 13 & 15). The milestone runs on a seven-day calendar, so every day of waiting is a day of slip. On 1 July it was forecast for 4 April 2018.
Solid days and markers are pinned by a recorded actual or a data date; faded ones are inferred. S, J and R mark a shift, a join and a release; no path succeeds to its own next activity in this window. Progress moved the milestone 24 days; the update's revisions added 3.
For the first eleven days the milestone waited on the resolution of the regulatory agencies' comments, and its forecast slipped from 4 April to 10 April. The comment resolution finished on 11 July. The next day, control passed to the delivery of the permanent reinforcing steel for the tunnel's cast-in-place roof deck.
For the rest of the month that delivery and two footing backfills, east footing 15 and north footing 11, ran within a few days of each other. None of the three had started, so the forecast slipped with the calendar, and the lead passed between them or was tied about once a week. From 27 July the rebar delivery held control to the end of the window. On 1 August the forecast stood at 28 April 2018.
Pinned or Inferred
A day-by-day reading is only as good as the record behind it, so FPM says how well each day is supported. A day is pinned when a recorded actual on the driving path, or a data date, falls on it. Otherwise it is inferred: the record allows the reading, but no actual on the path fixes it.
Every hand-off is named as one of four kinds. In a succession the same path carries on to its next activity. In a shift another path takes over. In a join a second path ties the one driving, and in a release a tie breaks.
In the Riverdale window, five of the 32 days are pinned: the two data dates, the shift on 12 July that follows the comment resolution's finish, the join on 25 July that follows the start of the MSE leveling pad, and the shift on 27 July that follows the start of the MSE panels. The pad and the panels come next on the backfills' path, so their recorded starts are evidence for it. Between the pins on 12 July and 25 July, the record cannot say which of the two paths was ahead on a given day. The band still shows the day-by-day reading, but FPM marks those days held shared, with both paths, from 13 July to 24 July. That is all the record supports.
That distinction matters most when the reading is challenged. An opposing expert's first question about an as-built critical path is what evidence places each hand-off. Here the answer is printed next to each one.
Progress and Revisions, Kept Apart
Over the month the milestone moved 27 calendar days, from 4 April to 1 May 2018. The daily reading splits that movement by source. Progress alone, the days walked with the plan held as it was, moved it 24 days, to 28 April. Work added during the month, entered at its recorded dates, moved it by nothing. The revisions the August update made moved it the other 3 days, to 1 May.
The revisions did more than add three days. In the August update the milestone is driven by a different path, through a newly added activity giving access to the Zones 4-6 leveling pad. FPM flags this with a warning: the path the daily band ends on is not the path the update reports, because the revisions rebuilt it. Read from the two updates alone, that looks like one path change. The daily reading keeps its two parts apart: the band shows what progress did during the month, and the warning marks the path the revisions put in place at the update.
Choices, Disclosed
Some questions the record leaves open, and FPM makes each of them a stated setting:
Held to the update's data date by default. A hindsight timing that lets started work take its revised logic from its recorded start is shown beside the default.
Held in each day's schedule until the update's data date by default, and a day it holds says so. Optionally, a deleted tie is released from the day the work it held actually started.
An activity of your choosing, compared with the milestone day by day: where the two agree, and the days they part and rejoin.
An optional float threshold that lists the paths close to taking over beside each day's controllers.
In the Riverdale window, a near-critical band of five working days shows that from 12 July on, whichever of the rebar delivery and the backfills was not in control sat no more than three working days behind. The band only lists who is close; it changes no controller.
In the App and in the Conversation
The As-built critical path page draws the milestone's forecast over the band of controllers, coloured by path, responsible party or WBS, with one row per controlling activity. Pick any day to see its readout, the evidence for its hand-off, and a Gantt of that day's driving path. It reads as soon as the window exists, in seconds.
The same reading is available over our MCP server. get_as_built_critical_path returns the band, the hand-offs, any single day, the movement split and the deleted work the reading used, for one window or a run of consecutive windows.
The as-built critical path says what controlled a milestone. It does not measure delay: the days a path held control are not added up against the milestone's movement. How far each change moved the milestone is the job of the impact analysis, and what is holding it in a single update is the job of critical path drag. Who is responsible for the path that held it remains the analyst's question and the contract's. What FPM gives them is the path for every day, and the evidence for each hand-off.