When a product’s return rate rises, the first question is usually straightforward: what went wrong?
Answering it is harder.
A returns dashboard might show that two headphone models have unusually high return rates. But it may not explain whether those products share a manufacturing batch, a component supplier or a courier. Investigating those possibilities means moving between records and comparing groups that don’t always appear together.
That was the problem I chose for ReturnTrace, my project for the WeMakeDevs × FalkorDB hackathon.
I wanted to build something that went beyond summarizing a dashboard. The idea was to help a returns analyst follow the evidence, decide what deserves inspection and use the inspection outcome in the next investigation.
Starting with a question, not a chatbot
The question behind ReturnTrace is:
Which connection best explains this return pattern, and what should someone investigate next?
That gave the project a clear workflow:
- Select a product with elevated returns.
- Compare its batches, couriers and warehouses.
- Follow relevant connections to other products.
- Propose an inspection task.
- Record the inspection outcome.
- Include that evidence in future investigations. I used synthetic data with deliberately different scenarios. This let me check whether the application could distinguish a shared-component lead from a courier handling pattern and whether it could stop when the evidence was insufficient. That last case mattered. An investigation tool shouldn’t always produce a confident explanation just because the interface expects an answer. Why I used a graph The useful information in this problem sits between records. An order contains a unit. That unit belongs to a product and comes from a batch. The batch uses a component lot supplied by a supplier. Another batch, for another product, might use that same lot. ReturnTrace stores those relationships in FalkorDB. Its investigation tools execute Cypher queries to follow them. The main demo starts with Aura Pro. One batch has 32 returns from 80 orders, compared with eight returns from 160 orders elsewhere. That is a lead, but it isn’t enough to explain the cause. Following the batch’s component lot, DSP-X17, reaches another product: Lyra. Lyra also has elevated returns associated with that lot. The application then compares the pattern across courier groups rather than immediately blaming the shared component. The resulting inspection scope covers 160 orders, including 56 returns, across two products. Those numbers describe the connected group worth investigating. They do not mean that 160 units are defective, or that the component has been proven responsible. That distinction shaped much of the project. Counting returns wasn’t enough One of my biggest learnings was that a convincing-looking number can still be misleading. A batch with more returns may simply have more sales. Looking only at returned orders removes the denominator needed to understand the rate. The graph queries therefore include orders that were not returned. They also use distinct counts to avoid counting an order multiple times while traversing relationships. The same principle applies when connecting products. Sharing a component is common in manufacturing. ReturnTrace checks whether the connected products each show an elevated rate relative to their own comparison groups before strengthening the shared-component lead. The graph finds the connection. The comparisons help decide whether that connection deserves attention. The most useful part was what happened after the investigation Finding DSP-X17 made a good demonstration of graph traversal. But I didn’t want the workflow to end with a finding on a screen. ReturnTrace creates a reviewable inspection task. A person can approve it and record an outcome- confirmed, refuted or inconclusive. That outcome becomes evidence for later investigations. For the demo, I recorded a clearly labeled simulated inspection of 12 units, with zero reproducing the suspected failure. No physical inspection took place. When the product is investigated again, the return pattern remains. The application doesn’t rewrite the historical data. Instead, it recognizes that the inspection challenges the original lead and changes the recommendation to independent review. This became the clearest way to explain the project: New evidence should change a decision without changing the facts that led to the original suspicion. It also made memory more useful than simply saving previous answers. An inspection connected to a shared component can matter when investigating another product that uses it. Giving the model a limited role ReturnTrace uses Groq for language model assisted tool selection. The tools expose scoped graph queries through MCP. I kept the model’s role separate from the numerical calculations and decision rules. It can help select eligible follow-up checks, but it cannot skip the mandatory initial checks. Application code calculates the metrics and applies the evidence policy. This made the results easier to inspect. The interface exposes the tool run log, retrieved source records and relevant queries. I wanted someone reviewing a finding to be able to ask, “Where did this number come from?” and find an answer beyond a generated paragraph. What didn’t go smoothly Local setup took more effort than expected. I initially used Docker, but later ran into a Docker Desktop installation registration problem that prevented the engine from starting. I moved the working demo to FalkorDB Cloud That experience made me appreciate having a cloud option, but it also highlighted how much onboarding depends on clear connection details and useful error messages. Testing was another important part of the process. The project passed 24 automated tests, a real FalkorDB integration check and a four scenario synthetic evaluation Those checks helped verify the intended behavior. They are not evidence of real-world diagnostic accuracy. The dataset was designed for the demo, and a production system would need much broader validation. Building with AI assistance I used OpenAI Codex extensively for implementation, interface design, debugging, testing and documentation. My contribution included choosing and developing the returns-investigation use case, directing the workflow and visual revisions, configuring the services and practicing the demonstration. Working this way made technical understanding especially important. A functioning screen isn’t enough: I need to understand how the graph connects the records, why the comparisons use order denominators and why an inspection changes the recommendation. AI assistance helped build the project, but it didnt remove that responsibility. What I’d improve next The next step would be to test the workflow against a more realistic, permissioned dataset. I would also improve how inspection methods are captured. A small sample that fails to reproduce a problem doesn’t necessarily disprove it. Recording how units were selected, what conditions were tested and who reviewed the result would make the evidence more useful. Any claim about reduced investigation time or fewer returns would need measurement. For now, ReturnTrace demonstrates the workflow rather than claiming those outcomes. Building it taught me that a useful investigation agent needs more than a plausible answer. It needs connected evidence, visible reasoning steps, a human review point and a way to reconsider its recommendation when new information arrives. That is what I tried to build with ReturnTrace.
Top comments (0)