Contact
Sequence

Impact & recovery

The compression assistant that ranks candidates without inventing a crash cost, fragnets as reusable delay templates, and impact records that capture the before, the after and the rows together.

Two related things live here: deciding what to shorten, and recording what a delay event did.

The compression assistant#

It lists candidate rows on the critical path with their duration, float, assigned resources and, where costing is on, what they cost. It ranks and proposes; it does not act — compressing a row means editing its duration, which is an ordinary edit a person makes.

Each candidate carries:

DurationWorking days, as the engine scheduled it
Total float
ResourcesNamed, so the list is actionable rather than a set of row ids
CostThe row's total, or nothing where it is unpriced
Daily costCost ÷ working days

What "cost to crash" is not#

⚠⚠ Sequence does not report a cost to crash, and the column is deliberately empty rather than filled with a plausible figure.

Crashing means shortening a row by adding resource, and what that costs depends on a duration triangle — how work, duration and units trade off, and which of the three is held. That is not built, so there is no answer to "what would two more people do to this duration".

What is reported instead is the row's daily cost rate, which is a fact derived from figures that exist. Inventing a crash cost would put a made-up number in front of somebody deciding what to compress, which is the one place a made-up number does real damage. The gap carries its reason rather than reading as a zero.

Fragnets#

A fragnet models a delay event as a small set of rows with logic. It is a template, not a one-off edit: its rows hold local ids and take real ones on insertion, so the same fragnet can be inserted twice — into two scenarios, or twice into one to model a delay recurring — and neither insertion knows about the other.

Insertion hangs the fragnet off a row you choose. A fragnet row with no predecessor of its own becomes a successor of the insertion point; one that names another fragnet row becomes a successor of that instead. So a two-row fragnet attached to Erect steel reads: Erect steel → row 1 → row 2, which is what modelling a delay event actually means.

⚠ A fragnet is inserted into a scenario, never into the live schedule. A delay event is a hypothesis until somebody accepts it, and merging the scenario is how it stops being one.

⚠ A link pointing at a row the fragnet does not contain is dropped, not retargeted at the insertion point. Retargeting would quietly change the fragnet's logic into something its author did not draw, and a delay event whose network is wrong produces an impact figure that is wrong in the direction nobody checks. The dropped links are reported.

Impact records#

An impact record captures the before, the after and the inserted rows together: which fragnet, into which scenario, which rows it minted, the project finish before and after, and the days it moved.

"Together" is the whole clause. A project finish that moved and a set of rows that appeared are two facts; the record is the claim that one caused the other, and it is worthless if either half can be read without the other.

⚠ A delta of zero has two very different meanings, and the record distinguishes them. A delay that absorbed entirely into float moved the finish by nothing — a genuinely interesting finding. A scenario the engine refused to schedule also produces nothing, and that is not a finding at all. When the second happened, the record says why.

Not built#

Windows analysis is not built. Target-date solving — asking the tool to find the compression that lands on a date — is an open question and probably should not exist: a schedule that has been solved backwards from a required date is one nobody can defend line by line.