← Side projectsSource & foray ↗

Portfolio Wave / Foray 165 / First exploration

One lane.
Two perfectly good plans.

The site needs concrete. The farmer needs to take cows to market.
Unfortunately, their plans share a farm track.

A concrete mixer waits before a farm gateway as unhurried cows walk along the same narrow lane toward market. Two construction workers wait beside foundation shuttering.
The cows have not read the programme. They do, however, have a process.

01 / The proposition

One world, two views of it.

A schedule describes work we intend to do. A risk register describes uncertainty about what may affect our objectives. Both concern processes in the same world. Can we model their interactions together, then take the views we need?

Red and green branching trees whose strands cross and intertwine; each contains nodes of the other colour.
The intuition. Risk and task accounts have different centres of attention, but their branches are entangled.
A closer network of interwoven red and green strands and process-like blocks.
The proposed move. Follow the connections through one process model. These are motivating images, not mathematical trees or evidence that a model works.
Cow and mixer sharing one lane emblem

Same kind of box; different relationships to the project.
“Deliver concrete” and “walk cattle along the lane” can both transform resources and conditions. Calling one a task and the other a threat tells us about intention and consequences—not a different law of composition.

Boxes do things

Moving, pouring, preparing and walking cattle are processes. A box needs explicit conditions before it can run.

Wires say what connects

They carry typed resources or information. A resource’s current condition is part of the state; a wire is not, by itself, a complete state description.

Risk adds a question

Which uncertain process, timing or outcome could affect which objective, under which conditions? A red box alone does not answer that.

02 / The picture behind the idea

The project is inside a world that keeps going.

This is the key sketch: tasks, risks and business as usual belong to the same changing situation. The enclosing “comb” keeps that wider world in view.

Lawrence’s original Project tasks in context comb: a green scope arch over task and risk boxes, crossing connections between them, and a business-as-usual process inside a lower resources cradle.
Lawrence’s original: “Project tasks in context”. Preserved unchanged. Open the full-size picture.

What I read in your drawing

The green arch: selected work contributes to the scope the project wants to achieve. It is one chosen account of the world.

The lower cradle: resources and surrounding activity do not disappear when the project starts. Business as usual keeps changing the situation.

The crossing connections: the influence runs both ways. Outside events alter what tasks can do; tasks and responses alter what may happen next.

The crucial insight: a risk register and a task list can be different views of this connected account, instead of separate worlds.

The surrounding shape has a close counterpart in Capucci’s environment comb: choosing a system leaves a context around it, including activity continuing outside it. The particular SCOPE / RESOURCES split here is your adaptation. This interpretation of your sketch is a reconstruction, not an attribution of its exact labels to that paper.

A corrected generic version

The context is the whole pale surrounding shape: it supplies conditions, continues acting, and receives the result. The project occupies openings within it. Two successive stages make the mutual influence visible through a shared handover, without drawing an unexplained loop.

Generic context comb: setup feeds project process P1 and outside process E1; both feed an explicit exchange and allocation handover; project P2 and context E2 then feed assessment and an updated situation.
One generic interaction round. Time runs left to right. Each wire carries a typed bundle of resources, conditions or information. Further exchanges require further stages. Open or save the full-size SVG.

Scope is a choice and an aim

The project boundary selects which processes we study as project work. Deliverable scope and objectives tell us what result we seek. Neither is an extra physical resource flowing down a wire.

Risk can concern either lane

The old “Risks” box becomes a specific mechanism—such as a cattle movement, breakdown or rework process. Uncertain timing and consequences can belong to project work, outside activity or the handover itself.

A handover has to do the work

It changes the next inputs to both sides. A lane, crew or machine must be allocated or transferred; drawing another line cannot duplicate it. Observations may be copied only under a stated information model.

Read it back into the cows. P₁ could prepare the shuttering while E₁ walks the cattle clear of the lane. At H, access is released and made available to the delivery. P₂ moves the concrete while E₂ continues farm work off the lane. If the cattle have not cleared it, that handover cannot supply the required free-access input. The next task waits.

The small formal statement behind this picture

Let setup map the initial situation to X₁ ⊗ R₁. The first project and context processes produce A₁ ⊗ B₁. The joint handover has type H: A₁ ⊗ B₁ → X₂ ⊗ R₂; the second pair produces Y ⊗ R₃, which the final context receives.

whole = post ∘ (P₂ ⊗ E₂) ∘ H ∘ (P₁ ⊗ E₁) ∘ pre

Read the formula from right to left. Each parallel pair assumes its inputs have been allocated consistently and that no further exchange is hidden within that stage. If there is another interaction, split the stage and expose another handover. The expression describes a completed round; enabling conditions and waiting require the accompanying transition semantics. This is an ordinary typed process construction inspired by a comb. It has external input/output boundaries; it is not Capucci’s closed context in a category of optics, and the explorer does not implement that theory.

This is a reusable conceptual pattern, not another simulated model. Its purpose is to make the original proposition legible and specify what a more general implementation would have to retain.

03 / Reconstructing the conceit

From the whiteboard to an explicit model.

The earlier trail includes Lawrence’s 25 October 2024 post about viewing risks alongside tasks, a July 2024 delayed-trusses example, and the March 2025 processes-to-plans mandate. Links come from the archived export; visibility may require LinkedIn access. The older high/low-probability distinction is revised here: intention, uncertainty and effect are separate dimensions.

The original plan lists “move concrete” then “pour concrete”. The second sketch lets the surrounding world into that plan: weather, a farmer, cattle and a road that the project does not own outright.

Original pre-cow flow: Move concrete feeds Pour concrete, with wagon, concrete, workers and shuttering wires inside a scope boundary.
Before: the project-only view. A useful baseline, but access is an unstated premise. “No cattle in this branch” does not mean “no risk”.
Original cow-risk sketch: cattle-to-market and weather processes use the road; Move concrete is crossed out.
After: another process uses the road. The crossed-out move becomes a temporarily disabled transition, not a deleted task. It becomes possible again when access is released.

Four repairs that preserve the idea

  1. Make access explicit in both pictures. One available lane is a resource; it cannot be copied into two simultaneous uses.
  2. Put workers where they are needed. The corrected toy uses one crew for shutter preparation and pouring. The delivery has its own driver, included in the loaded-wagon boundary.
  3. Return reusable resources; transform consumables. The wagon and crew survive. Concrete becomes placed concrete; shuttering stays in place. A completed pour is not a cured foundation.
  4. Separate a condition from its cause. “Sunny day” may inform the farmer’s choice. The first executable model treats cattle passage as a selected scenario; it does not assert that sunshine causes a market trip or assign it a probability.
See the starting plan
Original plan listing move and pour, adjacent farm and single road under risks, foundations under scope and wagon, concrete, groundworkers, shuttering under resources.
“Adjacent farm” and “single access road” name context and a constraint. A fuller risk statement is: cattle may occupy the shared lane when the delivery needs it, delaying the pour.

04 / Try the shared resource

Whose turn is it on the lane?

Every button applies the same kind of process rule. Start the cattle walk, then see why the delivery must wait. Preparing the shuttering can still proceed. Finish the walk and the delivery becomes available again.

This is a temporary exploration. Your changes stay in this page and reset on reload. No data is uploaded or saved.

What has happened?

    What can this model establish?

    The model explores all allowed start/finish interleavings for one delivery, one pour, one shutter preparation and at most one cattle passage. It supplies no frequencies, likelihoods or optimum policy.

    05 / The mathematics you can see

    A possibility map is not a schedule.

    The first diagram shows alternative enabled transitions. The second shows one chosen execution. A plan selects and times an execution; it cannot silently grant both users the same exclusive lane.

    ONE access token · competing starts, separate occupancy statesLane freeStart deliveryStart cattleFinish deliveryFinish cattleWagon on laneCattle on laneBoth journeys exist in this branch. Only one can acquire access.
    The shared-lane fragment. Circles are conditions/resources; boxes are transitions; a dot marks an available token. Both starts require the one free-lane token. Completing either use returns it. Cargo and cattle positions are additional prerequisites shown in the full rules below. This is the lane projection of the executable model, not the whole net.

    Corrected before and after, using the same wires

    Chosen execution: no cattle passage in this branchInput / output boundaries; colour marks perspective, not a different process type.DeliverPreparePourFree laneLoaded wagonCrewShutteringFree laneWagon + concreteCrewReady shutteringPlaced concreteEmpty wagonCrewShuttering in place
    Baseline branch: use the lane to deliver, then pour. Preparation can run independently of delivery because it uses a different resource.
    Chosen execution: cattle first, then deliveryInput / output boundaries; colour marks perspective, not a different process type.Walk cattleDeliverPreparePourFree laneCattle + farmerLoaded wagonCrewShutteringFree laneCattle clear of laneCrewReady shutteringPlaced concreteEmpty wagonCrewShuttering in placeCrossings without dots are not connections. The farmer and driver travel with their bundles.
    Cattle-first branch: the same lane passes through the cattle process before delivery. No fork creates a second road. The waiting delivery is delayed, not erased.

    Sequential composition: then

    walk ; deliver is shorthand for lane order: the full typed composition also carries the other resource wires through, using identity wires and rearrangement. The released access passes into the next process. Reversing the order is another valid execution under this model. It may be better or worse for different people.

    Monoidal composition: alongside

    deliver ⊗ prepare uses separate resources. It means independent work can be placed side by side. It does not mean a single lane may be shared without an extra rule.

    The process diagrams use the language of a symmetric monoidal category (SMC): typed inputs and outputs, composition, parallel combination and rearrangement of wires. The running model supplies concrete enabling rules. It is a small token-transition construction; this page does not implement an operad engine, optics, or a general open-net composition algorithm.

    Read the complete input/output rules
    ProcessOn starting: require / holdOn finishing: transform / return
    DeliverFree lane + loaded wagon (driver included)Concrete at site + wagon at site + free lane
    Walk cattleFree lane + cattle waiting (farmer included)Cattle clear of lane + free lane
    Prepare shutteringFree crew + unprepared shutteringReady shuttering + free crew
    PourDelivered concrete + wagon + free crew + ready shutteringPlaced concrete + empty wagon + free crew; shuttering remains in place

    A resource “on finishing” is not free while its process is running. The wagon is unique and its phase is represented by the cargo state. Fixed process boundaries include the driver and farmer; their separate availability is not tracked. Curing, concrete expiry, traffic safety, return journeys and weather dynamics are outside this first model.

    One model, more than one timetable

    The lane order is a decision or agreement; the weather and market trip are not under unilateral project control. These witness schedules assume both users are ready at minute zero, delivery takes 10 minutes, cattle passage 15, shutter preparation 8 and pouring 12. The numbers are invented teaching values.

    The cattle-first and delivery-first witnesses have the same completed processes and different timings. Neither is proved optimal or agreed in reality. A risk view should retain the competing demand and uncertainty; a chosen Gantt chart alone loses the unchosen alternatives.

    06 / Correcting the set picture

    Intended by whom? A threat to what?

    The nested idea works for this selected task set if we make its universe and perspective explicit. Here, an “item” is a modelled process affecting the project, and a WBS task means the process implementing that task—not the WBS document or deliverable itself. Here “project actions” includes work deliberately commissioned by the project, not only work performed by its own staff. This conceptual picture is broader than the four-process explorer.

    All modelled processes affecting the projectIntended by the project teamDeliberate project actionsProcesses implementingthe chosen WBS tasksA cross-cutting threat-bearing subsetPour concreteAgree access slotCattle passageHeavy rainCoordinate access(outside this WBS)e.g. desired supplier activities as well as the team’s own workFarmer’s intention:take cows to marketNot necessarily theproject’s intention.e.g. deliver, prepare, pourRain has no intention.Threat is relative toobjectives and context.
    A schematic Euler diagram: task-processes ⊆ deliberate project actions ⊆ processes intended by the project team ⊆ relevant processes. Threat-bearing processes cut across these layers; the dashed red region is illustrative, not a complete inventory.

    The nesting needs qualifications

    Coordination and mitigation may be deliberate project actions outside a particular WBS. A supplier’s separate maintenance can be desired by the project team without being commissioned project work. WBSs often organise deliverables, so the mapping to processes must be declared.

    The red subset needs moving

    Threats are not confined to the project’s intended processes. Cattle passage is intended by the farmer; heavy rain need not be intended by anyone. A planned pour can itself threaten quality or safety. Intention and adverse effect cross-cut one another.

    Contextone narrow laneUncertaintywill uses overlap?Processcattle occupy laneConsequencedelivery waitsObjectivepour on time

    “Risk” is not simply another subset of physical processes. A risk description connects uncertainty to effects on objectives. We can draw the set of processes associated with threats, provided we say so. Opportunities are the corresponding favourable possibilities; one process can help one objective and harm another. Probability, controllability, ownership and whether an event has actually occurred need separate annotations.

    Once cattle are observed on the lane, their presence is a current condition. Uncertainty may remain about how long they will take. A mitigation—agreeing a slot, changing a dispatch time—also belongs on the process map and can create new dependencies or threats.

    07 / Why these methods, and where next?

    A bridge back to Ends, Ways and Means.

    End

    Explore whether one compositional process account can connect project tasks, outside activities and their uncertain effects. The destination is reusable smaller blocks across projects; the cows are a deliberately small test.

    Ways

    Use process theories to focus on transformations; typed wiring to expose dependencies; resource-sensitive transition rules to expose competition; environment-aware thinking to challenge the chosen boundary.

    Means

    The six original images, source-backed corrections, this finite explorer, alternative execution diagrams and timed witnesses. Keep a simpler resource table as the comparator.

    Coecke, Fritz & Spekkens · processes before inventories

    A mathematical theory of resources supplies the process/resource perspective: transformations compose in sequence and in parallel. Here it motivates resource inputs and returns, not a rule allowing a road or crew to be copied.

    In the collected “best” Dynamic project states cluster; published-paper pp. 63–67. Our lane capacity and event rules are a separate, declared construction.

    Capucci · the project lives inside an active environment

    Open cybernetics systems I: feedback systems as optics is the strongest match for the remembered surrounding bars. Its environment-comb picture wraps a system and includes ongoing environmental activity.

    Collected under “best / 2nd tier”, Context section. The separate SCOPE and RESOURCES bars are Lawrence’s adaptation. This toy does not yet model an optic, feedback interface or controller. The related formal paper is Towards Foundations of Categorical Cybernetics.

    Patterson, Spivak & Vagner · wiring has a grammar

    Wiring diagrams as normal forms for computing in symmetric monoidal categories supplies typed ports, nesting and composition syntax. It motivates the visible process interfaces and the distinction between a diagram and what its boxes mean.

    In “best / Project wiring diagrams”, §2.1. Its directed acyclic syntax does not automatically validate the feedback loops in the original context sketch. Compatible ports alone do not establish feasible timing.

    Libkind, Baas, Patterson & Fairbanks · flow is not sharing

    Operadic Modeling of Dynamical Systems: Mathematics and Computation distinguishes directed interaction from undirected resource sharing. That distinction prevents confusing concrete transfer with two activities depending on the same road.

    In “best / Project wiring diagrams”, introduction. The road persists; this implementation reserves a single access token. It does not implement the paper’s dynamical-system algebras.

    Bakirtzis, Vasilakopoulou & Fleming · choose an explicit interface

    Compositional Cyber-Physical Systems Modeling distinguishes systems from the interfaces through which they are connected. Here the driver, farmer and return journeys expose where a boundary has been chosen and what it leaves out.

    In “best / Project wiring diagrams”, §2. These are boundary-design lessons; a material flow is not automatically the paper’s information-flow semantics.

    Baez & Master · a neighbouring route to composition

    Open Petri Nets explains how nets can expose boundaries for composition. The token diagram here is a small resource-sensitive net fragment. Gluing reusable farm-access components, with matching boundary semantics, remains a next step rather than an implemented feature.

    What the next essay must earn

    Package “use a single shared access” as a reusable component; then substitute a crane, test rig or review panel. Compare what can be checked locally with what requires the joined model. Add uncertain timing and an explicit coordination process only when their semantics are clear. Judge the extra machinery by the conflicts or reusable checks it reveals, compared with a plain schedule and resource table.

    What this first essay has established: within its declared toy rules, both stakeholder processes can be represented uniformly, exclusive access prevents an invalid overlap, and one process model permits several executions. It has not established a general risk theory, a scheduling optimum, a compositionality theorem, or usefulness on a real project.