Rescuify

My final-year dissertation, “Decentralized Food Surplus Redistribution Platform using Blockchain and Reinforcement Learning” (Anglia Ruskin University, submitted 22 April 2026, awarded 87%), started from a systems problem rather than from a technology I wanted to use.

Edible surplus and food insecurity coexist in the same cities. The barriers between them are interconnected: manual last-mile routing, spoilage risk during redistribution, weak cold-chain monitoring, donor liability and compliance concerns, thin end-to-end traceability and low recipient trust — and, underneath all of it, fragmentation between the logistics, sensing and trust systems that would have to cooperate.

The product hypothesis was that these are not separable features. Rescuify explored whether routing intelligence, IoT-style condition monitoring and cryptographic traceability could operate as one coordinated cyber-physical platform.

Redistributing perishable surplus is a decision problem under uncertainty where the cost of a wrong decision is not inefficiency but unsafe food. A static plan cannot answer what should happen when a chilled load warms mid-route.

At the same time, none of the logistics intelligence matters if a donor cannot show what happened to the food they gave away, or a recipient cannot check it.

• Surplus is lost while demand for it goes unmet, because coordination cost exceeds value before the food fails.
• Last-mile routing is manual and static, so it cannot respond to changing conditions.
• Cold-chain condition is largely unobserved during redistribution.
• Donors carry liability with no defensible record of handling.
• Recipients are asked to trust an opaque chain of custody.

The dissertation implemented role-based interfaces because each role carries a different task, a different risk and a different trust requirement.

• Food donor — registers surplus; needs confidence around safety, accountability and handoff.
• Driver — receives tasks and routes; needs live condition and risk information while carrying perishable food.
• Recipient — receives food; needs confidence in its condition, history and traceability.
• Administrator — oversees system activity, impact, governance and audit information.
• Wider stakeholders — charities and redistribution organisations, institutional food donors, food-safety and compliance bodies, and researchers or smart-city operators.

Discovery here was research rather than fieldwork: a literature review and an analysis of existing platforms, used to locate system gaps, translate those gaps into stakeholder needs, and then into product requirements before any architecture was drawn.

The dissertation compared Rescuify against Too Good To Go, FareShare and IBM Food Trust on tamper-evident audit trails, RL-based adaptive routing, real-time condition monitoring, institutional redistribution orientation and open-source implementation. Its conclusion was not that any one capability was novel, but that integrating trust, adaptive routing and condition monitoring within a single architecture was.

The constraints below shaped both what the platform had to do and what could honestly be claimed about it.

Each decision below was made against the research question — whether an integrated system could adapt to risk, preserve records and improve simulated diversion — rather than against a feature list.

This distinction is the most important part of the case study. The prototype demonstrated technical feasibility inside a controlled simulation; it did not demonstrate operational or commercial viability.

This was an academic engineering and research project, not a generated app. The architecture, implementation and simulation are documented in the dissertation and built on FastAPI, Stable-Baselines3, Gymnasium, Supabase, OSMnx and related open-source tooling.

Where AI-assisted tooling was used, it was to accelerate parts of the public-facing UI and portfolio presentation of the work. The research design, system logic, experimental setup, interpretation and dissertation are my own.

The dissertation used a four-tier cyber-physical architecture so that presentation, orchestration, intelligence and trust concerns could be developed and evaluated independently before integration.

The trust layer used SHA-256 hashing to produce a tamper-evident audit trail simulating blockchain immutability. Hyperledger Fabric appears in the dissertation only as part of the platform-selection rationale; it was not the deployed trust implementation.

Evaluation was designed around the hypothesis rather than around interface completion. Every figure below is a simulated or prototype evaluation result: no real food was moved, no physical thermal breach occurred, and no charity deployed the system.

What this project demanded of me as a product person, rather than what the product contains.

A technically impressive feature is not useful unless it resolves a stakeholder risk or a job someone actually has.

Routing optimisation for perishables is a safety problem as much as an efficiency problem, and framing it that way changed what I measured.

Simulation is excellent for controlled experimentation and no substitute for live operational validation — the honest position is to say which one you have.

A trust system is only useful when the user can understand what is being verified and why; a hash nobody reads is not trust.

Integrating AI, sensing and auditability creates more product value than three isolated demos, and considerably more systems complexity.

Product credibility improves when limitations are explicit rather than hidden.

Stating these plainly is part of the work. These are the boundaries of what the evidence here can and cannot support.

The dissertation's future-work directions translate cleanly into a product roadmap, and every item on it is aimed at closing the gap between simulated and real evidence.