MSC Traceability

Inspiration

Manufacturing traceability often looks complete on a dashboard while the real handoff is still uncertain. A wrong part, wrong lot, skipped process, or delivery recorded too early can create quality risk, rework, and hidden cost leakage.

I wanted to focus on one practical question: how can a system make every part handoff visible, attributable, and difficult to manipulate?

What it does

MSC Traceability is a proof of concept for tracking one manufacturing lot from Production Plan to Customer Received:

Plan → Material Request → Warehouse → Prepare → MC A → MC B → MC C → Final Inspection → Finished Good → Delivery Note → Shipment → Customer Received

Every active step belongs to a specific PIC role. The PIC must scan the expected Plan, Part/Lot, or Delivery Note barcode before the next step becomes available.

The app provides:

• role-based scan tasks for Planner, Warehouse, Prepare, Production, Quality, Customer Incoming, and Admin;
• a visible success popup after a valid scan;
• rejection warnings for wrong barcodes, skipped flow steps, denied device permissions, and invalid customer location;
• three scan retries for each PIC before a transaction is locked;
• Admin-only unlock with a required recovery reason;
• customer receipt validation through Delivery Note scan and browser location; and
• an exportable CSV audit report containing PIC, role, timestamp, scan source, reason, part, lot, and Delivery Note.

How I built it

I started by using the Devpost Learn Skill Pack to define the scope, PRD, and technical specification before coding. Then I used an AI coding agent to turn the workflow into a browser-based proof of concept using HTML, CSS, and JavaScript.

The project intentionally uses local demo data so the full workflow can run without an external database. Camera barcode detection and browser geolocation are used when supported by the device, while clearly marked simulation actions help demonstrate the control flow.

Challenges I ran into

The biggest challenge was keeping the idea focused. A real ERP includes many modules, but building an entire ERP would weaken the demo. I narrowed the project to one reusable control: a handoff should not become a trusted production or delivery record without evidence from the responsible PIC.

Another challenge was balancing protection and usability. Locking the system after one failed scan would create unnecessary Admin work. The final design gives each PIC three attempts, records every rejection, and escalates only repeated failures.

Accomplishments that I’m proud of

I turned a real manufacturing concern into a working, explainable flow instead of only a dashboard mockup. The project shows successful transactions, rejected attempts, controlled recovery, and a clear audit trail.

Most importantly, the app demonstrates that traceability is not only about knowing where a part is. It is about proving who handled it, when, under what role, and whether the next process was allowed to continue.

What I learned

AI coding works best when the workflow and boundaries are decided before implementation. Planning first made it easier to avoid feature overload and to keep the POC centered on one end-to-end outcome.

What’s next

The next version will move users, roles, transactions, and audit records from browser-local data to Google Sheets with Apps Script or a backend service. It will add real authentication, configurable production routes, barcode label generation, and sender-to-receiver verification for every handoff.

Built With

• barcodedetector-api
• codex
• css3
• devpost-learn-skill-pack
• geolocation-api
• github
• html5
• javascript
• localstorage
• openai
• visual-basic