Timeline Generator

Timeline Generator

Purpose

Convert a dependency-tagged task list into a visual timeline with critical path analysis. Identify which tasks must complete on time for the matter to close as planned. Model delays before they happen — or calculate their programme-level impact after they do.

The what-if cascade is the central capability. When a jurisdiction delays, a regulatory determination runs long, or a counterparty goes quiet, the question is not just "is this task late" but "which of the twenty-three things downstream of this task now move, by how much, and what does the client need to know?" This skill produces that answer, along with the draft communications.

This skill consumes the structured output of matter-plan-builder and feeds its results back as updated milestone dates to status-report-drafter and scope-change-controller. It sits at the technical centre of the LPM plugin: every other skill produces or consumes timeline data; this skill owns the calculation layer.

---

Operating Modes

Mode 1 — Baseline build

At matter setup: build the dependency network from the matter plan, calculate the critical path and near-critical paths, produce the Gantt diagram and dependency summary. This is the timing baseline all future reporting measures against.

Input: matter-plan-builder structured export (CSV) or pasted task table with dependency tags. Minimum viable input: Task ID, Duration (working days), Predecessor(s), Dependency type (FS/FF/SS), and at least one fixed date anchor.

Forward-scheduling vs back-scheduling: If a programme start date is known but no fixed end date exists, schedule forward — calculate EF from ES. If a client completion deadline is fixed (the more common scenario in legal work), back-schedule — treat the completion date as the LF of the final task and work backward through the network to derive the required start date for each task. Flag which mode is in use and why. A back-scheduled plan immediately reveals whether the available time is sufficient: if the calculated start date for the first task is in the past, the programme is already in deficit before it begins.

Mode 2 — What-if analysis

At any point during the matter: propose a change and receive a full cascade impact analysis. "German counsel now says 12 weeks, not 10" → this skill calculates which tasks move, which milestones slip, whether the critical path changes, and what the new programme completion date is. Produces a draft client notification and affected local counsel communications.

Input: existing baseline (uploaded or pasted) + proposed change described in plain language or as extracted from email.

Mode 3 — Baseline update

Apply a confirmed change: update the timeline, version it, produce a comparison table (original dates vs revised dates for all affected tasks), and trigger cross-skill handoffs to status-report-drafter and scope-change-controller.

Input: existing baseline + confirmed change. Output: versioned updated baseline, comparison table, handoff prompts.

Mode 4 — Workstream or jurisdiction view

Produce a filtered Gantt and timeline summary for a single workstream or jurisdiction, drawn from the full programme baseline. Use when local counsel needs their timeline without the full programme, when a partner asks for a single workstream update, or when preparing a communication for one team that should not expose programme-wide information.

Input: full baseline (or the relevant subset) + the workstream or jurisdiction to filter on.

Three categories of task appear in a Mode 4 output:

1. In-scope tasks — tasks belonging to the specified workstream or jurisdiction. Shown as normal coloured bars (critical path red, non-critical green). Float values inherited from the full network — not recalculated on the subset.

1. Upstream constraints — tasks in other workstreams that are hard predecessors to in-scope tasks. Shown as grey bars labelled "[External — constrains [Task ID]]." The recipient needs to see these to understand why their tasks have the dates they do, but should not be misled into thinking these are their responsibility.

1. Downstream milestones — programme milestones that in-scope tasks feed into. Shown as milestone diamonds labelled "[Programme milestone — [description]]." These give the recipient visibility of what their work is gating without exposing the full downstream network.

Float must be inherited from the full network calculation, not recalculated on the subset. A Germany registration task with 0 days float in the full programme has 0 days float in the Germany view. If float were recalculated on the Germany subset alone, tasks that are critical in the full network would appear to have float — which would be wrong and potentially dangerous. Always calculate against the full baseline first, then filter.

---

Before Starting Any Mode

Confirm the following before running any calculation:

1. Programme start date — the date from which durations are calculated. If not provided, ask.
2. Fixed external dates — any dates that cannot move: regulatory filing deadlines, contractual completion dates, court dates, end-of-financial-year dates, client board approval windows. These are constraints, not estimates. Flag them explicitly — a fixed date on the critical path changes the calculation entirely.
3. Duration units — confirm whether durations are working days (Mon-Fri, default) or calendar days. Never infer.
4. Working calendar exceptions — flag any jurisdictions with non-standard working weeks (e.g. Middle East Friday-Saturday weekends, public holiday-heavy periods). Duration estimates that don't account for local calendars are wrong from day one.
5. Lag/lead values — where a predecessor has a waiting period before the successor can start (lag: positive days) or where the successor can start before the predecessor finishes (lead: negative days). Common in legal work: "regulatory filing submitted → 6-week determination window before successor can proceed" is a 30-working-day lag on a FS dependency.

Regulatory lags require clarification and three-scenario modelling: when a lag represents an external determination window, confirm whether it is (a) a hard minimum — the authority cannot determine before this period regardless of circumstances, or (b) an expected duration — the typical determination period, which could be shorter or longer.

For expected durations, produce three scenarios as a named output — do not just note the risk in prose:

• Best case: minimum credible determination period
• Expected: the stated duration
• +50%: expected duration × 1.5

Show the programme completion date under each scenario. This is the analysis the LPM needs to have the client conversation about deadline risk before the window opens. If the LPM cannot confirm which type the lag is, model as expected duration, produce all three scenarios, and flag the assumption explicitly.

If critical inputs are missing, stop and ask. Do not calculate against an incomplete network — the output will appear precise while being wrong.

---

Step-by-Step Process

Step 1: Build the dependency network

List all tasks in topological order — predecessors always appear before successors. Identify:

• Network start tasks: tasks with no predecessors (or no in-scope predecessors)
• Network end tasks: tasks with no successors — the milestone or task whose completion date is the programme completion date
• Dependency edges: for each task, record its predecessor(s) and dependency type (FS/FF/SS) plus any lag/lead value

Lag convention: lag counts forward from the working day after predecessor EF. FS lag 5 WD from EF Wednesday 7 May → successor ES = Wednesday 14 May (8, 9, 12, 13, 14 = 5 WD). Day zero is the day after EF, not EF itself. Apply this consistently — a one-day error in lag convention propagates to every downstream task on the same path.

Flag circular dependencies immediately — they are data errors and prevent calculation. A circular dependency means Task A depends on Task B and Task B depends on Task A. They appear most often when a task's predecessors have been entered as successors by mistake.

If the input contains resource or information dependencies (from matter-plan-builder's dependency register) that do not have their own task row, add them as explicit lag values on the FS relationship — do not silently omit them.

Step 2: Forward pass — calculate Early Start and Early Finish

Work through tasks in topological order. For each task, calculate:

• ES (Early Start): the earliest date the task can begin, given its predecessors
• EF (Early Finish): ES + Duration (in working days, adjusted for weekends and flagged calendar exceptions)

By dependency type:

• FF (Finish-to-Finish): Successor EF ≥ Predecessor EF + lag. The successor cannot finish until the predecessor finishes. Both tasks run in parallel; the constraint controls the finish end, not the start. This is the dominant dependency type in multi-jurisdiction execution work — two parallel workstreams converging at a controlled sequence point. Example: dividend resolution completes Monday; share transfer must complete by Thursday. Both run in parallel throughout; the FF+3d lag controls when the transfer can close. If dividend resolution slips, share transfer slips by the same amount — even though both started simultaneously.
• FS (Finish-to-Start): Successor ES = Predecessor EF + lag. The successor cannot start until the predecessor finishes. This is the dependency type for hard legal sequencing requirements — Germany entity registration must complete before Netherlands dissolution can begin; there is no parallel execution possible. Also used with lag for regulatory windows: filing submitted → [30 WD lag] → determination received → successor starts.
• SS (Start-to-Start): Successor ES ≥ Predecessor ES + lag. The successor cannot start until the predecessor starts. Used when two workstreams must launch in coordinated sequence but can then proceed independently.

When a task has multiple predecessors, its ES is determined by the latest-finishing predecessor (for FS/SS) or the most constraining relationship across all dependency types. Apply each predecessor constraint independently and take the maximum.

Show the forward pass calculation for the critical path tasks and for any task where the constraint is non-obvious. Transparency builds trust in the output — do not present dates without showing how they were derived.

Step 3: Backward pass — calculate Late Start and Late Finish

Work backwards from the programme end date. The end date is either a fixed constraint (if one was identified in the setup check) or the EF of the last task in the network.

For each task, calculate:

• LF (Late Finish): the latest date the task can finish without delaying the programme
• LS (Late Start): LF - Duration

By dependency type (backward pass):

• FF: Predecessor LF = min(Successor LF - lag) across all successors
• FS: Predecessor LF = min(Successor LS - lag) across all successors
• SS: Predecessor LS = min(Successor LS - lag) across all successors

When a task feeds multiple successors, its LF is constrained by the earliest-requiring successor. Take the minimum.

Step 4: Calculate float and identify the critical path

For each task:

Total float = LS − ES = LF − EF

Float is the amount of schedule flexibility a task has. A task with 10 days of float can slip by up to 10 days without delaying the programme completion date — assuming none of its successors have already consumed that float.

Zero float = critical path. The task must complete on its earliest finish date to avoid delaying the programme. Zero float does not mean the task is late — it means it has no buffer.

Negative float = already late. The task cannot complete by its latest finish date even if started at its earliest start. This occurs when a fixed deadline constraint is tighter than the network allows. Negative float is a programme-level problem requiring immediate escalation — it cannot be resolved by better scheduling. Flag every task with negative float, name the constraint causing it, and quantify the gap. "T04 has -8 days float: the programme requires completion by 30 June, but the network produces EF of 12 July. An 8-working-day compression is required on the critical path."

All tasks on the critical path is a valid and expected result on small linear matters with no parallel paths. It means there is no float anywhere in the network — every task must complete on time. Note this explicitly: "All tasks sit on the critical path. The network has no parallel paths that could provide float. There is no scheduling flexibility in this plan."

Near-critical path: tasks with float ≤ the near-critical threshold. Default threshold: 5 working days. The threshold is configurable — a fast-moving matter may use 3 days; a long-running programme may use 10. Ask the LPM to confirm or accept the default before producing the near-critical report. Express as: "The following tasks have float within [threshold] working days of the critical path and warrant active monitoring: [list with float values]."

If the critical path passes through a task whose duration is an information dependency (regulatory determination, counterparty response), flag this explicitly: "Programme completion is contingent on [external event]. The LPM has no control over this duration. Build contingency planning around the minimum/expected/maximum range."

Step 5: Produce the baseline output

See Output Format section. Produce in order: Gantt diagram, critical path narrative, near-critical tasks table, dependency summary, open calculation assumptions.

Step 6: What-if cascade (Mode 2 only)

See What-If Cascade Protocol section.

Step 7: Update and version (Mode 3 only)

Apply the confirmed change to the baseline. Increment the version number. Produce the comparison table. Trigger cross-skill handoffs.

Step 8: Produce workstream or jurisdiction view (Mode 4 only)

1. Run the full network calculation (Steps 1–4) against the complete baseline first. Float values must come from this full calculation.
2. Identify the filter: which workstream or jurisdiction has been requested?
3. Classify every task as: in-scope / upstream constraint / downstream milestone (see Mode 4 definitions above).
4. Produce the filtered Gantt showing all three categories with distinct visual treatment.
5. Produce a plain-language summary for the recipient: "Your workstream has [X] tasks. The earliest you can start [Task Y] is [Date] — this is gated by [upstream constraint task]. Your work feeds into [programme milestone] on [Date]. Your tasks have [Z] days of float in the full programme."
6. Note explicitly what is not shown: "This view covers the [Germany] workstream only. [X] other workstreams are running in parallel and are not shown here."

---

Critical Path Methodology — Key Concepts

Why the critical path matters in legal work: The critical path is not a scheduling curiosity — it is the answer to "what do I actually have to manage?" Every matter has tasks that can slip without consequence and tasks that, if they slip one day, slip the programme one day. Experienced LPMs develop intuitive critical path knowledge. This skill makes it explicit, which serves two purposes: it survives the LPM's departure, and it produces defensible programme impact assessments when delays need to be communicated to clients.

Effort vs duration: Duration is the elapsed time to complete a task. Effort is the person-hours applied. They diverge whenever waiting is involved. A two-hour partner review that sits in an inbox for three days before being done has three days duration and two hours effort. In legal work, the waiting periods are frequently longer than the work periods — review cycles, approv

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: legalopsconsulting
• Source: legalopsconsulting/lpm-skills
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.