Idea: keep a single “graph data structure” (GDS) as the authoritative project model, and render stakeholder views from it.
This matches the MBSE pattern of Concept → Model → Graph → View: a conceptual model is transformed into a generic graph data structure, then
rendered into multiple views (visual graphs, matrices) to inform different stakeholders. In this prototype, the GDS is a typed process network.
The left side shows state (what is true / available) and process (how state changes). The right side shows the
schedule abstraction (what must precede what). You can switch datasets to see the consequence of starting from a task-only DAG.
- State view: resources/deliverables/risks with availability status.
- Process view: boxes with typed inputs/outputs (resource semantics are explicit).
- Task plan: precedence constraints (resource semantics are mostly hidden).
Processes as arrows, systems as objects. A “process theory” treats systems/resources as objects and transformations as morphisms.
Traditional process theories correspond to symmetric monoidal categories (SMCs), and can also be expressed as algebras of wiring operads.
The wiring diagram itself encodes composition (connecting outputs to inputs), rather than privileging only sequential vs parallel composition.
In this prototype we use a lightweight, engineering-friendly version:
- System types = resource/deliverable types (e.g. PermitsApproved, AnchorsInstalled).
- Primitive processes = tasks with typed inputs/outputs (e.g. InstallAnchors).
- Composition = wiring outputs to later inputs (acyclic wiring).
- Monoidal product = doing things “side-by-side” when independent (parallel work).
Formal sketch (kept short)
Let R be a set of resource types. Objects are finite lists/multisets of elements of R.
A primitive process is a morphism f : A → B between such objects.
Wiring diagrams compose morphisms by matching output types to input types (acyclic). Parallel composition is multiset union.
A schedule view is the preorder category on tasks: A ≤ B iff there is a path of prerequisite edges.
Why the reverse map is lax: A dependency edge A ≺ B only says “A finishes before B starts”.
It does not say what flows (materials? info? risk reduction? access?) nor how much, nor whether it can be substituted.
So many distinct process models collapse to the same schedule. Recovering the process semantics needs extra choices (templates, ontologies,
constraints, or data).
In category terms: the Process → Plan map behaves like a forgetful projection. It can be useful (for planning) but is not invertible.
The Plan → Process map therefore behaves like a lax functor: it can add “witness” structure, but only up to non-unique refinement.
Iteration, uncertainty, risk: Real design and construction aren’t strictly acyclic.
Engineering process models often include iteration loops, rework propagation, and “process variables” that change over time.
One practical technique is to keep the diagram mostly acyclic while representing iteration via versioned deliverables
(Design_v0 → Review → Design_v1) or via probabilistic outcomes.
This prototype hints at that by treating risks and information maturity as first-class “state resources”.
Next steps would be:
- Process variables (e.g. “design maturity”, “weather confidence”) that gate task availability.
- Probabilistic iteration (e.g. review may trigger rework with probability), yielding schedule risk bands.
- Enrichment (cost, probability, metrics) so composition tracks more than mere feasibility.