Back to app index

Petri Net → SMC → WBS: a “tiny artifact” workflow (toy project: build a mountain refuge halfway up a mountain)

This page is a single-file, shareable demo: it contains (i) a Petri net that encodes the physical logic of a mountain-refuge build, (ii) a timed simulator that turns different markings / choices into different schedules, and (iii) an “elementary WBS” view derived from those schedules.

1 file • runs offline Petri net = “what’s allowed” SMC term = “how it composes” WBS = “how you package it”
Quick explainer for the Petri net → SMC → WBS framing.
How to use this affordance in your project
Make the Petri net the single source of truth; generate many WBS/schedules as views.

Step A — Write the project’s physical logic as a Petri net

Places represent “states/resources”; transitions represent “work”. Tokens are your marking (what’s currently true / available).

  • Inputs to a transition = prerequisites/resources it needs.
  • Outputs = what becomes true when that work finishes.
  • Parallelism is not an extra feature—it’s just “multiple enabled transitions”.

Step B — Treat schedules as “executions” of that net

A schedule is a particular way of firing transitions over time: different priorities, different resource tokens, different durations ⇒ different schedules, all still compliant with the same physical logic.

In the theory view, a Petri net presents a (commutative) symmetric monoidal category: markings behave like objects, firing sequences like morphisms. That’s why “schedule alternatives” naturally show up as different composites / string diagrams.

Step C — Export and share as a runnable artifact

Two practical routes:

  1. Julia route: author the net in AlgebraicPetri.jl, explore/compose/simulate, export a self-contained HTML from a notebook.
  2. Browser route: keep a tiny JSON net spec + a tiny JS viewer (like this file), publish on GitHub Pages or attach to tickets.

Step D — Make WBS a view, not the source

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.

1) The toy Petri net: build a mountain refuge halfway up a mountain

Interactive Petri net
Click an enabled transition to fire it (instant / untimed).
Tip: The untimed firing view is about reachability (what markings are possible). The schedule generator below adds durations + resource tokens.
Marking + enabled work
The Petri net tells you what’s allowed right now.

Enabled transitions

What this encodes

  • Permitting/logistics/access work can proceed in parallel after kickoff.
  • Foundation requires: permits + materials at site + site prepared + crew + tools.
  • Walls & roof can be parallel if you have enough crew/tools/lift tokens.

2) Generate schedule options from the same net

Timed schedule generator
Different tokens/durations/priority ⇒ different schedules, same logic.

Resources




Priority policy


Durations (days)

Generate schedules



—
Each candidate is a timed execution of the same Petri net. If you keep the net fixed, any schedule produced is automatically “physically compliant” by construction.

Candidate list

Selected schedule → Gantt + SMC term + WBS
Pick a candidate on the left.

Gantt (simple)

SMC expression (one view)

Parallel blocks are joined with ⊗, sequential blocks with “;”.

Elementary WBS (schedule-derived)

A simple hierarchical packaging of the same tasks.

Task table

TaskStartFinishDuration

3) Reuse this pattern for your real project

A concrete workflow that stays “tiny”
Net spec → analysis → publishable demo. Repeat as the project evolves.

Version-controlled net as your “physics”

  • Keep a JSON net spec in the repo (places, transitions, arcs, default marking).
  • Review changes like code: “Did we add a dependency? a resource? a rework loop?”
  • Compose subnets when useful (foundation module, framing module, etc.).
Open Petri nets (nets with explicit input/output interfaces) are designed to be glued compositionally, which is a clean way to model “WBS modules” as composable components.

Many WBS + schedules as projections

  • Different markings correspond to different “what’s done / what’s available” states.
  • Different executions (choices + timing) correspond to different schedules.
  • Different groupings of the same transitions correspond to different WBS views.

The key benefit is organizational: you stop arguing about precedence rules inside the Gantt chart, because precedence is already encoded in the Petri net.

Exportable net spec used by this page

—
You can open this file locally (double click) or host it anywhere static. Replace the JSON with your real project net and keep the rest of the UI.