🤓 Latest Submissions
Proofline: Tablekeeper
Inspiration A reservation is a promise. When a table closes before dinner, keeping it may require changing several bookings together. What it does Tablekeeper offers booking, recurring visits, dated policies and a manager's seating-repair preview. Apply moves bookings atomically while preserving guest times and accepted terms. The planner supports six tables, four declared pairs and six considered bookings; every confirmed booking overlapping the closure counts. How we built it Shivam Gupta directed the product and configured Proofline: four BAND seats with generic mandates. Coordinator planned, Engineer and Experience implemented, and Verifier checked committed results independently. One human task covered all four stages. Original commits, handoffs and the full room export are preserved. Challenges Verifier found that a corrupted restore could erase an individually changed recurring booking's permanent exception. It rejected the candidate; Engineer repaired history validation and independent rechecks passed. A daemon interruption required an operator restart of the same seats and room, with new provider sessions. No new task or implementation hints were sent. Accomplishments All four stages were accepted. Workspace and fresh-clone isolated runs each passed 120, 145, 152 and 158 required checks for stages one to four, including inherited suites. These are check executions, not distinct requirements. Published tests are partial; hidden-suite success is not claimed. What we learned Independent review matters after public tests pass. The frozen service has ephemeral state and judge controls, so it is not a public production deployment. Provider-billed spend is unknown.
6 Oct 2026
UndoProof: prove the way back
A deployment can pass every forward test and still have no safe way back. A renamed column can break the previous application version. A rollback script that restores yesterday's table can quietly erase orders placed after today's deployment. The script succeeds, but the business loses data. UndoProof improves the developer workflow between a migration pull request and release approval. A developer supplies a small release contract: synthetic seed data, forward and rollback SQL, old and new query contracts, representative writes, and a canonical data invariant. UndoProof executes the rehearsal in isolated PostgreSQL databases powered by PGlite. It checks compatibility with the previous application contract, exercises rollback after new writes, compares the customer-visible data, and attempts the migration again. The interface connects each result to the executed SQL, database errors, and before-and-after rows. A developer can inspect the failure, export an evidence packet, and hand IBM Bob a repair prompt grounded in the actual contract and result. The supplied scenarios include a destructive rename, a rollback that loses new orders, and an additive migration. A repair preview makes the change reviewable before another run. The same engine supports a command-line release gate. The key distinction is the data that arrives between deployment and rollback. Reversing a schema does not automatically preserve that data. UndoProof makes the missing check visible and repeatable. A safe application rollback can retain a compatible expanded schema instead of destructively reversing it. Shivam Gupta created UndoProof for the IBM Bob 2.0 Hackathon. The initial commercial audience is a platform or engineering lead at a SaaS company that ships relational database changes regularly. An MIT local runner provides a low-friction starting point. Retained evidence, shared release policies, and private runners are the proposed paid offering, subject to customer validation. The prototype uses original synthetic data and needs no database credentials or paid inference API for rehearsals. Results establish what happened for the supplied SQL contracts and fixtures. They do not establish full application behavior, production lock safety, concurrent transaction behavior, or complete production parity.
27 Sep 2026
Benchback: From parts shelf to paid back
An old alternator on a shop shelf can still be worth money. Repair shops pay refundable core deposits when buying remanufactured parts, but recovering them requires the right purchase, packaging, deadline, and supplier credit. Benchback connects those steps. A technician talks to the AssemblyAI Voice Agent API while holding the part. The agent checks job, invoice, purchase line and part identifiers, asks about condition, and reads the supplier policy attached to that purchase. It checks approved packaging alternatives and records reported evidence. Typed tools create an inspection draft; only the human can confirm the match, approve a return, or post a credit. The demo follows a fictional $240 deposit. A $200 credit leaves $40 unresolved. Only another credit or an explicitly accepted deduction closes the balance. Return packets, CSV imports, correction history and a credit ledger make this a working operations desk. Built by Shivam Gupta with React, TypeScript, Firebase Authentication, Firestore, Cloud Run and AssemblyAI. The voice stack uses short-lived tokens, audio streaming, interruption handling and server-validated tools. Transactions protect against duplicate credits and competing edits. The hardest lesson was keeping reported observations separate from verified financial evidence. The business hypothesis is $99/month for independent repair shops with an unreliable core-return process. Existing shop platforms already track cores; our proposed advantage is hands-busy capture and clear credit follow-up. Pricing and demand need customer validation. Next: timed shop pilots comparing voice with a short form, then supplier-specific imports. Test at benchback-ai.web.app: Sign in, Try a private guest workspace, then Load practice purchases. Open WO-418 and use voice or the form. All example companies and amounts are fictional. Benchback does not contact suppliers, buy shipping or guarantee refunds.
30 Sep 2026
Granted Robotics: Permission Before Motion
Inspiration A cup moves. A grasp slips. A successful demo no longer tells us what happens next. Granted Robotics makes that missing recovery evidence visible. What it does A hosted workbench for robotics integrators: inspect a two-arm table-setting plan, inject failures, execute real SO101 MuJoCo simulation, compare recovery on and off with the same seed, and export results. Guest access works immediately; Firebase accounts are optional. How we built it Shivam Gupta built Granted with AI assistance using React, TypeScript, FastAPI, MuJoCo and OpenVINO. A constrained OpenAI planner validates language against an actual rendered camera frame. A small imitation policy trained on 480 examples, with 120 held out, proposes joint targets through OpenVINO. Numerical correction remains mandatory. Firebase hosts the interface and Cloud Run executes simulation. Challenges we ran into A convincing animation is not physics evidence. We separated the illustrative browser view from real execution, camera input, measurements and downloadable traces. The prototype uses assisted grasps and ground-truth poses. It is not a certified safety system or an end-to-end VLA. Intel Core Ultra access is pending review; hardware validation is incomplete. Accomplishments that we're proud of 50 simulations across 10 randomized seeds: grip-loss recovery completed 10/10, versus 0/10 without recovery. Mean cup error was 14.05 versus 160.96 mm. Learned initialization reduced numerical iterations 5.3% in paired trials. All 29 regression tests and five deployed API checks passed. What we learned Recovery needs reproducible evidence, not just a success rate. What's next Our first customer hypothesis is an integrator turning recurring failures into regression tests. A paid pilot would measure diagnosis time saved. Next: broader tasks, end-to-end VLA control and Core Ultra validation. Pricing and demand remain hypotheses. Coherent evidence is the product.
16 Sep 2026
