Core runtime systems
These systems define how work moves and completes inside one engine. Read them in contract order; the scheduler internals are rarely the first place to edit.
| Concern | Chapter | Owning layer |
|---|---|---|
| Addressing, kinds, delivery | Mail and kinds | actor/data/substrate |
| What may run concurrently | Concurrency and blocking | actor/substrate |
| Queueing and worker policy | Scheduler | substrate internals |
| Ordered frame stages | Frame lifecycle | lifecycle capability/chassis |
| Causal completion | Tracing and settlement | substrate + trace capability |
| Per-actor evidence | Logging | actor/substrate/MCP |
| Boot-time policy | Configuration | derives + chassis composition |
The stable public contract is mail plus actor seriality. Scheduler queues, worker heuristics, and tuning defaults are implementation details unless an ADR promotes them. When debugging, prove the failure layer before changing a knob:
wrong name/schema → registry or kind issue
handler never runs → delivery/wiring issue
handler overlaps itself → actor invariant violation
descendants remain pending → settlement/hold issue
correct but slow → cost/scheduler/load issue
Changes here have wide fan-out. Read invariants, the owning ADRs, and tests across both native and wasm actors before editing.