Restatement: what this model is
We treat a project as a state space plus allowed transitions. The brick demo makes those transitions concrete (build / wait / switch direction). The circle demo shows a key planning reality: you often only observe part of what’s happening—so you need an explicit input→output map.
What was corrected + improved
- Explicit dynamics: distinguish initial parameters, allowed actions, readout and state update. The conceptual connection to Myers is scoped below, not a claim of implemented modular composition.
- Brick model clarified: each course’s doping affects (i) curing delay after that course and (ii) direction constraint for the next course.
- Added real planning analytics: total feasible plans, switch-count histogram, min/mean/max switches, and time estimates including setup penalties.
- Circle model improved: analytic visibility windows (entry/exit times) + timeline view, not just sampled logging.
- Robust UI: responsive layout, reserved canvas space, pause/resume controls, and a safe fallback path.
A. Cylindrical Brickwork — Project-State Toy Model
Build a circular installation course-by-course. Each course has a doping label (D0/D1/D2) that changes what transitions are allowed next and how long you must wait. This is a compact stand-in for real project constraints (dependencies, cure times, changeover/setup costs).
The policy restricts the selected direction rule; conflicting choices produce zero feasible plans. Parameters are fixed for each run. Editing them stops and resets the run; valid changes recompute, and invalid entries remain visible for correction.
Doping per course
In the D0/D1/D2 direction rule, D0 frees the next direction, D1 keeps it the same, and D2 forces the opposite. In the categorical curing law these also give base, zero, and base + extra cure. Numeric curing instead uses the separate JSON values.
Analytics
Best plan preview (direction sequence)
The rings are an unwrapped course index, not physical support geometry. One model step places a brick or waits one unit; playback accelerates brick placement relative to waiting. Earlier #1 is recovered at course boundaries with setup = 0, offset = 0 and final cure off.
Event log
B. Viewing Window — Precursor Model (Partial Observability)
A point moves around a circle at constant angular speed. You only “see” it through a short arc (“the slot”). This is the planning analogue of checkpoints, dashboards, and status meetings: you don’t observe the whole state, only a slice.
Predicted observation analytics
These windows are predicted from the entered full model, not inferred from observations alone. The grey hidden dot in the drawing is a full-state teaching overlay, not sensor output. Positive angles are clockwise on this screen.
| # | t in (s) | t out (s) | duration | θ in | θ out |
|---|
Next five crossings after t = 0
Crossings are genuine boundary events, independent of the chosen horizon. Window endpoints clipped at 0 or T are labelled as horizon boundaries.
Observer log
What the model actually constructs
The brick model constructs feasible direction plans and expands one into brick-placement, setup and curing transitions. The circle model constructs an exact constant-speed trajectory and its visible time windows. These are specified toy dynamics, not dynamics recovered from a blueprint alone.
State, action, readout, update
For brickwork, the run state includes the course, number of bricks placed, current direction, setup/cure phase and remaining wait. The chosen plan is fixed during playback. At course boundaries, the selected direction rule and policy determine the admissible directions; within a course the next placement or wait is prescribed.
readout : S → O
allowed : S → finite sets of actions
update : {(s,a) | a ∈ allowed(s)} → S
The drawing reads this run state. A policy resolves choices; a trajectory is obtained by iterating updates. Neither a drawing nor a list of direction plans is itself a proof of a compositional interface.
Myers connection, with a boundary
A deterministic system can be described by a readout S → O and update S × I → S. Here admissible actions depend on state, so the displayed allowed/update formulation makes that dependence explicit. This page does not implement a general arena-composition engine or prove that the visible blueprint alone determines the action menu.
For the circle, hold ω, r and the slot fixed during a run: θ̇ = ω. Initialisation supplies θ(0); it is not the dynamics update. Readout is θ when inside the slot and ⊥ otherwise. Radius changes geometry, not angular crossing times.
The hard visible/null gate is discontinuous at its boundaries. Its output lies in the set of angles plus ⊥; it is not a smooth cotangent pullback. The trajectory is evaluated analytically and the observer code is explicit; no smooth derivative or completed lens-wiring theorem is claimed.
Export (optional)
Copy computed results or download the current event log. This page keeps data only in this browser tab; exports are local files or copyable text. Reloading resets the experiment. No server is changed.