Inspiration
I built TraceShield because I became interested in what happens after a supply-chain incident is discovered. Traditional traceability can show where a product has moved, but during a recall, knowing the movement alone is not enough. I wanted to explore a more practical question: where should action be taken first, and how confident are we in the evidence behind that decision? That led me to the idea of combining supply-chain tracing, evidence verification, and risk analysis into one investigation workflow.
What It Does
TraceShield is a supply-chain intelligence platform for precision recalls. It allows me to:
- Trace affected batches through their supply-chain movements.
- Visualize relationships between manufacturers, distributors, retailers, and other locations.
- Calculate affected and downstream quantities.
- Identify evidence gaps and anomalies in the event chain.
- Generate deterministic SHA-256 hashes for critical custody events.
- Inspect the integrity and verification state of supply-chain evidence.
- Calculate Exposure Risk separately from Evidence Confidence.
- Prioritize incidents using states such as Immediate Recall, Urgent Investigation, Monitor, and Verify Evidence.
The core workflow is: Incident > Trace > Verify > Assess > Prioritize
How I Built It
I built TraceShield as a React + TypeScript application using Vite and TanStack Router, with Firebase repository support for data persistence. I built the investigation engine to process events such as shipping, receiving, storage, sales, and returns. Instead of simply following links between events, it calculates inventory flow and keeps track of accounted and unaccounted quantities. I then built the investigation graph using React Flow so that I could inspect supply-chain relationships visually and drill down into individual custody events. For evidence integrity, I implemented canonical event hashing with SHA-256. The hashing process produces deterministic hashes from the relevant event data, allowing changes to that data to be detected. I also designed the Web3 layer so blockchain anchoring can be performed without exposing private keys in the browser. The frontend uses read-only verification, while transaction signing is separated into a controlled environment.
Challenges I Ran Into
One of my biggest challenges was handling incomplete or inconsistent supply-chain data. A missing event should not automatically be treated as proof that a product disappeared or reached a particular destination. I therefore built the inventory-flow logic to track accounted and unaccounted quantities and surface evidence gaps instead of inventing information. Another challenge was designing the risk system so that exposure and evidence quality were not treated as the same thing. I separated the two scoring systems so that a potentially serious incident with weak evidence can trigger an investigation rather than being treated as fully confirmed. I also had to rethink the original Web3 implementation because signing transactions directly from the browser would create a serious security problem. I moved private-key operations outside the frontend and kept the browser-side verification read-only. Finally, I had to build, test, and deploy the project under a very limited hackathon timeline, which forced me to focus on the core investigation workflow rather than adding features simply for appearance.
Accomplishments I'm Proud Of
I'm proud that I was able to take the idea from concept to a working deployed MVP as a solo builder. I implemented and tested the core recall and exposure engine across multiple scenarios, including inventory accounting and evidence gaps. I also built the interactive supply-chain investigation graph and integrated event-level evidence inspection into it. Another accomplishment I'm particularly proud of is the cryptographic verification layer. Rather than claiming blockchain functionality that I could not actually verify, I implemented deterministic SHA-256 evidence hashing and designed the Web3 architecture around a secure separation between frontend verification and transaction signing. Most importantly, I was able to turn what started as an idea about supply-chain traceability into an end-to-end investigation workflow that can actually be demonstrated.
What I Learned
The biggest lesson I learned is that traceability is not the same as certainty. Having a record of where something moved does not automatically mean every part of that record is complete or trustworthy. Missing events, broken links, duplicated records, and inconsistent quantities all affect how much confidence an investigator should have. I also learned a lot about designing systems around security boundaries. Web3 functionality is not simply about connecting a wallet or sending a transaction. Where signing happens, where private keys live, and what the browser is allowed to do matter just as much. Building TraceShield also reinforced the importance of testing the underlying logic rather than relying on a UI that appears to work.
What's Next for TraceShield
The next stage is to move TraceShield from a hackathon MVP toward a production-ready system. I want to expand the real-world data and integration layer, strengthen the Web3 anchoring infrastructure, and connect TraceShield to more realistic supply-chain data sources. I also want to explore AI-assisted investigation more deeply, particularly using AI to help investigators interpret complex evidence, explain why an incident received a particular priority, and surface relationships that may deserve human attention. The long-term goal is to make TraceShield a system that does more than answer "Where did this batch go?" It should help answer: "Where should I act first, what evidence supports that action, and how confident should I be in the decision?"
Log in or sign up for Devpost to join the conversation.