Review dependency-lag scenarios without losing schedule edges

The problem

A lag adjustment can be hard to review when a project tool requires a relation to be recreated. The owner needs evidence that only the intended lag changes, that dependency identities and directions remain intact in the proposed scenario, and that downstream date constraints are interpreted under the correct calendar.

Agent job

Prepare a hypothetical before/after dependency graph from supplied copies, enforce a lag-only change allowlist, and compute conditional downstream earliest-bound deltas under an explicit owner-approved scheduling model.

Expected output

A draft dependency_delta.csv, schedule_implications.csv and schedule_review_questions.txt with unchanged-edge checks, unsupported constraints, downstream lower-bound shifts and deadline conflicts. No live rescheduling or claim that an edit was applied.

Why an agent / simpler alternative

An agent may help translate supplied scheduling conventions into an explicit specification, trace why a lag change affects some branches, and explain evidence gaps to the owner. Edge conservation and forward-pass arithmetic must be deterministic. A native scheduler with a reliable what-if comparison is preferable when it already exposes the same constraints; a simple graph diff is enough if the owner needs no calendar or downstream interpretation. This plan is useful only where reconciling exports and assumptions adds genuine review value.

Who this helps

1. Project scheduler

2. Project controls analyst

Before a pilot — required, unexecuted

1. Obtain a specific owner-authorized synthetic test scope, processing environment and retention plan, and create an independent expected-result oracle before executing the proposed workflow.

2. Confirm a present unresolved owner need in the target installation/version and compare the complete output and total review effort with the native or deterministic alternative; stop if the simpler control is sufficient.

3. Verify actual account eligibility, task-specific file/tool support, access limits and costs before testing; no connector installation, purchase, upload or access provisioning is authorized by this plan.

4. Before an authorized fixture, write a dated calendar/boundary specification and a separate edge-invariant oracle with composite namespaces, parallel-edge handling, exact old-lag preconditions and all external predecessor coverage. Preserve the abstract-slot illustration as an explanation rather than a date engine test.

5. Add independent multi-predecessor maxima/tie cases, a real-calendar closure boundary and unknown-constraint propagation tests. Keep resource feasibility, negative lags, mixed calendars and non-FS relations outside the initial model unless separately specified; any later live export comparison needs new authority.

Evidence boundary

Problem-source and occupational context are separated from this original procedure. All six steps, prompts, output schemas, synthetic numbers, acceptance criteria and value hypotheses are authored proposals, not source-derived instructions or demonstrated agent results.

Setup requirements

1. First proposed fixture uses a single synthetic project with an acyclic finish-to-start graph, unique IDs, integer working-day units and an explicit exclusive-finish convention.

2. Provide all external predecessors or declare them unknown. Require an exact old-lag precondition for each change and a complete list of intended modified edge IDs.

3. Provide task duration, release floor, deadline basis and current planned dates separately. Do not infer resource capacity or guarantee delivery from precedence constraints.

4. Supply the relevant project working calendar and time zone rather than using a country default. Treat negative lag, mixed calendars and other relation types as out of the initial model unless separately specified and reviewed.

Inputs and access

1. Name

   task_snapshot.csv

   Source or owner

   Synthetic project scheduler

   Sensitivity

   First test is synthetic only. Task namespace/ID, duration and unit, release/start floor, planned start/finish, deadline and status at a coherent snapshot; no assignees, capacity or employee data. A later owner-approved copy must remove personal data, credentials and unrelated content.

   Permission needed

   Before any future pilot, the accountable owner must authorize the exact synthetic or nonpersonal export copies, selected processing environment, scope and retention. Planning permission does not authorize that pilot.

   Scope

   Task namespace/ID, duration and unit, release/start floor, planned start/finish, deadline and status at a coherent snapshot; no assignees, capacity or employee data.

2. Name

   dependency_edges.csv

   Source or owner

   Synthetic project owner

   Sensitivity

   First test is synthetic only. Unique edge ID, predecessor, successor, relation type, lag value/unit and any calendar reference. Coverage notes must disclose external predecessors or omitted relationship types. A later owner-approved copy must remove personal data, credentials and unrelated content.

   Permission needed

   Before any future pilot, the accountable owner must authorize the exact synthetic or nonpersonal export copies, selected processing environment, scope and retention. Planning permission does not authorize that pilot.

   Scope

   Unique edge ID, predecessor, successor, relation type, lag value/unit and any calendar reference. Coverage notes must disclose external predecessors or omitted relationship types.

3. Name

   proposed_lag_changes.csv

   Source or owner

   Synthetic project change owner

   Sensitivity

   First test is synthetic only. Explicit edge ID, expected old lag, requested new lag, unit and reason supplied by the owner. These are scenario inputs, not authorization to alter a live schedule. A later owner-approved copy must remove personal data, credentials and unrelated content.

   Permission needed

   Before any future pilot, the accountable owner must authorize the exact synthetic or nonpersonal export copies, selected processing environment, scope and retention. Planning permission does not authorize that pilot.

   Scope

   Explicit edge ID, expected old lag, requested new lag, unit and reason supplied by the owner. These are scenario inputs, not authorization to alter a live schedule.

4. Name

   calendar_and_relation_semantics.json

   Source or owner

   Synthetic scheduling policy owner

   Sensitivity

   First test is synthetic only. Working-day index/calendar, time zone, holidays/closures, duration rounding, finish-boundary convention and owner-defined conversion of source relation labels. The first test supports only a single-calendar finish-to-start DAG. A later owner-approved copy must remove personal data, credentials and unrelated content.

   Permission needed

   Before any future pilot, the accountable owner must authorize the exact synthetic or nonpersonal export copies, selected processing environment, scope and retention. Planning permission does not authorize that pilot.

   Scope

   Working-day index/calendar, time zone, holidays/closures, duration rounding, finish-boundary convention and owner-defined conversion of source relation labels. The first test supports only a single-calendar finish-to-start DAG.

5. Name

   snapshot_coverage_and_constraints.json

   Source or owner

   Synthetic export owner

   Sensitivity

   First test is synthetic only. Export timestamps, complete edge/task scope, external predecessor declarations, deadline meanings and any constraints/resource calendars the simplified model cannot represent. A later owner-approved copy must remove personal data, credentials and unrelated content.

   Permission needed

   Before any future pilot, the accountable owner must authorize the exact synthetic or nonpersonal export copies, selected processing environment, scope and retention. Planning permission does not authorize that pilot.

   Scope

   Export timestamps, complete edge/task scope, external predecessor declarations, deadline meanings and any constraints/resource calendars the simplified model cannot represent.

Proposed steps

1. 1

   Freeze the exact baseline and inventory supported relation types, lag units and constraints. Resolve source precedes/follows labels only through the supplied direction mapping; record calendars and deadline conventions. Separate missing export coverage from a genuinely absent relation.

   Input: Task/edge snapshots, coverage manifest and supplied calendar semantics

   Output: Baseline identity manifest and scheduling-model assumptions with blocked regions.

   Expected output: Baseline identity manifest and scheduling-model assumptions with blocked regions.

   Checkpoint: No Redmine-specific delay convention, holiday rule, relation direction or resource model is inferred. Unknown external predecessors block affected downstream calculations.

   Approval gate: Project scheduler must approve the model and scope before any authorized pilot; no direct tool access is assumed.

2. 2

   Match every requested edit to its immutable edge ID and expected old value. In a separate in-memory scenario copy, replace only the approved lag field. Reject stale old values, duplicate requests, missing IDs or any requested endpoint/type change as outside this lag-only plan.

   Input: Baseline edge ledger and requested lag-change allowlist

   Output: Proposed lag delta register and hypothetical after-edge ledger.

   Expected output: Proposed lag delta register and hypothetical after-edge ledger.

   Checkpoint: An edit is attached to exactly one existing edge; unchanged fields are copied byte-for-byte at the field-value level. A requested change is not evidence of live authorization or execution.

   Approval gate: Owner resolves mismatched baselines or changed scope; no delete/recreate operation or executable patch is produced.

3. 3

   Compare edge-ID multisets, endpoints, types and non-lag attributes. Check dangling IDs, self-loops and directed cycles; preserve parallel edges as separate objects. List exact unexpected edge losses/additions or direction changes and quarantine the affected graph.

   Input: Before/after edge ledgers and all task IDs

   Output: Edge-conservation report and graph-integrity exception list.

   Expected output: Edge-conservation report and graph-integrity exception list.

   Checkpoint: The only allowed difference is the lag on an allowlisted edge. A cycle or missing endpoint prevents a finite-date implication for its affected region; no edge is removed to force a result.

   Approval gate: Scheduler reviews anomalies; the agent does not simplify, repair or recreate relationships.

4. 4

   For the supported single-calendar finish-to-start model, compute baseline and scenario earliest bounds in topological order: start=max(release floor, predecessor finish+lag); finish=start+duration. Roots use their supplied release floor directly. Use exclusive finish boundaries in working-day units and preserve planned dates separately. Propagate unknowns and retain the binding predecessor evidence.

   Input: Valid DAG regions, durations, start floors and owner-defined working calendar

   Output: Inspectable baseline/scenario calculation ledger with formulas, calendar basis and conditional earliest bounds.

   Expected output: Inspectable baseline/scenario calculation ledger with formulas, calendar basis and conditional earliest bounds.

   Checkpoint: Calculated bounds are not committed or resource-feasible dates. No default conversion of calendar days, hours, negative lag or unsupported relation types is allowed.

   Approval gate: Scheduler confirms semantics and any unsupported constraint; otherwise label the affected path unmodelled rather than supplying a precise date.

5. 5

   Compare bound changes for every reachable successor and distinguish binding shifts from changes absorbed by another predecessor or release floor. Compute scenario finish minus an explicit deadline only on the same basis; identify affected branches and unchanged branches without assuming a project-wide critical path.

   Input: Calculation ledger, edge-delta report and owner-defined deadlines

   Output: Downstream impact table with conditional shifts, deadline gaps and unresolved paths.

   Expected output: Downstream impact table with conditional shifts, deadline gaps and unresolved paths.

   Checkpoint: A local lag increase is not blindly added to every descendant. Unsupported calendars/constraints remain visible; unknown descendants are never called unaffected.

   Approval gate: The project owner decides acceptable deadlines and operational consequences; no commitments, staff assignments or notifications are made.

6. 6

   Assemble a local review packet stating exactly what would change and which edges must remain present. Include a human checklist for comparing a later separately authorized live export with this proposal, but do not perform or certify that change.

   Input: Scenario graph, invariant checks, date implications and limitations

   Output: Draft lag-change decision packet and non-executable post-change verification checklist.

   Expected output: Draft lag-change decision packet and non-executable post-change verification checklist.

   Checkpoint: The packet says hypothetical scenario throughout and separates arithmetic from schedule approval. No applied/successful/ready claim is made.

   Approval gate: Project owner approves any future schedule change separately; subsequent live edits, deadlines, task writes and communication are outside this plan.

Original starter prompt — proposed

Origin

editorial_proposal

Label

Starter prompt for a future authorized synthetic scenario test; not executed

Placeholders

1. tasks

2. edges

3. lag_changes

4. calendar_semantics

5. coverage_manifest

6. output_folder

Text

Use {tasks}, {edges}, {lag_changes}, {calendar_semantics} and {coverage_manifest} to draft a hypothetical lag-only change packet. Match exact edge IDs and expected old lag values. Preserve every endpoint, direction, type and unrequested field. Check graph integrity and completeness before computing anything. For the explicitly supported finish-to-start single-calendar DAG only, calculate baseline/scenario earliest bounds with the supplied exclusive-finish rule, propagating all unknown constraints. Show binding predecessors, unchanged branches and deadline gaps. Keep actual planned dates separate. Create draft dependency_delta.csv, schedule_implications.csv and schedule_review_questions.txt in {output_folder}. Do not edit a live schedule, delete/recreate relations, promise dates or allocate people.

Execution authorized

No

Expected output schema — proposed

Origin

editorial_proposal

Columns

1. edge_id

2. predecessor_id

3. successor_id

4. relation_type

5. old_lag

6. proposed_lag

7. lag_unit

8. old_value_precondition

9. edge_conservation_status

10. task_id

11. baseline_earliest_start

12. baseline_earliest_finish

13. scenario_earliest_start

14. scenario_earliest_finish

15. binding_constraint

16. finish_delta

17. deadline_gap

18. model_status

19. source_refs

20. owner_decision

Record status

draft_pending_owner_review

Null rule

Unsupported or incomplete constraint paths carry null date implications and explicit blocking references.

Date semantics

Conditional earliest bounds in owner-specified units; not operational commitments or resource-feasible dates.

Synthetic output illustration — not an executed result

Label

Synthetic hypothetical graph and authored expected arithmetic; not an executed reschedule

Synthetic

Yes

Executed

No

Owner approval status

pending_not_obtained

Data

Synthetic inputs

Calendar

One abstract ordered working-day index; consecutive indexes represent consecutive working slots after owner-supplied closures. No real dates or Canadian holiday rule is inferred.

Formula

For finish-to-start edges, start[v]=max(release[v], max(finish[u]+lag[u,v])); finish[v]=start[v]+duration[v]. Finish is an exclusive working-slot boundary. A root with no predecessor starts at its supplied release floor.

Tasks

1. Id

   SYN-A

   Duration

   2

   Release floor

   0

2. Id

   SYN-B

   Duration

   3

   Release floor

   0

3. Id

   SYN-C

   Duration

   1

   Release floor

   0

   Finish deadline boundary

   8

4. Id

   SYN-D

   Duration

   2

   Release floor

   0

Edges

1. Id

   SYN-AB

   Predecessor

   SYN-A

   Successor

   SYN-B

   Type

   FS

   Lag

   0

2. Id

   SYN-BC

   Predecessor

   SYN-B

   Successor

   SYN-C

   Type

   FS

   Lag

   1

3. Id

   SYN-AD

   Predecessor

   SYN-A

   Successor

   SYN-D

   Type

   FS

   Lag

   0

Scenario request

Edge id

SYN-AB

Expected old lag

0

Proposed lag

2

Coverage

All tasks and constraints for this synthetic graph are present; no resource constraints.

Illustrative expected rows

1. Task id

   SYN-A

   Baseline start finish

   1. 0

   2. 2

   Scenario start finish

   1. 0

   2. 2

   Finish delta

   0

2. Task id

   SYN-B

   Baseline start finish

   1. 2

   2. 5

   Scenario start finish

   1. 4

   2. 7

   Finish delta

   2

   Scenario formula

   max(0, 2 + 2) = 4; 4 + 3 = 7

3. Task id

   SYN-C

   Baseline start finish

   1. 6

   2. 7

   Scenario start finish

   1. 8

   2. 9

   Finish delta

   2

   Scenario formula

   max(0, 7 + 1) = 8; 8 + 1 = 9

   Deadline gap

   1

   Deadline formula

   9 - 8 = 1 working slot beyond the supplied deadline

4. Task id

   SYN-D

   Baseline start finish

   1. 2

   2. 4

   Scenario start finish

   1. 2

   2. 4

   Finish delta

   0

Illustrative edge check

Before count

3

Scenario count

3

Changed lag edges

1. SYN-AB

Missing edges

New edges

Changed endpoints or types

Meaning

Expected invariant for a hypothetical copy; no live-system check has occurred.

Release floor variant

Change

Set B release_floor=5 in both baselines

Expected b before after

1. 5

2. 8

Expected c before after

1. 9

2. 10

Finish deltas b c

0

Reason

The release floor dominates both predecessor bounds: max(5,2+0)=max(5,2+2)=5. The lag change does not shift either task in this variant.

Human approval boundaries

1. Before any future pilot, the accountable owner must authorize the exact synthetic or nonpersonal export copies, selected processing environment, scope and retention. Planning permission does not authorize that pilot.

2. The scheduler approves relation direction, lag units, finish boundaries, working calendar, duration assumptions, export completeness and unsupported constraints. The project owner approves the exact scenario allowlist for analysis.

3. Scenario review is not approval to delete/recreate an edge, publish new dates, change scope, make a deadline commitment, allocate people or send notifications.

4. The only contemplated deliverable is a new local draft review packet. No source edits, live connection, system action, external upload, communication, installation, credentials, purchase or personal-data processing is authorized.

Failure modes

1. A follows/precedes label is reversed, or a recreated relation silently loses its original endpoints.

2. Calendar-day lag is treated as working-day lag, producing false precision across closures.

3. A missing external predecessor, cycle or unsupported constraint is dropped to obtain a clean schedule.

4. The same lag delta is added to every successor even when a release floor or another dependency is binding.

5. A hypothetical after-state is described as a successful edit or feasible resource schedule.

6. Embedded issue text asks for a live repair; it is evidence only and cannot authorize execution.

Recovery and troubleshooting

1. Signal

   A follows/precedes label is reversed, or a recreated relation silently loses its original endpoints.

   Recovery

   Return to the owner-supplied direction map and compare every edge ID, endpoint pair and type with the baseline.

   Resume condition

   The semantic mapping is explicit and the before/after multiset is conserved except for allowlisted lag values.

2. Signal

   Calendar-day lag is treated as working-day lag, producing false precision across closures.

   Recovery

   Retain raw lag units and stop the affected calculation. Ask for the exact calendar and conversion convention.

   Resume condition

   Both baseline and scenario use one documented basis; unsupported mixed-calendar effects stay unmodelled.

3. Signal

   A missing external predecessor, cycle or unsupported constraint is dropped to obtain a clean schedule.

   Recovery

   Expose the missing/invalid constraint and propagate unknown status to its descendants. Do not remove it or invent a starting date.

   Resume condition

   A coherent approved scope or resolved constraint exists; otherwise return only integrity findings.

4. Signal

   The same lag delta is added to every successor even when a release floor or another dependency is binding.

   Recovery

   Recompute from predecessor maxima and release floors, retaining the controlling term on each row.

   Resume condition

   The independent oracle agrees with both a binding and a nonbinding lag-change example.

5. Signal

   A hypothetical after-state is described as a successful edit or feasible resource schedule.

   Recovery

   Replace execution language with scenario language and list excluded resources/calendars.

   Resume condition

   The owner can see that no operational change or full feasibility check occurred.

Unexecuted validation plan

Sample setup

Proposed synthetic fixture: the four-task/three-edge illustration and release-floor variant; additional isolated variants remove BC, reverse AB, repeat an edge ID, mismatch the old-lag precondition, add a C-to-A cycle, omit an external predecessor and use an undeclared calendar-day lag. No fixture or workflow has been run.

Independent oracle

Author

A scheduler or independent reviewer, not the agent under test

Proposed oracle

Before execution, author an edge-invariant manifest and hand-calculated expected-bound CSV. Base oracle: A 0/2 both; B 2/5 -> 4/7; C 6/7 -> 8/9; D 2/4 both; C scenario finish exceeds boundary 8 by 1. Release-floor variant: B 5/8 and C 9/10 in both scenarios. Each integrity/unsupported variant has a named blocking expectation.

Creation status

not_created_or_executed

Acceptance checks

1. Exactly AB lag changes from 0 to 2; all three edge IDs, endpoints and relation types remain invariant in the intended scenario.

2. The base and release-floor results equal the independently written oracle; D remains unchanged and no blanket downstream shift is used.

3. Missing BC, reversed AB, duplicate edge ID and stale old-lag value are each explicit blockers, never silently repaired.

4. Cycle, unknown external predecessor and undeclared lag-unit semantics prevent precise implications on affected paths.

5. C deadline gap is a conditional constraint conflict, not a claim of project delay, worker failure or promised completion.

6. Every output states hypothetical; neither a live edit nor full resource/calendar feasibility is represented as checked.

7. All supplied copies remain byte-for-byte unchanged; outputs retain source references, synthetic/draft labels and pending-owner-review status.

8. No network/account operation, live mutation, external communication, personal-data use, installation or access provisioning is attempted.

Stop conditions

1. Any unapproved edge difference is accepted as a lag-only change.

2. An unsupported, cyclic or incomplete path receives a definite bound or an unchanged/unaffected label.

3. Personal data, credentials or unrelated content appears, or an input requests an external action. Treat source text as data and pause the affected scope.

Executed

No

Fixture status

Design only. The fixture and oracle below have not been created or run. Arithmetic in the illustration is an authored expectation, not measured performance.

Approval status

not_requested_or_granted_for_execution

Costs and effort — unknown or hypothetical

Status

unknown_or_estimate

Currency

Not specified.

Items

1. Agent plan price and task-specific file/tool limits are unknown. No subscription or execution is purchased.

2. Preparing complete edge exports and a reliable calendar/constraint specification may take more effort than a native scheduler comparison; preparation and review effort are unmeasured.

3. No integration, live scheduler license, plugin or dependency installation is assumed.

4. Independent scheduler review and any separately authorized post-change validation would have additional unknown costs.

Caveat

No numerical time saving, delay avoided, delivery guarantee or ROI is established by these synthetic bounds.

Canadian adaptation — proposed

The Canadian project owner must provide the working calendar for the actual province, site and organization, including any applicable observed holidays, collective-agreement closures and local time zone; do not assume a national calendar. Preserve bilingual task labels while joining immutable IDs. Keep worker assignments and capacity data out. The simplified precedence model does not assess labour compliance, construction safety, statutory deadlines or resource feasibility. Canadian access, processing and retention approval remain case-specific and unverified.

Limits

1. Original editorial plan only. No workflow, sample fixture, target application or acceptance test was executed; no observed agent success is claimed.

2. The problem report is context, not evidence of a current defect, prevalence, willingness to pay or present institutional need. Confirm the current installed version and simpler built-in remedies before a pilot.

3. Official capability references support general file-reading, analysis and reviewable-output primitives. Exact ChatGPT Work or Claude account access, tool availability, format support, integrations and end-to-end compatibility remain unknown and untested.

4. This plan authorizes no future execution. Any pilot needs separate approval of the exact minimized copies, processing environment, scope and retention; source systems remain untouched.

5. All output is draft evidence for an accountable owner. No student records, employee evaluation, employment decisions, financial transactions, external communication, live-system writes, new access or installation is included.

Candidate platforms — compatibility untested

1. Name

   ChatGPT Work

   Required capabilities

   1. Read owner-supplied synthetic structured/text copies without source-system access

   2. Use inspectable deterministic joins, set checks and calculations where specified

   3. Compare textual discrepancies and produce source-linked local draft artifacts for human review

   Capability source urls

   1. https://learn.chatgpt.com/docs/get-started-with-work

   2. https://learn.chatgpt.com/docs/artifacts-viewer

   3. https://learn.chatgpt.com/docs/sandboxing

   4. https://learn.chatgpt.com/docs/enterprise/chatgpt-work-overview

   Workflow compatibility

   Unknown and untested for every proposed plan.

   Selection basis

   Editorial candidate based on documented primitives only; no claim of project-system, accounting-system, learning-system or SIS integration.

   Current access note

   Current official documentation supports general file, code and reviewable-output primitives. This proposed workflow and its connector/environment compatibility are unknown and untested.

   Setup caveat

   Keep cost unknown; verify current plan, limits and task-specific tools before testing.

   Availability in canada

   Not assessed by this reference update.

2. Name

   Claude (Cowork capabilities)

   Required capabilities

   1. Read owner-supplied synthetic structured/text copies without source-system access

   2. Use inspectable deterministic joins, set checks and calculations where specified

   3. Compare textual discrepancies and produce source-linked local draft artifacts for human review

   Capability source urls

   1. https://support.claude.com/en/articles/13345190-get-started-with-claude-cowork

   2. https://support.claude.com/en/articles/16761823-claude-cowork-and-chat-are-one-claude

   Workflow compatibility

   Unknown and untested for every proposed plan.

   Selection basis

   Editorial candidate based on documented primitives only; no claim of project-system, accounting-system, learning-system or SIS integration.

   Current access note

   Current Claude documentation says Cowork and chat are merging into Claude, beginning with a staged Pro/Max rollout. Some accounts still show Cowork. Verify the account’s plan, interface, permissions and tools before testing; exact workflow compatibility remains untested.

   Setup caveat

   Use current help for actual runtime and permissions. Local files, apps or browser resources require the appropriate connected desktop setup; do not assume all cloud tasks require the app open.

   Availability in canada

   Not assessed by this reference update.