What attribution means for a phase
A phase milestone moves because something on the path behind it moved: an activity started late, ran long, or picked up a new predecessor. Attribution ties the milestone's movement in one update window to those activities, and through them to the trades that perform them. Done window by window across the updates as issued, it shows when float was consumed and by whom, instead of one total at the end of the job.
Float ownership matters here. Most contracts never say who owns float, and the usual default is first come, first served: whoever's work consumes it first uses it. A contract that says otherwise changes the reading, which is why the rule is stated rather than assumed.
How Pathizer attributes a phase's movement
Continuous Float Attribution walks the evaluated float path of each phase in every update pair and attributes float consumption and recovery first come, first served against that update's total float variance, the prior path first. A recovery claimed without an actual finish to confirm it is shown as unverified, with zero attribution, until a later update confirms it.
Every window closes to the phase's movement. What the as-built drivers on the path account for, what came from Half-Step changes, and what was off the path or could not be traced are shown as separate parts that add up to the total float variance, so whatever cannot be traced is printed as its own figure rather than hidden.
Reading a trade handoff
On the driving path, one trade's finish usually feeds the next trade's start. When the first finishes late, the second starts late through that relationship, and the milestone moves. Pathizer shows the relationship itself, so a late handoff reads as a link you can open in the schedule file rather than as a judgment. In the Network Diagram each node shows its driver type, its relationship, its attribution value and its total float in calendar days.
