Inspiration
Max spent his summer doing AI alignment research at MIT. Derek spent his waiting on PO paperwork to get pushed through before he could continue his intern project. Will likes to pretend he's good at abstract math.
Comparing notes, we noticed something: everyone builds AI for shopping, but people like shopping. It's a dopamine hit. The shopping nobody enjoys happens at work: purchase orders, approvals, policy checks and paperwork. A typical PO takes about 2 days to release (APQC), costs $14–54+ to process (APQC), and 18.4% of invoices hit an issue that needs fixing (Ardent Partners). We had the domain experience and the technical know-how to sand that friction off corporate America.
What it does
Papr takes the same kind of formal verification now being used on Millennium Prize problems and points it at a far higher cause: purchase orders.
An employee types what they need, like "a laptop with at least 32 GB RAM under $1,000." Papr then:
- Authorizes the person. A proxy checks their spending limit, approval thresholds, blocked categories and approved suppliers. The CEO goes through; the intern with a $0 limit gets denied, with the reason on record.
- Turns words into math. AI converts the request into checkable requirements (
ram ≥ 32 GB,total ≤ $1,000,product = laptop) and preference weights. - Checks candidate listings against the supplier's own published data, whether the listings come from search or the user's own agent.
- Proves each one with Z3. No counterexample means requirements proven. A counterexample means not met, with the exact reason: "8 GB < 32 GB", or "a stapler is not a laptop".
- Keeps the receipts. Every approval and denial is saved with the requester, the requirements, the evidence and a replayable proof, and finance gets a filterable ledger.
Trust is the point. The AI reads the request; proofs and company policy make the decisions. A fact papr couldn't check never counts as a pass, each company's data stays separate, and papr never approves a payment itself. Our demo uses clearly labeled, simulated supplier listings.
How we built it
Our team primarily used Cursor and Codex to code, but relied on a mixture of pen, paper, Google Docs, and oral tradition to ideate and consolidate ideas.
Under the hood: a FastAPI proxy for authentication, policy and signed handoffs; a FastAPI + SQLite main service for Claude-powered requirement parsing, listing checks and Z3 proofs; OAuth (PKCE) and MCP so personal AI agents can connect; and Node frontends for employees and finance. It's backed by 240+ automated tests.
Challenges we ran into
The biggest challenge was keeping track of all the moving parts of such an expansive system: the proxy for authorization, turning natural language into mathematical conditions (not to mention subjective or vague criteria like "preferably light"), and the search and verification service running on yet another server. Keeping a mental model of the system was hard enough; building it in parallel was even harder.
Accomplishments that we're proud of
In less than 24 hours, we built a real solution to a real problem in a way that hasn't been done before: every purchase decision comes with a proof, and every "no" comes with a reason.
What we learned
There are no peanut butter M&Ms to be found anywhere near the Bill and Melinda Gates Center.
What's next for Papr
Ranking proven candidates with the preference weights we already capture, live supplier search, and a hand-off to payment rails like Visa once a purchase is approved.
...and then a $40 million Cursor acquisition..? 👀👀👀
Log in or sign up for Devpost to join the conversation.