Relay

What it is

Relay is the system underneath a chat message. A non-technical user types /start into a Telegram conversation, presses one button, and receives a compiled, AI-analyzed, formatted PDF report aggregated from multiple data sources. The chat interface hides everything else.

The interesting work is what happens between the button press and the PDF: multi-source aggregation, LLM-driven executive summary, anomaly flagging, and channel-specific formatting. The Telegram interface is one of several adapters; the same backend can deliver to Discord, and Teams support is in progress.

The Telegram interface. Bot greeting, "Generate Full Report + PDF" button, immediate compiled output.

The compiled report streaming back, with state-by-state metrics, severity color coding, and a PDF attachment.

The framing

I built Relay as a working prototype demonstrating a channel-agnostic enterprise report system. The current demo is themed around public health surveillance: a domain where multiple dashboards (case reports, immunization coverage, sentinel surveillance, training rollouts) need to be aggregated, analyzed, and routed to decision-makers who do not log into dashboards.

All data shown in the demo is simulated. The system is real and production-shaped; the numbers are illustrative. The architecture is the deliverable.

A complete generated report ends with the source link and an automatic PDF attachment. Same content, two delivery formats, single click.

Architecture

Hub-and-spoke. A single backend pulls from N data sources, runs analysis, generates the artifact (PDF), and delivers it through M channel adapters.

  Data sources                  Relay backend              Channels
  ┌─────────────┐                                          ┌──────────────┐
  │  Source A   │──────┐                              ┌──→ │  Telegram    │
  └─────────────┘      │                              │    └──────────────┘
  ┌─────────────┐      │   ┌────────────────────┐    │    ┌──────────────┐
  │  Source B   │──────┼──→│   Aggregator       │    ├──→ │  Discord     │
  └─────────────┘      │   │   LLM analyzer     │────┤    └──────────────┘
  ┌─────────────┐      │   │   PDF generator    │    │    ┌──────────────┐
  │  Source C   │──────┘   └────────────────────┘    └──→ │  Teams (WIP) │
  └─────────────┘                                          └──────────────┘

Adding a new source means writing one adapter. Adding a new channel means writing one adapter. The aggregator, the analyzer, and the PDF generator stay the same. This is the same architectural pattern as Soup: one backend, many surfaces.

The LLM layer

The compiled report is not just numbers. An LLM analysis pass runs over the aggregated data and produces a written executive summary, named critical alerts, and recommended actions. The output is constrained to specific structural slots (alerts go in alerts, summaries go in summary) and the underlying numbers are not regenerated, the LLM only writes about them, never over them.

Stack

What this project demonstrates

• Enterprise system thinking. Multi-source aggregation, channel adapters, formatted artifact delivery.
• LLM as analysis layer. Used where it adds value (qualitative summarization) and not where it would hallucinate (the actual numbers).
• Production-shaped prototype. Generates real artifacts (PDFs), runs on real infrastructure, can be deployed against real data sources.