Graph-change workbench · Project states & relationships

JavaScript is needed for the interactive examples

The graph calculations and controls require JavaScript. The static preservation, assumptions and source record and Graphviz sample input remain readable.

Move a handoff. Follow the consequence.

Select a task or dependency in the graph or selectors. Apply a local start delay or edge lag, then compare with the untouched baseline.

View

Graph labelsScalar rule (schedule always uses max)Animate changed task dates

Scalar values ignore durations and lags. Sum can count a shared cause more than once; mean can dilute it. Neither is a finish-to-start schedule.

Task delay

Selected taskLocal start delay: 0 days

Added after all incoming constraints. This is an additional waiting period, not a fixed calendar release date.

Dependency lag

Selected dependency

Lag change: 0 days

Negative lag allows overlap in this toy model. Start dates have a floor of day zero. No calendars or shared-resource limits are applied.

Baseline finish

Current finish

Largest positive finish shift

Drag a task to rearrange the view. Click a task or arrow to select it.

Green ≤3 days · amber >3–10 days · rose >10 days of positive finish shift. These are illustrative bands, not assessed risk. Blue outline = selected.

Actual date calculation

ES(v) = max(0, EF(u) + lag(u,v)) + localDelay(v)
EF(v) = ES(v) + duration(v)

Take the maximum over all predecessors u. The graph is recalculated in full; the animation highlights changed dates in dependency order. “Finish shift” compares against the original zero-lag, zero-delay baseline.

Task	Tier	Duration	Baseline finish	Start	Finish	Finish shift

Change trace

Session explanation, newest entry first. This is not a signature, approval or replayable event ledger.

Change a representation. Inspect its losses.

Import a graph, focus on an output, or introduce an explicit handoff. Every committed transformation keeps a snapshot for undo. Grouping changes only the displayed view.

Input graph

Graph JSON

Choose a JSON file

Or drop a JSON file here. Loading fills the editor; Parse commits it.

nodes: id, label, duration, tags, owner, type, date.
edges: id, source, target, lag, duration.
Task duration belongs on a node; edge duration is an additional transfer time. Do not enter the same duration in both.

Filter from baseline

Exact typeTag containsExact owner

From date

Through date

Induced subgraph: unmatched nodes and their edges disappear. An earlier date in this reduced graph does not establish an earlier finish for the full project.

Group the current view

GroupingExact tag to group

Membership and every boundary edge stay inspectable. Internal edges are hidden in this overview; durations are not added together. Timing and exports still use the ungrouped current graph.

Keep upstream dependencies

Output tag or type (comma-separated)Output IDs (comma-separated)

Follow incoming edges back from the outputs. This preserves their encoded upstream paths. It says nothing about omitted resource, cost or contractual coupling.

Make interfaces explicit

Lane attributeInterface tag priorityFallback typeShare one interface per lane pair and type

Default: one interface per edge; all original weight stays on the first leg and the second has weight zero. Shared interfaces intentionally couple paths: they can add dependencies or create cycles. The checks show this.

ScopeContractPermitPower

These colours distinguish interface types, not assessed risk.

Inspectable failure cases

Each loads the editor. Parse it, then insert interfaces and inspect the checks.

Current graph

Current graph; one longest path highlighted

What the last transformation preserved

Checks compare retained original nodes. A check can establish only these graph properties; it does not validate the project’s interpretation.

View and model

Current nodes and dependencies as tables

Before & after

Before always shows the imported baseline. Transformation checks above compare the immediately preceding model with the result.

Before JSON

After JSON

Snapshot history

Undo restores saved graph data. Filtering and pruning discard information in the result; they are not invertible functions. History lasts only in this browser tab.

Export current graph

JSON can be imported here again. CSV and DOT are generic exchange formats, not certified vendor imports. CSV preserves isolated nodes in a separate node file. Treat imported labels as text if using a spreadsheet.

Export preview (select to copy manually)

A source → construction → limitation route

The original living graph-transform demo combined scheduling, transformations, formal aspirations and offer matching. This version keeps those strands accessible and makes their distinct meanings visible.

Read the transformations

A ──3──▶ B
becomes
A ──3──▶ I ──0──▶ B

Subdivision: the new zero-duration interface makes the handoff explicit. In the default per-edge mode, original-node reachability and weighted paths are preserved. The comparison panel checks this on your current data.

Shared interface: A→I→B and C→I→D also permit A→D and C→B. Sharing a drawn junction can change the model. A group box that merely contains separate channels is a different construction.

Upstream pruning: if the only question is the selected outputs’ encoded prerequisites, retain their ancestors. This is a scoped view, not a declaration that the discarded work is irrelevant.

Three original Graphviz examples

Six sample files remain available below. The comments in the maintained expected outputs identify their scope. These are reference examples, not a “three tests passing” badge.

Pruning input → expected upstream view: retain A→B→C→T; discard branches that cannot reach T.
Interface input → expected edge subdivision: Eng→Ops and Ops→Finance gain separate interface nodes. This does not demonstrate a fibration or reduced coordination work.
Mean/variance input → illustrative mean-path annotation: A→B→D→T has mean sum 7; A→C→D→T has mean sum 6. The file highlights the longer mean path.

Variance boundary: summing means is not computing the probability that a path finishes last. Means and variances alone do not determine the joint duration distribution. Shared tasks, covariance and distributional assumptions matter. No probabilistic critical path is computed here.

Formal questions, visibly bounded

A DAG can encode precedence. Mapping tasks to owner lanes is a grouping. Calling that grouping a fibration would require a specified category, projection and cartesian lifting property; no such construction is provided by this workbench.

The ordinary dependency calculation can serve as a comparison for Milestones under changing constraints. For a typed process-composition example, see Building a Wall. These are related enquiries with their own assumptions.

A model operation is not automatically a proof object. Snapshot history supports recovery; provenance needs recorded inputs, operation and result. Signed approvals and semantic correctness require additional evidence.

Original explanation strands, corrected

Open any short note. Each distinguishes the executable workbench from the original design aspiration.

Source and preserved intent

The source is Living Graph-Transform Rescheduler, fixed source revision 7888f8a. Its useful aim was to show local changes and their effects, inspect graph transformations, and explain change history. The historical design note and sample-checking note proposed more than the implementation supplied.

This maintained construction uses ordinary DAG arithmetic, ancestor traversal, a separate grouped view, edge subdivision, snapshot history and greedy offer matching. The original seven tasks, five-node sample and three matching presets remain. Unsupported claims about reversibility, signatures, probabilistic paths, vendor compatibility and fibrations are corrected.

Questions worth retaining concern what a representation preserves, when a boundary hides a dependency, what evidence makes a change explainable, and which extra semantics real work needs. They are questions, not a prescribed research programme or evidence of real project benefit. Preservation and limits record.

Can an offer meet another task’s window?

The three original scenarios remain as a small matching experiment. An offer is used once; positive time-window overlap permits a match. Matches can reveal a shortfall, but they do not establish a feasible resource schedule.

Example

Original presetMatching policyTasks & annotated resources JSON

Read before interpreting

Capacity and calendar fields are retained source annotations, not enforced constraints. “weekdays” and “shift” have no dated calendar here. This matcher can match a resource with capacity zero: that demonstrates its limitation, not feasibility.

Strict preserves both window endpoints. Liberal expands each side by buffer. Priority processes low-buffer tasks first and expands each side by floor(buffer/2). The reported delta is window width, not schedule float.

Offers are independent tokens available by assertion; the model does not first execute a provider or require its own needs to be met. Reciprocal matches can therefore conceal a real dependency deadlock.

Policy comparison

Arrow: provider → receiving task. Labels identify the offered item.

Structured result

Run the comparison to inspect the result.

The downloaded comparison includes the exact input, strict result and selected-policy result. It is an unsigned snapshot, not a governance receipt or P6 constraint import.

Generic matching CSV