Kinage Notifications

Notification systems fail in one of two ways: they send too much and train users to ignore everything, or they send too little and miss the events that matter. The Kinage notification layer was designed to walk that line, delivering only the signals that warrant an analyst's attention while suppressing the ambient noise that would otherwise cause alert fatigue and adoption drop-off.

1. 1.
   Event-Driven Architecture: Build a real-time notification delivery system on an event-driven backbone, so analyst alerts fire within seconds of a signal being classified, not on a polling schedule.
2. 2.
   Multi-Channel Routing: Route notifications across email, in-app, and push channels based on signal priority and analyst preference, with channel fallback logic for high-priority signals.
3. 3.
   Filtering Logic: Design the filtering rules that determine what earns an interrupt, calibrated to analyst-reported importance thresholds from the workflow research phase.
4. 4.
   Feed Integration: Integrate tightly with the Kinage Intelligence feed so notification content matches exactly what the analyst will see when they open the dashboard.

• ◆
  Interrupt Criteria Design: Worked with analysts to define the specific signal characteristics that warrant pulling someone out of their current work, building explicit criteria rather than a general 'high priority' flag.
• ◆
  Event Architecture: Implemented an event bus that the Intelligence feed publishes to on each new signal classification, with subscriber logic for each notification channel.
• ◆
  Channel Preference System: Built an analyst preference layer that overrides default routing, allowing each analyst to tune channel and threshold settings without affecting platform-wide behaviour.
• ◆
  Adoption Monitoring: Instrumented notification open rates and action rates per channel and signal type, using these to iteratively tighten the filtering criteria toward optimal alert volume.

Alert fatigue is not a volume problem, it's a relevance problem. Analysts don't stop reading notifications because there are too many; they stop because too many don't matter. The filtering criteria design is therefore the core product work in this project. The engineering of reliable delivery is table stakes. The product work is deciding what earns a notification in the first place, and that decision has to come from analyst workflow research, not from defaulting to 'notify on everything' and letting users manage their own noise.

The notification filtering logic is a product decision. I designed the rules around what earns an interrupt, when does a signal justify pulling an analyst out of what they're doing? That question drove the architecture.

Analysts get signals that warrant their attention, delivered at the right time, without alert fatigue.