Expected Finish Impact on Free Float

P6 treats Expected Finish as a constraint flag on the activity even though it's a "soft" constraint that doesn't drive dates. Free float is computed as the room an activity has before its early start pushes the early start of its immediate successors — that logic assumes the activity is free to shift. Once the flag is present, P6 no longer assumes it's freely floatable and reports zero free float.

Practical takeaways:

- The zero is a side effect of the flag, not a real loss of scheduling room — successor early starts are still driven by logic, not by the constraint.

- If free float must stay meaningful on in-progress activities, don't put Expected Finish directly on them — track expected finish outside the float calc (UDF or activity code), or keep the constraint only on final delivery activities.

- Constraint count is a schedule-quality signal in its own right: agencies flag schedules where constraints pile up, because each one masks real float.

Short version: the activity didn't suddenly lose latency — P6 shows zero because the constraint breaks free float's precondition. Check the constraint field on those activities and you'll usually find an Expected Finish sitting there.