Back to app index

PDDL → Explainable WBS (Interactive) — Emergency Shelter “halfway up” Gimmer Crag, Langdale

The model is a small STRIPS/PDDL-style planning problem: a target end-state (goal literals) + a catalogue of actions (preconditions/effects). Clicking Generate plan & WBS runs a lightweight best‑first planner, then compiles an explainable Work Breakdown Structure by goal decomposition + causal links. This stays high-level (no technical rigging/installation instructions); treat it as a planning/specification aid and consult qualified professionals for real-world execution.
Petri net → WBS (Mermaid)
About this workbench
Choose a button to view details.
Scenario
Think of literals as “auditably true statements.” Toggle assumptions; the planner will either produce a plan (action sequence) or prove it can’t reach the goal with the current domain.
For cliff/rock contexts: professional oversight, rescue readiness, and legal/landowner constraints are non‑negotiable in practice; the toggles here are epistemic switches for modelling.
Initial state & goals
Init (facts already true) —
Goal (end-state) —
Status: idle
Planning model (PDDL-style)
The UI edits the problem (:init and :goal); the domain is fixed but readable/exportable.
Domain (actions)
Problem (init & goal)
How the WBS is derived (explainability rule)
  • End-state literals are clustered into deliverables (work packages) like “Access & Rescue Readiness.”
  • Each plan action is assigned to the first deliverable whose target literals it contributes to (direct effects), and is displayed with its causal justification.
  • Within each deliverable, actions are ordered as in the plan, giving a traceable “because → therefore” chain.
This is deliberately “explainable by construction”: every work package is grounded in explicit predicates, not informal phase labels.
Outputs
WBS (tree)
Plan (actions)
Explain (causal links)
Tip: click the squares to collapse/expand. Each node has a short “why” grounded in literals the planner used.
Safety & realism notes (non-optional)
This planner treats “actions” as abstract commitments; it cannot capture real cliffside uncertainty (rock quality, anchor integrity, wind loading, human factors). In practice you’d add (at least) probabilistic risk models, verification gates, professional sign-off, and explicit constraints (e.g., “no single-point failures”).
If you use the model, use it for documentation and explainability—not for operational instructions. Treat every “access/anchor/rig” step as requiring qualified specialists and local authority guidance.