# When a complete plan will not fit a tree The [Causal Plan Lab](../apps/causal-plan-lab/) starts with a small project process, generates complete legal firing traces, and turns a selected trace into a dependency-preserving plan. It then answers a narrower question: can this plan's order be expressed exactly by a tree made only from tasks, sequential blocks and parallel blocks? Sometimes it can. Sometimes a four-task obstruction proves that this particular tree language must either invent a dependency or omit one. There is a second difficulty: when tokens are interchangeable, their chosen ancestry can change the answer even though the process model, firing trace and count snapshots stay the same. This is a finite research experiment using a fictional cliffside refuge. It advances the Petri-net → execution → WBS/schedule route by making the transformation and its limits executable. It does not establish a total Petri-to-WBS functor, a new mathematical theorem, or an engineering method validated in practice. ## Three objects that must stay separate | Object | What it records | What it does not establish | |---|---|---| | Count trace | Transition firings and the number of tokens at each place after each atomic firing | Which particular earlier output supplied an interchangeable token | | Chosen token-flow witness | Distinct event occurrences, selected producer-to-consumer connections and an exact dependency order | Unique collective-token causality or every alternative execution | | Elementary Seq/Par tree | Task leaves with the ordering semantics defined below | Every possible WBS convention or the full expressiveness of monoidal process diagrams | “Elementary WBS” here means the lab's restricted event-block grammar. A conventional deliverable hierarchy need not assert scheduling precedence at all; the obstruction is not a claim that all WBS must fail. ## From a Petri model to a complete witness A model declares places, initial token counts, transitions, input/output counts, positive durations, per-transition firing bounds and a goal marking. A transition may fire when the current marking contains all its inputs. An atomic firing consumes those inputs and adds its outputs. The goal is **covered** when every requested place has at least its required count; other remaining tokens are allowed. Generation enumerates first-goal firing traces within the declared firing bounds. It stops extending a trace once the goal is covered. It does not use marking-state deduplication to discard different routes to the same state. A legal partial trace is not reported as a complete goal plan. Every firing receives a distinct occurrence ID. Repeating one transition twice produces two events, rather than collapsing them under a shared task label. The replay also chooses which available tokens each occurrence consumes. FIFO takes the oldest available producer runs; LIFO takes the newest. These are explicit bookkeeping policies, not evidence about physical provenance. An output consumed by a later event gives a producer → consumer edge. Initial tokens have no producing event. Multiple tokens and places can supply reasons for the same event relationship. Closing these edges transitively gives a finite strict partial order on event occurrences. Places marked `resource` obey the same consume/produce rules as other places. Their label distinguishes allocated reuse from condition dependencies in the explanation. For a reusable lifting token, a task consumes the token and returns it as an output. A persistent prerequisite must likewise be modelled explicitly; its label does not silently make it reusable. The atomic count snapshots shown by replay are not concurrent timed marking snapshots. Timing is constructed separately from the selected witness. ## Timing and lawful freedom Under the lab's timed interpretation, an event consumes its inputs at its start and produces outputs at its finish. Its earliest start is the latest finish of its predecessors, or zero when it has none. The duration is then added to obtain its finish. For a valid chosen token-flow witness, every required token has been produced before its consumer starts, and no token has two consumers. The resulting earliest schedule therefore respects the declared token rules. Independent tests check this with a timestamp sweep: finish outputs become available first, then the **combined** inputs of every event starting at that time must be available. Two events being individually enabled is not enough if both need the same single token. Every linear extension of the witness order is a lawful atomic ordering of those occurrences with that allocation. These are the freedoms of one witness. They are not all schedules or all method choices allowed by the original model. An earliest schedule minimizes completion time for that fixed precedence witness and those fixed positive durations. It does not optimize over token allocations or all possible project executions. LIFO can, for example, reuse one returned resource token while leaving another token idle, creating avoidable serialization. ## The exact tree question The grammar is: ```text Task(event) Par(child1, ..., childN) Seq(child1, ..., childN) ``` Each event appears once. `Par` adds no order between different children. `Seq` requires every event in an earlier child to precede every event in every later child. The empty tree represents no events. The recognizer recursively examines the induced event order. Disconnected components of its comparability graph become parallel children. Otherwise, disconnected components of its incomparability graph become sequential children in their common cross-component order. If neither split exists for a non-singleton set, the exact tree fails. A positive certificate expands the resulting tree back into order pairs and compares them with the original transitive order, with every event present exactly once. A negative certificate identifies four distinct events `a,b,c,d` whose **only** strict comparisons are `a