Semantic project planning · a trial in changing the work
When the work changes
Two tunnel units share a gantry. Refine a task, change the packages, or release one unit early. Do the work breakdown and its dependencies still agree?
The existing Solway model generates the required work. Here we test what survives when that work is reorganised.
Already partway through? Try carrying completed work and evidence into a changed plan ↓
Scope
Who owns the work?
Each action appears once. Select one to find it in the network.
Order
What must come first?
Small boundary nodes mark package starts and finishes. Arrows mean precedence, not elapsed time.
Scroll the network sideways to follow its branches.
The boundary matters
Which completion does the next crew need?
Inspect the connections and checks
Pruning simplifies the drawing. The source connections and their reasons stay in the model; a later edit rebuilds both views.
Continuing the same enquiry · after work has happened
What can we still count as done?
Changing the plan does not undo work already done. It can change what that work is evidence for.
Both tunnel units are installed, but only A has been inspected. The shared gantry is still up. Change the plan and see which claims survive, what remains unknown, and what work is still needed.
This advances Solway’s aim of explaining necessary work: preserve justified progress when the work description changes. The history, evidence and revision rules below are supplied toy inputs.
Claims against the current brief
Work still needed
Orders are conditional on successful checks. An unavailable record does not mean the physical work failed.
Compare with an ordinary change table
This separately authored table reaches the same decisions without an ontology. Agreement checks the construction; it does not establish that the ontology is better.
| Claim | Old record | Current support | Decision | Remaining work |
|---|
Inspect the records, planning comparison and limits
Current facts and retained records
Historical occurrences remain addressable. Current facts come from their effects; evidence records also name a subject, criterion version and source occurrence.
Independently authored revised PDDL
The planning comparison starts after the recorded history, with the current acceptance requirements. It does not merely replay a new plan against the old goal. Missing evidence predicates mean “not currently established”, not physical failure.
Where the distinctions come from
Digital Construction Entities 0.5 distinguishes processes and equipment. Digital Construction Information 0.5 distinguishes information content from the physical work. Fox and Long’s PDDL background supplies the initial-state, action and goal framework. Our evidence applicability and carry-forward rules are local constructions, visible in the small RDF model; the compiler interprets this declared vocabulary, rather than performing general OWL reasoning.
Four changes, one legal history before gantry clearance, and a supplied refinement-evidence control. No failed checks, rework, repeated setup, deterioration or disputed authority are modelled. Neither agreement between methods nor a retained acceptance record establishes engineering approval, human usefulness or an ability to discover missing real requirements. The earlier from-scratch trial above remains a separate calculation.
What this tries, and where the method comes from
Two views of one richer model
The work breakdown records ownership and containment. The dependency network records required order. Neither relationship substitutes for the other. Stable action identities, the grouping rule and the actual dependencies sit beneath both drawings.
David Pratten’s contribution: enclose each summary’s work with start and finish milestones, add dependencies, and prune connections already implied by other paths. His 2016 article, PMQu and later Rosella Model already develop and implement this approach. This trial independently implements the construction on Solway’s generated work.
What changes here
Changing the grouping preserves action identities and their order requirements. Refinement replaces installation A with two declared steps: position, then secure. The extra seal test is a supplied acceptance requirement; its necessity is not discovered from an ontology. Removing B reruns the existing goal-to-work model, retaining shared access for A.
The final comparison introduces a separate mobilisation action. It requires A’s acceptance, uses no gantry, and does not represent physical entry into the workface. In a trade grouping, waiting for the whole inspection package also waits for B. The extra ordering restriction is a modelling choice, not a requirement of the specific release. Rosella can represent the specific release: the problem is choosing too coarse a boundary.
What is checked
Each action has one owner. Package boundaries enclose their members. Removing implied connections preserves reachability. The model enumerates the permitted orders of these actions; the test suite replays their underlying Solway actions and compares the base work with its independent PDDL route. Counts are orders in a small finite model, not timed or resource-feasible schedules.
What agreement cannot establish
Two coherent views can both omit necessary work. Completion here means completion of the declared inspection and acceptance steps, not engineering certification. Durations, lags, calendars, crew capacity, failures and rework are outside this trial. An alternative path is sufficient for pruning only under these unweighted precedence assumptions.
The broader question—what a mapping preserves, forgets and needs in order to support change—connects to Functors for Projects. This trial uses ordinary graph operations; it does not claim a categorical equivalence between a bare WBS and a schedule.