Flexibility probe — papermill-executed Jupyter notebook as a first-class simulator artefact

Question

This is not a research campaign in the thesis-chain sense — it is a platform flexibility probe. It answers one question:

Can the IP-078 + IP-081 + IP-085 stack carry a simulator whose primary deliverable is an executed Jupyter notebook (plus interactive HTML and a static figure), end-to-end, with no per-simulator code in the supervisor or analysis-writer?

If the answer is yes, then role: notebook from IP-085 §Layer 2 is real — the contract holds for an artefact shape we have not yet exercised in production. If the answer is no, the campaign synthesis names the specific gap (renderer missing, S3 sync drops .ipynb, supervisor refuses an unfamiliar slug, format: html blocked by the artefact whitelist, etc.) and the platform gets a concrete bug to fix.

The walking-simulation content is incidental — a straight-corridor walk with JuPedSim's CFSM, just rich enough that the notebook has something to plot. The campaign exists to stress the artefact-shape surface, not to advance the crowd-dynamics chain.

What we already know

• IP-085 already declares format: ipynb, format: html, and role: notebook as first-class entries in the artefact protocol (cf. IP-085 §Layer 2 format table and §"Manifest stability contract"). The schema lets a simulator emit them; nothing in the platform has actually done so yet.
• jupedsim-runner ships a working CFSM image — but its entrypoint writes a parquet trajectory, not a notebook. Reusing its Python deps is cheap (pinned to JuPedSim 1.2.x); writing a sibling walk-notebook image whose entrypoint is papermill <notebook> adds ~3–8 s of kernel boot per run, which is fine at this budget.
• The supervisor's tool whitelist (monad_knowledge/campaigns/subagent_spawn.py) does not have a per-simulator branch — it asks sim_simulators for the manifest and reads artefacts via sim_read_run / the sim://run/<run_id>/artefact/<path> resource template. If this works for parquet, it should work for ipynb and html modulo the renderer's content-type handling. This campaign is the test.
• The walk-notebook curated note exists alongside this brief and declares the outputs: block the protocol consumes.

What I want the supervisor to do

A single batch, six sub-experiments (3 corridor widths × 2 seeds, no parameter sweep beyond that). At the budget ceiling this leaves ~30 % headroom for the analysis-writer + critic.

Each group runs with seeds=[0,1] → 6 runs total. The campaign-wide constants (geometry, length_m, seconds, dt, window_s) live in sim_params.walk-notebook.base and are merged automatically — only vary corridor_width_m and n_agents group-to-group.

Analysis-writer responsibilities

Three things the synthesis must do, in order:

1. Confirm the artefact surface. For each run, list which IP-085 roles came back. The expected set is {scalar-summary, notebook, figure(html), figure(png), per-bin-summary}. If any are missing for any run, name the run and the missing role — that is the platform finding, not a research finding.
2. Read the scalar floor, not the notebook contents. Pull mean_traversal_s, mean_speed_m_s, lane_count from each run's walk-notebook.metrics.json via sim_read_run. Do not open the executed notebooks to extract numbers — the point is that the floor is machine-readable on its own.
3. Cite the notebooks by URI. When the synthesis discusses run-specific behaviour ("W1 seed 0 shows clear single-file with one pinch at t≈22 s") it must reference the notebook by sim://run/<run_id>/artefact/analysis.ipynb. The notebook is the deep-dive surface — the metrics are the headline.

Figure render request

One renderer slug: traversal_vs_width — a per-seed scatter of (corridor_width_m, mean_traversal_s) with the three groups colour-coded, no published band overlay (this isn't a calibration campaign).

Out of scope

• Calibration against any published band. The (ρ, v) sanity gates in _knowledge/simulators/jupedsim-runner §Sanity gates are not used here. We are not validating physics — we are validating artefact plumbing.
• Sweeping JuPedSim model parameters. time_gap, desired_speed, radius stay at CFSM-V1 defaults. Any sensitivity question is a follow-on campaign.
• Multi-simulator chaining. This campaign uses only walk-notebook. Re-running the same trajectory through pedpy-analyser is the natural next step but adds chain complexity that obscures the artefact-shape signal.
• Bottleneck or queue geometries. Straight corridor only. The supervisor must not propose alternative geometries on replan — straight_corridor is the only geometry value the entrypoint accepts.
• Anything BLE / CSI / EXP-P1 hardware. Pure simulation.

Expected interpretation

Three closing-sentence outcomes the synthesis should distinguish:

1. All three success criteria met → "The IP-085 protocol carries role: notebook and format: html end-to-end on the walk-notebook simulator; the platform supports notebook-as-artefact workflows without per-simulator supervisor code." Platform implication: notebook-emitting simulators are unlocked as a class.
2. Criteria 1 + 2 met, criterion 3 fails (no monotonic width effect) → "The artefact pipeline works; the toy physics doesn't show the expected width effect under CFSM defaults. The platform finding is positive; the physics finding is null and immaterial." Platform implication: same as outcome 1.
3. Criterion 1 fails (any required role missing) → "Notebook / HTML artefacts do not round-trip cleanly: <which role on which run> is missing. The renderer / S3-sync / manifest validator at <surface> needs a fix before notebook-emitting simulators ship." Platform implication: opens a bug-fix loop on the named surface, not a research follow-on.

Write whichever you actually find. The interesting outcome is outcome 3 — that is the one that pays for the campaign.

Operator notes — running this campaign in practice

• The budget envelope (0.6 CPU-h, 80 k LLM tokens, 500 MB S3) assumes 6 runs at ~30 s wall-clock each plus the supervisor + analysis-writer fan-out. Notebook execution dominates the wall-clock (papermill boot + ~12 cells); the simulation proper is < 5 s.
• walk-notebook is a sibling image to jupedsim-runner. Until the Dockerfile lands (dockerfiles/simulators/walk-notebook/), this campaign cannot dispatch on CI — the /campaign-curious path will fail at sim_run_launch with simulator_not_registered. Treat the brief as design specification until the image publishes.
• Once the image exists, the bridge path mirrors any other simulator: monad-knowledge sim sweep walk-notebook --grid <grid.yaml> followed by monad-knowledge sim campaign attach-run <session_id> <run_id> per resulting run, then /campaign-curious c-walk-notebook-flex to drive Step 6.

Notes (for future sessions)

If this probe passes, the natural follow-ons are:

• c-notebook-vs-script-cost — same physics, two simulators (walk-notebook papermill vs. a hypothetical walk-script that emits the same metrics + figures without a notebook), to quantify the papermill overhead the IP-085 §Future Considerations note flags.
• c-notebook-cross-simulator-synthesis — two walk-notebook runs at different widths PLUS one jupedsim-runner + pedpy-analyser run on the same corridor, to test whether the analysis-writer can synthesise across heterogeneous notebook + parquet artefacts.
• c-html-figure-archive — push the format: html boundary by emitting Plotly + Bokeh + a custom D3-vanilla HTML page in one run, to stress the artefact whitelist's html value.

Each is a separate brief; do not bundle.