Earlier modelling experiments · 2020
One job.
Seven graph models.
A site needs its waste removed. Identify it, prepare an extraction plan, commission suppliers and remove it. What changes when we describe this job through tasks, achieved states, people or tokens?
These small Neo4j examples let us inspect what each representation makes explicit—and what disappears. They are historical source models, not a working scheduler.
One small job, three kinds of thing
Follow the middle row from left to right. The green conditions explain what the blue tasks achieve and why later tasks can start. The pink roles show who is allocated. For example, preparing the plan and having an agreed plan are different things.
What disappears when we simplify?
The task-only view keeps the actions. The state-only view keeps the achieved conditions but drops the action names. Neither can answer every question the combined picture can.
Seven choices, different questions
This reading order is a new guide to the earlier files, not a claim that the richer model is always better. Nine script files contain seven distinct variants; two pairs are exact copies.
1 · Tasks
What work comes next?
Four named tasks are linked by permits. This makes the sequence easy to follow; achieved conditions and resource needs are left implicit.
2 · States
What needs to become true?
Four conditions run from “Waste understood” to “No waste left on site”. The links are called transitions_with_task, but the script does not name the tasks on them. The initial identification task has disappeared. This is a loss of information, not an equivalent view.
3 · Tasks and states
Why does that task enable the next one?
“Prepare Waste extraction plan” causes “Plan agreed”, which permits “Commission suppliers”. The intermediate condition now has its own identity. The assumed result of preparing a plan is agreement; no separate approval process is modelled.
4 · Add resources
Who is allocated to the work?
Operator, Engineer, Project manager and Supplier connect to tasks through allocated_to. Supplier is attached to two tasks. These links record allocation; they do not check availability, capacity or competing demands.
5 · Add direct dependencies
Can we keep the familiar task chain too?
Task-to-task permits links sit alongside the task–state–task paths. Both describe the same order here, but the script does not derive one from the other or keep them consistent after an edit.
6 · A Petri-net fragment
What might be counted or required for an action?
Two tasks become transitions; two states and two roles become places with token counts. This is only the first part of the job. The file records a proposed structure, with unresolved token meanings and no firing engine. See the qualification below before interpreting its arrows.
7 · Stored schedule attributes
Where could timing information live?
The fuller graph adds Start and Finish plus supplied duration, earliest/latest and slack values. Its four durations add to 50 unspecified time units. Those values are imported constants: the script neither calculates a schedule nor updates dates when a duration changes.
Reading the Petri-net attempt carefully
The change is suggestive: a role and an achieved condition can both be represented as places feeding a task. But the old file has not yet made their different meanings precise.
- “Waste understood” and “Plan agreed” already have one token in the supplied marking. This is not a simulation starting before those conditions are achieved.
- The “Waste understood” input has
Consumed_tokens: 0. If that property is intended as an input-arc weight, zero imposes no token requirement under ordinary Petri-net firing rules. It is not a test that the condition holds while leaving its token untouched; that needs an explicit rule or construction. - Role inputs consume 5 Operator tokens and 10 Engineer tokens, with no return arcs. The file does not establish whether these mean people, effort or something else, and does not model reusable availability.
These are limits of this attempt, not reasons to discard Petri nets. Nor does this file demonstrate open-system composition or derive a family of feasible schedules.
Read, edit or run?
Read: the pictures and linked Cypher files are available in a browser. Edit: the text files specify the imported graph. Run: they use historical Neo4j syntax; compatibility with current versions has not been checked. They create graph records, not an execution or scheduling engine.
The files and original images are retained in project-scheduling-with-Neo4j. This guide reads the August 2020 source snapshot; it adds explanation without rewriting those models. The separate Highways machine-learning notebook is a different experiment, not part of the seven-model comparison.
The useful comparison is what each graph can express and what a reader must still supply. A picture of a dependency, a resource allocation and a computed schedule carry different commitments.