core.on_event: an interrupt handler, valid inside an interrupts slot and nowhere else (ADR-0002 decision 10).

A leaf with four config fields: the event that fires it, an optional cond that decides whether it fires at all, the outcome that decides what happens to the group it interrupts, and an optional capture that writes values out of the firing event's payload into the datamodel before the outcome is raised.

Placement, in both directions, from one tag

This type declares kinds: [:interrupt_handler] and nothing else. That single tag is the whole placement rule:

• an on_event dropped into a body slot fails, because body declares [:step] and the two sets do not intersect;
• an ordinary step dropped into interrupts fails, because interrupts declares [:interrupt_handler] and a step is not one.

ADR-0002 decision 10 originally recorded the first direction as a special-cased validation rule the core types carry, and withdrew it at acceptance in favour of ADR-0003 decision 3's kind tags, which close both directions with one declaration on each side. There is no placement check in this module, and there is not supposed to be one: adding it back would give the editor two code paths to highlight from.

This type also never names the group types it may live inside. A host group with an interrupts slot admits it by declaring "interrupts" => [:interrupt_handler], and a host with a genuinely different notion of interrupt handler mints its own kind and its own group without touching this package.

Candidates for event (sb-82mu)

event is a plain :string and this type validates it the way it always has - the event-name shape rule, and nothing else. What the editor adds is a list of suggestions: the completion events the blocks in the handler's enclosing body raise, each written as the done.outcome.<state id>.<outcome> name StatifierBlocks.Compiler.StateId.outcome_event/2 mints, and labelled by the block's own card label and that outcome. Wiring a handler onto a sibling's outcome is then a pick rather than a transcription of a generated name.

Three properties of the list are this record's, not the control's.

• The body is read through the declaration. "The enclosing body" is every slot of the enclosing block that admits ADR-0003's :step kind, which is body on core.group and core.resumable_group and whatever a host group calls the slot it declares the same way. The handler's own interrupts slot declares [:interrupt_handler], so it is excluded by construction rather than by name.
• Only a type that declares outcomes contributes. ADR-0002 amendment A1 gives a type that implements no outcomes/1 a single default done, and offering an author a generated name for an outcome a type never declared would be offering them a wire that is not there.
• config_schema/1 is untouched. The field declaration gains no candidate key; the derivation is the editor's and is keyed on this type. core.send, core.raise and core.await each declare an event key too, and each names events this list is not about.

The outcome values

ADR-0002 decision 10 fixes outcome as a :select and names no values. Two are implemented:

They are the minimal pair ADR-0001 decision 10's compile target needs - transitions on the group's state, with the group's own history mode deciding where a "resume" re-enters. A third value is a config_schema/1 change plus a current_version/0 bump, not a document schema change.

The optional cond guard

cond is an optional :expression field, and when it is set it becomes the cond on the watcher's transition: the handler fires only when the event arrives and the condition holds. A handler with no cond - the key absent, or blank - emits exactly the bytes it emitted before the key existed, which is what keeps it an additive key rather than a document schema change.

The guard belongs here rather than on a core.branch after the handler, which is the shape it would otherwise be spelled as. A core.on_event decides whether to leave the in-flight body at all, and by the time a branch inside the handler could read a condition the body has already been abandoned - so the two spellings do not express the same thing, and only this one expresses a guarded interrupt. See ADR-0002's 2026-08-31 note.

The condition is the author's bytes passed through into predicator's datamodel verbatim. This package ships no expression checking of its own (ADR-0004 decision 9), so validate_config/1 only asks whether the stored value is a string; a typo inside it surfaces as an upstream compile error routed back to the "cond" field by the cond_key this type passes to StatifierBlocks.Core.Emit.transition/2.

Unlike core.branch, this type declares no value_path: its condition is stored at config["cond"], so ADR-0002 decision 7's default path - [key] - already addresses it. And summary/1 is untouched. ADR-0002 amendment H6 fixes this type's card as the outcome word then the event name, and the reason core.branch counts its arms rather than listing their conditions holds here too: an expression is not a chip.

The optional capture map

capture writes values out of the firing event's payload into the datamodel. It is a map, and the direction is worth stating twice because a path-to-path map reads either way: the key is the destination - a datamodel path - and the value is the source, a path inside _event.data. A capture of %{"order.cancel_reason" => "reason"} on a handler for order.cancelled writes that event's reason into order.cancel_reason.

One <assign> is emitted per pair, on the transition the handler already emits and before the <raise> that carries the outcome. The pairs are emitted in their datamodel paths' sorted order: a map has no order of its own and a compile has to be deterministic, so the record fixes one rather than leaving the bytes to a map's iteration. A handler whose capture is absent or empty writes no <assign> at all, which keeps the key additive in exactly the way cond is.

The assigns belong on the transition, and before the raise, for the reason the guard belongs here: the <raise> is what tells the enclosing group to abandon or resume, and by the time control is anywhere else that has happened - on abandon the body is gone, on resume the body is re-entered and history decides where. _event.data is in scope only for the transition the event selected, so a core.assign placed after the handler is a separate microstep with a different _event and the payload is not merely awkward to reach there, it is gone. See ADR-0002's 2026-09-05 note.

A captured value that quietly is not there is the failure this key has to avoid, because everything downstream would read it as an authored absence. What the interpreter does about that splits on whether the expression's root is bound, not on whether the whole path resolves:

• _event is always bound, so a capture whose source path is not in the payload writes the interpreter's explicit unbound marker and raises nothing. The marker is not nil and is not nil's spelling - unbound and null are deliberately different values there - so the absence is one a reader can test for rather than a silent hole. A consumer of a captured path has to make that test; that obligation is the whole of what this key promises today.
• A wholly unbound root raises error.execution and writes nothing. That is predicator's on_unbound: :error policy reaching Statifier.Interpreter.Content's one raise site, and no capture compiles to such an expression.

[Note 2026-09-05, sb-0q0z: this paragraph read "an <assign> whose expr does not resolve is an execution error", following ADR-0002's capture Note, which was written ahead of the measurement. Measured on two engine versions, the error is raised for an unbound root only, never for a missing member of a bound one. ADR-0002 carries the correction and the cites; the error arriving for this shape too is upstream work, and nothing here may be built on it until that lands.]

The compile-time half - a :config finding for a declared payload that lacks a named source path - is dormant, because nothing in this package declares an event payload's shape; fixtures/0 below is one sample per event name for a palette panel, not a declaration.

config_schema/1 declares no field for capture. ADR-0002 decision 7's field-type set has no member that describes a map, the 2026-09-05 note declines to add one, and how an author writes the pairs is ADR-0005's question rather than this module's. So the key is authored through the document today and not through the editor, and the two <assign> attributes carry no config attribution for the same reason core.subchart's composed conditions carry none: expr is composed here rather than the author's bytes verbatim, and location has no declared field for a finding to land on.