Modules can react to what happens across the fleet. When a new system is created or destroyed, a module that cares can run one of its own hooks in response — a first-class, declarative way to say “when this happens anywhere, run my code.” A DNS module, for instance, registers each new system automatically the moment it appears, without anyone wiring it up by hand.
Declaring a reaction
A module declares its reactions right in its manifest, alongside the event it listens for and the hook that answers. The intent is readable at a glance:
subscriptions:
- name: dns-register-system
pattern: system.created.*
hook: on_system_event
hook_inputs: { op: register }
- name: dns-deregister-system
pattern: system.destroyed.*
hook: on_system_event
hook_inputs: { op: deregister }The framework forwards the event’s details into the hook as inputs, so the hook knows which system to act on. This is a general mechanism — any module can pair any event with any of its hooks. No feature has to invent its own bespoke command to react to fleet activity.
Fault-isolated by design
Each reacting hook runs in its own subprocess, not inside the long-lived process that dispatches events. That boundary is deliberate: a hook that loops forever, leaks memory, or crashes takes down only itself, and the dispatcher can cleanly kill a runaway on timeout. One misbehaving module can’t stall the fleet’s event delivery for everyone else. Reactions are powerful without being fragile — a module gets to respond to the whole fleet while staying safely contained.