RescueLoop

Inspiration

Surplus food and a receiving organization can be close to each other, yet a pickup still depends on receiving hours, storage, dietary constraints and someone taking responsibility for the handoff. RescueLoop focuses on that coordination problem for campus dining teams, pantries and community partners.

What it does

RescueLoop is a publicly hosted application with independent email/password accounts. Each account manages a donor, receiver or combined organization profile. Organizations opt into directory discovery, request partnerships and accept connections by mutual agreement.

Donors add surplus manually, import CSV inventory, or ask IBM watsonx.ai to structure an inventory note. Every extracted or imported batch starts as an unverified draft. A person checks the quantity, dates, location, storage, dietary labels and declared allergens before publishing it.

The receiver sees transparent eligibility reasons for a batch, requests it, and waits for donor approval. Approval rechecks availability and atomically reserves the batch and receiving capacity. The two organizations coordinate through a private pickup conversation and in-app notifications. The receiver confirms collection after the agreed pickup window starts, producing a receipt and an impact record.

How we built it

The application uses TypeScript, React, Vinext/Vite and Cloudflare Workers, with shared D1/SQLite storage and Zod validation. Independent credentials use salted scrypt hashes, while random session tokens are stored as hashes and sent in secure HttpOnly cookies. The server checks roles, organization ownership, input schemas and workflow state.

IBM Cloud IAM authenticates the server to watsonx.ai. The configured ibm/granite-4-h-small model extracts explicit inventory facts into JSON, which the application validates. Model output cannot verify food, publish listings or approve pickups. Only the deliberately submitted note is sent for extraction, and API credentials remain server-side.

Eligibility uses visible application rules: an accepted partnership, verified available food, compatible storage and categories, declared diet and allergens, enough remaining daily capacity, and at least 15 minutes of receiving-window overlap. D1 transactions and conditional updates protect reservations when requests happen concurrently.

Challenges we addressed

The hardest workflow issue was preserving the distinction between a request, an approved reservation and a confirmed collection. Capacity must be checked again at approval, including commitments from other donors. Receiving windows also need the receiver's time zone rather than a fixed UTC offset. Separating those rules from AI extraction made the decisions easier to inspect and test.

What we verified

All 35 automated tests passed in the final check, alongside TypeScript checking and the production build. The public application also completed a synthetic two-account workflow covering sign-up, sign-in, partnership acceptance, live IBM extraction, a pickup request, donor approval, private messaging, notifications, receiver confirmation and a persisted receipt. Duplicate collection was rejected. The temporary QA accounts and related records were removed afterward.

Responsible AI and impact

People review source facts and approve handoffs. Unknown allergens stay in review. RescueLoop does not certify food safety or decide who qualifies for assistance, and it does not need beneficiary personal information.

Impact counts donor-reported batch weight only after receiver-confirmed collection. Estimated meal equivalents use floor(collected kg / 0.5), with the 0.5 kg assumption clearly labeled as illustrative. Synthetic records demonstrate functionality, not real-world food recovery, actual meals served or emissions savings. A campus pilot still needs partner consent, handling procedures and validated measurement.

Current limits and next steps

Resend email verification, expiring reset links and opt-in notification delivery are implemented. The current deployment uses owner-only email test mode because a sending domain has not been verified. Other users retain in-app notifications and recovery codes. SMS and push are not implemented.

Organization affiliation is self-reported, each account manages one organization, and matching allocates whole batches. Institutional onboarding, a verified email domain and a measured campus pilot are the next steps. Route planning and dispatch remain future work.

Try it

Live shared application: https://rescueloop-live.rescueloop-campus.workers.dev/

Instant sample walkthrough: https://rescueloop-live.rescueloop-campus.workers.dev/demo

The /demo route uses isolated browser-local sample data and an offline parser. It provides an immediate concept walkthrough without account setup. The live application at the main URL provides independent accounts and the verified IBM integration. Use separate browser profiles for donor and receiver accounts when testing the full shared workflow.

AI development disclosure

Codex assisted with design, implementation, testing and documentation. The team remains responsible for understanding and validating the submitted work. IBM watsonx.ai performs the configured inventory extraction. We do not claim IBM Bob use.