Reclaim

• 

  Inspect confirmed item facts and each buyer's full purchase total: Alice's desk and lamp cost $72; the missing monitor share is $80.

• 

  Fresh inventory and buyer requests form a complete allocation: $72, $48 and $80 cover the $200 bundle, including preparation.

• 

  Each order has its own price, capture reference, pickup code and downloadable receipt. This screenshot uses labelled simulated payments.

• 

  Labelled failure simulation: refund the completed capture, void remaining authorizations, and block pickup until recovery finishes.

• 

  An individual receipt, pickup code and payment mode on mobile. Buyers can record an issue without an automatic refund promise.

• 

  Alice needs a desk and lamp; Ben needs a chair. Reclaim shows the missing monitor buyer and its $80 share, with confirmed item facts.

• 

  Actual SOCLAAS extraction and reviewed buyer needs complete this fictional $200 bundle. Payments remain labelled simulations.

• 

  Actual SOCLAAS calls show qwen3.6:35b, response IDs, prompt versions, latency and token usage. Provider cost remains unmeasured.

• 

  Actual sandbox expiry: Alice's $72 authorization was voided, with no capture. PayPal's API independently confirms VOIDED.

• 

  Three distinct sandbox buyers approved $72, $48 and $80. PayPal confirms three COMPLETED captures; the $200 group is paid.

• 

  After seller preparation, Chen's actual $80 sandbox receipt shows its capture reference, pickup code and downloadable payment mode.

• 

  Cancelling before pickup produced three full sandbox refunds totaling $200. PayPal confirms COMPLETED refunds and REFUNDED captures.

Inspiration

A student furnishing a room might find a good moving-out bundle containing a desk, lamp, chair and monitor, while only needing the desk and lamp. The seller wants to clear the entire lot. The buyer has to stretch their budget, organise a group manually, or walk away.

Reclaim explores a marketplace built around complementary demand: several people can buy different goods from the same larger offering.

What it does

Sellers describe a divisible bundle, review extracted inventory, confirm its attributes, and agree to separate fulfillment. Buyers describe what they need and confirm their budget, quantities, attributes, pickup location and deadline.

Reclaim solves for a complete allocation. It explains what blocks an incomplete group, such as a missing monitor buyer. When the group becomes feasible, each participant reviews an immutable proposal showing their exact goods and price. Prices follow disclosed seller-confirmed reference weights, with deterministic cent rounding.

Each buyer has an individual purchase from the same cooperating merchant. The PayPal sandbox adapter uses authorization before capture: Reclaim checks that all buyers and the seller have accepted, all required authorizations are ready, inventory is still valid, and the checkout window has not expired. A deal is paid only when every capture is confirmed complete.

The seller then prepares separate orders. Buyers receive individual receipts and pickup codes, and can report a problem. If a deal fails, the backend reconciles uncertain outcomes, refunds completed captures, and voids remaining authorizations before releasing inventory.

Furniture, creator equipment and divisible sealed bulk goods use the same allocation and payment engine.

How we built it

React, Vite and TypeScript provide the marketplace, seller review, buyer review, checkout, and order workspace. FastAPI and Pydantic validate API commands. SOCLAAS supplies text/image inventory extraction and buyer interpretation through the OpenAI Python SDK's Chat Completions API. Its requested default alias returned qwen3.6:35b in the verified runs. JSON mode is followed by local schema validation. An optional OpenAI Responses adapter remains available. Seller and buyer confirmation establish usable facts; model suggestions alone do not satisfy hard constraints.

Google OR-Tools CP-SAT solves integer quantity assignments with complete-request, inventory, attribute, budget and fulfillment constraints. A separate invariant validator recomputes the published allocation and price split.

The PayPal JavaScript SDK handles buyer approval. Server-side Orders v2 and Payments v2 handle authorization, capture, void and refund. Stable request identifiers, persisted operation outcomes, verified webhook receipt and a durable job outbox support recovery and restart. PostgreSQL supports row locking; SQLite is the single-process local development adapter.

The repo contains a Python launcher for the downloadable build, Docker and Render deployment configuration, full local setup instructions, seeded judge scenarios, and focused automated verification. The download bundles the compiled frontend so judges do not need Node or Docker.

Challenges

Matching attractive items individually doesn't prove that an entire lot can be sold. Complete requests, confirmed attributes, quantity limits and deterministic cent rounding must all agree. We kept that computation separate from AI language interpretation and checked solver outcomes independently.

Separate buyer payments are not atomic. A successful authorization can still fail at capture, and a lost response does not mean a failed payment. The recovery workflow preserves uncertainty until the provider outcome is resolved and keeps fulfillment blocked while refunds or voids remain incomplete.

Accomplishments

The local end-to-end walkthrough covers fresh buyer requests, complementary allocations, participant review, coordinated payments, individual receipts and pickup. Actual PayPal sandbox checks confirm three distinct buyer authorizations and captures at $72, $48 and $80; a $72 authorization was automatically voided after an incomplete group's deadline; and cancellation before pickup completed three full refunds totaling $200. Provider API reads independently confirm these outcomes. Partial-capture failure and completed pickup walkthroughs remain explicitly simulated. Focused tests exercise allocation invariants, concurrency, stale proposals, timeouts, partial capture, refunds and restart behavior.

Local application checks pass 46 tests with one PostgreSQL-only skip, including 13 AI provider-contract checks. Twelve additional checks verify the evaluation grader. PostgreSQL and Docker checks run in GitHub Actions. Browser checks include an entirely fresh seller listing and three fresh requests, all three example categories, partial-payment recovery, receipt export and independent pickup completion. Actual SOCLAAS extraction from a fictional illustration and fresh buyer interpretation also produce a complete $72 / $48 / $80 allocation after review.

The text development set contains 30 synthetic listings and 60 synthetic requests, with agent-authored labels kept out of the runtime prompts. SOCLAAS returned 90/90 validated responses at 96.48% proposal-field precision, 94.88% recall and 70/90 exact cases; median/p95 model-call latency was 1.54/2.99 seconds. The probes informed schema clarification, so these are development results, not untouched held-out accuracy or usable confirmed-fact precision. Independent labels, representative real photographs and human sessions remain pending.

Current status: actual SOCLAAS text/image input and PayPal sandbox authorization, capture, expiry void and full refund are verified. Seller preparation and Chen's individual sandbox receipt/export are also verified. A local test build passed a fresh-environment walkthrough through all three simulated pickups. Paid hosting is deferred. Merchant-dashboard review, signed webhook delivery and actual collection remain unverified. The public demo combines fresh app footage with the original presenter recording. Seller review includes a labelled screenshot detail; capture and receipt screenshots come from the independently verified PayPal sandbox run. Payment failure, delayed refund and lost-response scenes are explicitly labelled simulations. Historical gallery payment screenshots retain simulation labels. The examples are fictional fixtures and do not establish real seller consent or user demand.

What we learned

The useful AI contribution is finding purchase opportunities inside a larger offering and making unmet demand understandable. The transaction still needs exact, inspectable terms, independently checked allocations, and honest payment states.

What's next

Pilot the workflow with students furnishing rooms, creators assembling equipment, and sellers clearing mixed inventory. Measure seller preparation costs, task completion, buyer affordability against equivalent alternatives, and fulfillment outcomes. Broader merchant onboarding, delivery, and transferable service units follow after that evidence.

Built With

• docker
• fastapi
• openai
• or-tools
• paypal
• postgresql
• pydantic
• python
• react
• sqlalchemy
• typescript
• vite