Skip to main content

51. AI Integration with Signal Emitter

Status: Accepted Date: 2025-07-06

Context​

Now that we have a local AI processing capability (adr://ollama-local-ai), we need to define its role within the broader trading system. The AI can analyze data and generate insights, but we need a clear, decoupled pattern for how these insights are communicated and acted upon. Directly coupling the AI module to the trading execution logic would create a monolithic and brittle system, making it hard to test, modify, or disable the AI's influence.

Decision​

The mercury-ai module will not have any direct control over trading execution. Its sole responsibility is to perform analysis and generate structured signals (e.g., a Bullish or Bearish signal for a specific asset). These signals will then be passed to a dedicated, separate service, the "BS Emitter" (Bullish/Bearish Signal Emitter).

This emitter service acts as a central hub or event bus for these signals. Other services that are responsible for strategy and execution can then consume these signals from the emitter. This decouples the AI's analysis from the final trading decision.

Consequences​

Positive:

  • Decoupling & Modularity: The AI is a pluggable analysis component. We can swap out AI models, or even the entire mercury-ai module, without affecting the core trading logic. The trading system only needs to know how to interpret the signals from the emitter, not where they came from.
  • Testability: It's much easier to test the components in isolation. We can test the AI's ability to generate correct signals based on input data, and separately, we can test the trading logic's response to mocked signals.
  • Risk Management: We can easily "unplug" the AI from the trading system by simply telling the execution engine to ignore signals from the emitter. This provides a critical safety switch.
  • Flexibility: Other components, not just the AI, could also produce signals and send them to the emitter, allowing for a more flexible system where multiple sources of analysis can contribute to the final decision.

Negative:

  • Increased Architectural Complexity: This pattern introduces an additional component (the signal emitter service) and an extra "hop" for the data, which adds to the number of moving parts in the system.
  • Potential Latency: The extra step of going through an emitter service adds a small amount of latency compared to a direct call from the AI module to the execution logic.

Mitigation:

  • Lightweight Emitter: The signal emitter can be a very lightweight service, possibly just a thin wrapper around a Redis PUB/SUB channel or a simple message queue, minimizing its complexity and performance overhead.
  • High-Performance Messaging: For the implementation of the emitter, we can use a high-performance, low-latency messaging solution (like Redis PUB/SUB) to ensure the additional latency is negligible for our use case.