Pramana

Open sourceFull-stack prototype

Traceability prototype for the Ayurvedic herb supply chain. Farmers register geotagged harvest batches, supply-chain actors append custody events, and every event is SHA-256 hash-linked to the one before it, so anyone who scans a batch's QR code sees its full journey on a timeline and a map, together with a check that the chain is unbroken.

View Source Code

hash-linked chain of custody: SHA-256
farmer, transporter, manufacturer: 3 roles
public verification, no sign-in: QR

Tech stack

Next.js 13 (App Router)
TypeScript
Tailwind CSS
shadcn/ui
Leaflet
SHA-256 (Node crypto)
bcrypt
QR codes

Overview

Ayurvedic products depend on where and how their herbs were grown, but that history is usually lost somewhere between the farm and the shelf. Pramana (Sanskrit for "proof") records it as a chain of custody: a farmer registers a harvest with GPS coordinates, soil type and organic certification, and everyone who handles the batch afterwards adds an event with their own location, checkpoint and notes.

Each event stores the hash of the event before it, so the history behaves like a ledger: removing or reordering a step breaks the chain. A public batch page, opened from the batch's QR code, shows the journey as a timeline and a map and verifies the chain before marking it as trusted. The ledger is deliberately simulated, with SHA-256 hash links and generated transaction ids, to prove the workflow before committing to a real blockchain network.

What it does

Lets farmers register herb batches with live GPS coordinates, harvest date, quantity, soil type and organic certificate number
Generates a QR code for every batch that opens its public traceability page
Lets transporters record pickup, transport and quality-check events with location, vehicle, checkpoint and condition notes
Enforces role permissions on the server, so each actor can only record the event types that belong to their role
Links every event to the previous one with a SHA-256 hash and verifies the chain on the public page
Shows the batch's journey as a step-by-step timeline and a Leaflet map connecting every recorded location

Technical breakdown

Application

Built on the Next.js 13 App Router with TypeScript, Tailwind CSS and shadcn/ui. Each role has its own dashboard, protected by middleware that requires a session cookie, while batch pages and the API stay public so a QR scan works for anyone. Passwords are hashed with bcrypt. Dashboards use the browser's Geolocation API with permission tracking and a manual-coordinates fallback, and the journey map loads react-leaflet on the client only, avoiding server-rendering issues.

Integrity layer

Each event is assembled from its actor, type, location, timestamp and metadata, then hashed with SHA-256 together with the previous event's hash, so every record commits to the entire history before it. Batches also carry a root hash of the original harvest record. A verification endpoint walks the chain and returns whether it is continuous and, if not, the index where it breaks. Records are stored as JSON files and each event is logged as a simulated transaction with a generated id, which keeps the prototype self-contained.

Technical challenges

01
Making tampering visible
A supply-chain record is only useful if changes to it can be detected. Hash-linking each event to its predecessor means a removed or reordered step breaks the chain, and the verification endpoint reports exactly where, so the public page can flag a broken history instead of quietly displaying it.
02
Trust boundaries between roles
A transporter must not be able to record a harvest, and a farmer must not be able to mark a batch as processed. Permissions are checked in the API against the stored user's role rather than in the UI, so a forged request is rejected with a 403.
03
Capturing location in the field
Location is the core of every event, but browsers expose GPS only on secure origins and only after the user grants permission. Dashboards track the permission state, explain what is needed and fall back to manually entered coordinates, so a denied prompt never blocks the workflow.
04
Public verification without accounts
Consumers scanning a QR code should not need an account. Middleware protects only the role dashboards and leaves batch pages and the API open, so verification works for anyone with the link.

Who it is for

Ayurvedic brands, farmer cooperatives and regulators exploring farm-to-shelf provenance, and consumers who want proof of where a product's herbs came from.

Learnings

A hash-linked log makes a supply-chain history tamper-evident without committing to a blockchain on day one
Enforce permissions on the server; the UI should only reflect them
Keep authentication for the people who write records; verification pages should be public
Location capture needs a graceful path for denied permissions
Proving the workflow on a simulated ledger first keeps the choice of chain open

Next steps

Recompute each event's hash during verification, not only check that the links match
Replace the JSON file storage with a database
Signed, expiring sessions instead of a plain session cookie
Finish the manufacturer flow: product creation and product QR pages
Anchor batch root hashes on a public blockchain network

Next projectLighterPulse