How I built PharmaTrace: an observable drug-interaction triage assistant with SigNoz

There is a specific kind of failure that happens in AI apps that looks harmless at first.

The interface loads. The button works. The response comes back. But when something feels off — a slow response, a weak answer, a missing result — you have no idea why. For most demos, that is an annoyance. For healthcare-adjacent workflows, that is a problem.

That was the starting point for PharmaTrace.

I wanted to build something practical for the Agents of SigNoz Hackathon 2026: a drug-interaction triage assistant that does not just produce an answer, but makes its own process visible. So instead of building a generic chatbot, I built a retrieval-grounded system that checks live FDA evidence, synthesizes a structured review, and exposes the full path through SigNoz.

It ended up being one of the most useful project decisions I made.
Where the idea came from

Drug interaction questions are deceptively simple on the surface. Two drug names go in, and some kind of safety guidance comes out. But once you think about what that means in practice, the problem gets more serious.

A weak answer is not just “wrong output.” It can be delayed, poorly grounded, or impossible to debug. If the system times out, or if one of the external APIs behaves strangely, or if the model gives a vague summary, you need to know what actually happened under the hood.

That was the gap I wanted to address.

PharmaTrace was my answer to that gap: a triage assistant that retrieves current FDA label and adverse-event evidence, then uses an LLM to turn that evidence into a structured, review-oriented response. The goal was never to replace clinical judgment. The goal was to make the workflow clearer, safer, and much easier to inspect.
What PharmaTrace actually does

The core experience is simple.

A user enters two drugs in the Streamlit frontend. The backend validates the request, retrieves evidence from OpenFDA, generates a structured review with Groq, and sends back a response that includes:

a review status,

a short clinical-style summary,

label warnings for each drug,

interaction evidence,

FAERS co-report signal,

and limitations/disclaimers.

That structure matters because it forces the system to stay grounded. It does not drift into free-form speculation. It produces a decision-oriented output that is easier to read and easier to trust.

The frontend then shows the response in a clean, tabbed interface with summary, evidence, and observability sections. Recent analyses are also stored locally so I can revisit past results while testing.
The stack behind it

I kept the stack intentionally lean:

Streamlit for the UI,

FastAPI for the backend,

OpenFDA for live evidence,

Groq for synthesis,

OpenTelemetry for tracing,

SigNoz for observability.

The architecture is straightforward, but that simplicity was the point. I did not want the project to depend on a complicated infrastructure layer just to prove the idea. I wanted something that felt real, testable, and easy to explain.

The request path looks like this:

user submits two drugs,

backend validates the input,

FDA label and FAERS data are fetched,

the model generates a structured summary,

traces are exported to SigNoz,

the result returns to the frontend.

That flow became the backbone of the project.
Why SigNoz changed the project

This is where the project stopped feeling like a demo and started feeling like a system.

Before adding observability, the app was functional, but opaque. If something slowed down, I had to infer where the issue was. If the model output looked weak, I could not easily tell whether the problem came from the prompt, the retrieval step, or the API latency. That kind of uncertainty is exactly what makes AI systems hard to trust.

SigNoz gave the project a shape I could actually reason about.

I instrumented the app so I could see:

the overall request latency,

backend spans,

OpenFDA label lookup spans,

FAERS co-report lookup spans,

model synthesis timing,

and the end-to-end trace for each review.

That changed how I debugged the app. Instead of asking, “Why is this slow?”, I could see whether the delay was in retrieval or generation. Instead of guessing whether a failure was local or upstream, I could inspect the trace and find the answer.

For an AI-assisted triage tool, that matters a lot. If a system is going to make decisions that people might rely on, it should not behave like a black box.
The hardest part

The hardest part was not writing the frontend or even wiring up the model.

It was getting the entire flow to behave like one coherent product.

There is always a temptation in hackathon projects to focus on the visible layer and treat the rest as plumbing. But in this case, the plumbing was the product. The value came from making retrieval, generation, and observability work together cleanly.

That meant being careful about:

request validation,

structured responses,

failure handling,

trace naming,

and keeping the frontend stable while I changed the backend.

I also ran into the usual deployment friction: local URLs, backend separation, environment variables, and different hosting constraints for frontend and backend. But in a way, those constraints helped sharpen the project. They forced me to make the architecture more deliberate.
What I learned

The biggest lesson from building PharmaTrace was that observability is not just for production systems. It is a design tool.

When you can trace a request clearly, you start making better decisions earlier. You can see bottlenecks sooner. You can understand failures instead of just reacting to them. And when the project sits in a sensitive domain like healthcare triage, that visibility becomes part of the product itself.

I also learned that “AI-powered” is not enough on its own. A useful AI system needs boundaries:

it should stay grounded,

it should explain itself,

it should expose limitations,

and it should be debuggable.

That combination made this project feel more serious than a typical hackathon build.
Deployment and demo setup

I deployed the backend separately and pointed the Streamlit frontend to the public backend URL instead of localhost. That was necessary so the app would work outside my machine. The frontend runs on Streamlit Community Cloud, and the backend is hosted on Render.

This split setup turned out to be useful for the demo too, because it made the architecture easier to explain:

frontend for interaction,

backend for retrieval and synthesis,

SigNoz for visibility.

That is a simple story, but it is also a real one.
Closing thoughts

PharmaTrace started as a hackathon submission, but it became a reminder of what good AI systems should feel like.

They should not just answer. They should show their work.

That was the main idea behind this project: take a high-stakes, hard-to-debug workflow, ground it in live evidence, add observability where it matters, and make the whole thing understandable from the outside.

That is also why SigNoz fit so naturally into the project. It did not feel like an extra feature. It felt like the missing layer that made the system honest.