A Shared resources
Walls and roof can overlap when crew, tools and lift are available.
Project finish
Gimmer · a comparison of process rules
You’re asked to finish a mountain refuge sooner. Two teams show the same 36-day plan. Would extra resources help them equally?
Three short comparisons · a fictional build · no setup
Walls and roof can overlap when crew, tools and lift are available.
The method also requires walls to finish before roof work can start.
Wall and roof excerpt · same day 18–27 scale in both views. The comparison below checks all 14 tasks.
Take this into the next planning conversation
Before promising an earlier finish, establish whether the wait comes from shared resources or a required handoff. The plan alone cannot settle that question.
Fixed toy durations. Each step sets its own resources and priority. Temporary results; reload returns to step 1. Nothing is saved or approved.
Each model runs separately. Equality checks every task ID, label, start, finish and duration; resources, priority, units and makespan; and the full stage/WBS and same-start expression. The process arcs and their rationale are deliberately outside this plan projection.
This demonstrates information loss in a chosen-execution projection. It does not prove a mathematical functor or validate real construction sequencing, resource estimates or safety.
This model allows walls and roof to overlap when resources permit. Change resources, durations and priority, generate schedules, then inspect a candidate’s Gantt, task list and WBS. The SMC-style expression and WBS group tasks by start time: they are illustrative views, not a proof of equivalent process behaviour. Results are temporary; changing settings clears earlier candidates and reload resets the page.
Parallel blocks are joined with ⊗, sequential blocks with “;”.
A simple hierarchical packaging of the same tasks.
| Task | Start | Finish | Duration |
|---|
This is the untimed token view of model A. Fire enabled work, reset it, or follow the example route. Schedule generation above starts from the configured initial state, independently of this manual walk.
Places represent “states/resources”; transitions represent “work”. Tokens are your marking (what’s currently true / available).
A schedule is a particular way of firing transitions over time: different priorities, different resource tokens, different durations ⇒ different schedules, all still subject to the same encoded toy rules.
Two practical routes:
WBS becomes one projection of the same underlying process: group the same transitions into phases/work packages, and let each schedule produce a “time-respecting” WBS instance.
The key benefit is organizational: you stop arguing about precedence rules inside the Gantt chart, because the assumed precedence is explicit and open to challenge in the Petri net.