Event-Driven Coordination Channel¶

A signal-routing protocol — instantiates Distributed Coordination Architecture

Routes meaningful changes and exceptions to exactly the actors whose decisions depend on them, so coordination rides targeted signals instead of broadcast noise or constant shared-state polling.

Event-Driven Coordination Channel carries coordination on events — meaningful changes and exceptions pushed to precisely the actors whose decisions depend on them — with stable event semantics, subscriptions, priority, acknowledgment, duplicate handling, and missed-event recovery. Its defining premise is the archetype's signal discipline: more communication is not the goal, and a changed commitment or an exception usually matters far more than a continuous stream of raw state. So it answers "who needs which signal, for which decision, by when, at what confidence" by delivering the few decision-relevant events to their subscribers, rather than broadcasting everything to everyone or making each actor poll a shared board. It is the push complement to a shared-state model: state you would otherwise have to watch, it brings to you the moment it changes in a way you care about.

Example¶

An electricity system operator has to keep generation matched to load across many independently-run plants, second by second. Rather than have every generator poll one enormous shared telemetry dashboard, an Event-Driven Coordination Channel pushes targeted events. "System frequency dropping below 49.8 Hz — spinning-reserve units, ramp now" reaches only the units that hold reserve. "Wind forecast revised down ≈400 MW for the 18:00 block" reaches the dispatchable units that subscribed to forecast changes. A routine schedule update and a frequency excursion carry different priorities, so the excursion preempts the queue.

Each event requires acknowledgment — did the reserve unit actually see the call? — and the channel has missed-event recovery: a unit that dropped offline gets a state resync on reconnect rather than silently acting on stale information. The channel's whole value is turning a firehose of grid telemetry into the handful of signals each actor must act on, delivered fast, to the right subscriber, with proof of receipt.

How it works¶

It is event-driven, not state-polling. Signals are pushed on a meaningful change or exception, so actors are not forced to watch a stream to catch the moment that matters.
Subscriptions are keyed to decisions. An actor receives an event because one of its decisions depends on it — which is what keeps the channel targeted instead of a broadcast.
Events carry stable semantics and priority. A defined, versioned event vocabulary lets subscribers rely on meaning, and priority lets urgent signals preempt routine ones.
Delivery is guaranteed, not hoped. Acknowledgment, duplicate handling, and missed-event recovery (replay, resync on reconnect) prevent the silent failure of an unseen critical event.

Tuning parameters¶

Signal selectivity — what counts as event-worthy. Too loose and it floods; too tight and a decision-relevant change never arrives — the blindness/overload dial.
Subscription granularity — per-decision subscriptions versus broad topics. Fine-grained keeps it targeted but is more work to maintain as dependencies change.
Priority and preemption — how aggressively urgent events jump the queue ahead of routine ones.
Acknowledgment strictness — fire-and-forget versus required acknowledgment with retry, trading latency against delivery certainty.
Missed-event recovery — the replay window and the state-resync behavior on reconnect, which sets how gracefully a dropped subscriber recovers.

When it helps, and when it misleads¶

Its strength is cutting through broadcast noise: it delivers the decision-relevant change fast, to exactly the actor who needs it, and scales without requiring everyone to watch everything. Where continuous shared state would overload, targeted events reduce both blindness and overload at once.

Its failure modes track its dials. Loose selectivity produces alert flood — recreating the overload it was built to fix. Weak recovery produces silent failure, the most dangerous outcome, when a critical event is missed and no one knows. And stale subscriptions quietly miss newly-formed dependencies. Its classic misuse is broadcasting everything to everyone "to be safe," which abandons the targeting that is the channel's entire reason to exist.^[1] The discipline that keeps it honest is to key signals to named decisions and to guarantee acknowledgment and missed-event recovery rather than assuming delivery.

How it implements the components¶

information_and_signal_policy — it operationalizes the policy directly: who needs which signal, for which decision, by when, and at what confidence — realized as targeted, prioritized, acknowledged event delivery that favors exceptions and changed commitments over continuous raw state.

It does not hold the authoritative shared state itself — that is the Shared Coordination Board, the pull complement to this push channel; it does not define the procedure an exception triggers — that is the Exception and Escalation Protocol, for which the channel is only the transport; and it does not durably store the commitments whose changes it broadcasts — that is the Commitment and Dependency Register.

Instantiates: Distributed Coordination Architecture — the signal-routing layer that delivers decision-relevant change to the actors who need it.
Sibling mechanisms: Shared Coordination Board · Exception and Escalation Protocol · After-Action Coordination Review · Commitment and Dependency Register · Coordination Decision Rights and Autonomy Matrix · Coordination Health Review · Dependency and Interaction Map · Distributed Planning and Reconciliation Session · Interface Control Document or Service Contract · Joint Operating Agreement · Liaison and Integrator Role · Synchronization Checkpoint

Notes¶

The channel (push) and the Shared Coordination Board (pull) are the two halves of the signal/state split. Use both: the board holds the authoritative state an actor can consult on demand; the channel brings the change to the actor the instant it becomes decision-relevant. Relying on only one leaves either overload or blindness.

References¶

[1] The publish–subscribe pattern — publishers emit typed events and subscribers register for only the event types their decisions depend on, decoupling senders from receivers. This channel is its coordination-layer application, and pub/sub's well-known hazards (alert flood from loose topics, silent loss without acknowledgment or replay) are exactly the failure modes above. ↩