A forensic analyst's but-for question usually gets answered the slow way. Copy the schedule, insert one delay, recalculate, read the milestone date, then start again with the next delay. Each answer costs hours of editing.
What-if worlds turn that question into a selection. Pick any set of the changes between two schedule updates, and FPM builds the schedule with exactly those changes and dates every tracked milestone. It works on the What-if worlds page in the app and for AI clients over MCP.
Two Ways to Ask
A window holds every change between a base update and its revision: activities and relationships added, removed or modified, progress recorded, durations re-estimated, external dates moved. The What-if worlds page lists them, grouped by change type or by WBS, and you tick the ones you want to test. Then you choose a mode.
The base schedule, the window's floor, and your selection. Nothing else. It reads where the milestone lands with only these changes.
The revised schedule with your selection taken out. This is the but-for reading: the update as it would stand without these changes.
Every world sits at the revised data date, on the same frame the delay analysis uses. An empty selection gives the floor dates and a full selection gives the revised dates, and both are shown beside every world you build, so each reading has its two ends in view.
The two modes can disagree. On one of our test networks, cutting a steel erection activity from 20 days to 10 brings a weathertight milestone in by 7 days when applied to the base, where the roof path drives. Take the same cut out of the full update and it reads 0, because there the envelope work's growth drives the milestone. Both readings are correct, because the modes ask different questions.
The Same Ground in Every World
Some changes in a window cannot be chosen in or out. A change to the schedule options alters how the whole network calculates. A network restructure, as we described in When a Network Change Is One Event, is a set of interwoven relationship edits that only form a valid network together. FPM calls these the window's floor. The floor is held in every world, in both modes, and it never appears as a change you can tick.
That keeps every what-if question on the same ground, whoever asks it. The page shows the floor in its own band, with how far it moves each tracked milestone, so its effect is visible without being selectable.
Changes That Belong Together
Some changes cannot stand alone. An added relationship needs the added activities at its ends. A removed activity needs its relationships removed with it. When a selection needs another change in order to build, FPM brings that change in and lists it, so the page always says exactly what the world contains. An added activity also brings its new relationships to work already in the world, so it never floats unattached.
A second kind of pairing is advisory. A late actual start may be late because new logic held the activity back. Apply the progress without that logic and the whole delay lands on progress. FPM names the upstream changes that could have forced the date, warns when a world leaves them out, and offers to add them. It never adds them on its own. The choice stays with the analyst, made in plain view.
Scenarios: Steps You Can Replay
One world answers one question. An argument usually runs as a sequence: first one party's design changes, then the other's resequencing, then the late deliveries. A scenario saves that sequence on the window as a named, ordered list of steps. It either builds up from the floor or takes changes away from the revised schedule, a direction fixed when the scenario is created.
Each step reads against the one before it. Within one scenario the steps chain from the floor to the full update: the step readings, plus a closing reading for whatever the steps left out, account for the whole distance between the floor date and the revised date.
Only the recipe is stored. Every step is rebuilt live, so anyone with access can open the scenario and replay it. Reorder the steps and the readings change, which is expected: each reading describes one position in one order.
One Date per Question
Every world is one date, read on the schedule's own logic. What a world gives you is a precise statement: with these changes brought in, or taken out, in this order, the milestone lands on this date. That is the statement a time-impact analysis was always trying to produce, and the network produces it, as we described in Why Concurrent Impacts Don't Sum.
In the App and in the Conversation
What-if worlds run the schedule calculation live, so a window with no analysis run still gets a working page.
The same capability is available over MCP. list_diff_units lists a window's changes and its floor, evaluate_subset builds one world and reads its milestone dates, and the scenario tools create, extend and read saved scenarios. An AI client can build a world in conversation and save the steps as a scenario that an analyst then opens and replays on the What-if worlds page.
Time-impact analysis by hand made each but-for question expensive enough that analysts asked few of them. As a selection, the question can be asked as often as the argument needs, on the same ground every time.