Work can be generated.
With explicit initial facts, final obligations and permissible actions, search produces a route without being given a project task list. Shared setup and eventual removal arise through those rules.
An essay in constructing project work
The work that
must exist.
A finished tunnel contains its equipment. It contains none of the temporary access that made installation possible.
Can the outcome tell us what work is missing? Give this model a goal and permitted methods. It generates a route, then tests which actions can be avoided.
A synthetic two-unit tunnel fit-out. The methods and acceptance rules below are supplied assumptions, not Solway engineering requirements.
Change the brief. Watch the work change.
The generated work
Choose an action to inspect its reasonA reason for each action
Follow an outcome back to the work supporting it.
These links trace facts produced and consumed by this route. A later step is not automatically dependent on the step before it.
What survives a smaller scope?
The comparison below always uses the same access and methods with both units requested. Shared work retains one identity when B is removed.
What does “must” mean?
For each chosen action, the solver forbids it and searches again. If another successful route exists, that action is method-dependent. If none exists, it is unavoidable in this model.
Both methods still require temporary access. A particular setup action can be avoidable even when the broader function it serves is necessary.
This tests grounded actions against the declared methods. It does not establish necessity in every possible real project.
Four different relationships
A product is not a process.
A product structure describes physical things. A work breakdown groups the processes needed to deliver them. A process can change a product, use temporary equipment and produce evidence. “Is part of”, “contributes to”, “uses” and “produces” mean different things.
These views interpret this brief’s declared model. Select an item to follow its computed support. The process descriptions are proposed work, not records of work performed.
One route, more than one useful decomposition
A plan does not determine a unique WBS.
Change the packaging rule. Each action is owned once; cross-package support remains visible. These are two supplied organisational choices, not a discovered best organisation.
Give both routes the same problem
Does ontology earn its place?
One route compiles explicit semantic rules into a planning problem. The other uses a separately written PDDL domain and an independent parser and search. Both receive the same brief and count one step per action.
Semantic routeFoundation → domain → local factsTyped goals + declared process rulesFinite search → supported work packages
samescope
Direct PDDL routeExplicit predicates + actionsInitial state + the same final obligationsIndependent finite search → work packages
Which typed obligations came from this brief?
The completion profile is explicitly authored domain knowledge. Scope chooses the local objects to which it applies. The ontology does not discover engineering requirements from their names.
Where the meaning comes from
The foundational layer distinguishes objects, processes, qualities and information. The domain layer classifies a requested installation as a unit that needs acceptance evidence. Explicit domain methods and local access and handover rules supply the bridge from those meanings to actions.
The Turtle file is compiled into the model used here. The compiler and rule provenance are inspectable. Merely naming something “equipment” does not tell a planner how to install it.
The comparison we can make
Planning parity is an informative result. The semantic route makes the origin of obligations and support links explicit; a PDDL application could add the same explanations. We have not measured human modelling effort or established that ontology is better.
Our process search is ordinary finite planning. This essay does not implement the functorial plan-transfer algorithm in the source paper.
Inspect or reuse this exact problem
Show the PDDL problem
The restricted result
The end state is a starting point. Methods supply the bridge.
Necessity is conditional.
Restrict access or remove a method and previously replaceable work can become unavoidable. Remove a goal and some work disappears; a shared prerequisite can remain.
Structure needs another choice.
Causal support does not uniquely choose responsibility or hierarchy. Two packaging rules preserve the same work and expose different interfaces.
What remains unproved
A complete WBS for a real tunnel. Automatic discovery of engineering methods. Real safety, resources, time and cost. Full OWL reasoning or general PDDL support. A measurable productivity gain from ontology. Those would each require additional evidence.
Sources and lineage
- Digital Construction Entities and Information: the vocabulary distinction between the unit, its process, qualities and evidence.
- Basic Formal Ontology: foundational distinctions. This app uses a small declared alignment; it is not a complete BFO reasoner.
- Aguinaldo, Patterson & Regli — Automating Transfer of Robot Task Plans using Functorial Data Migrations, v2, 2025: ontology and actions together define a planning domain; transfer guarantees have conditions.
- The process/product distinction from the retired comparison is developed here using the current model. The old comparison and plan-import demo have been withdrawn; their history and the reasons are recorded in the curation note.
- Model ontology · Method, limitations and rerun instructions · App source and checks