Inspiration
A convincing recommendation is not permission to spend. An AI purchasing assistant might choose useful-looking products while missing a seat, overlooking an exclusion, or exceeding the budget. I wanted the buyer to see exactly where a recommendation meets the brief—and where it does not—before any payment begins.
ClauseCart explores a practical question: can AI make a purchase easier to understand while the person keeps control of the decision?
What it does
A buyer describes a team's needs, sets a USD ceiling and seat count, and chooses required product categories. The AI planner proposes a basket from a small fictional catalog and explains its tradeoffs. Independent server rules calculate prices and check the budget, required categories, seats and exclusions.
The buyer can edit the proposal and immediately see the checks rerun. Failed conditions block checkout. When the buyer explicitly approves a valid basket, the application binds that approval to its exact contents and freezes it for checkout.
PayPal sandbox then handles buyer approval. On return, ClauseCart retrieves the actual order, verifies it against the approved basket and requests capture only when the checks agree. A downloadable decision receipt connects the original conditions, chosen products, approval and confirmed payment result. Repeated requests reconcile the same order instead of starting another purchase.
The responsive interface makes the proposal readable as an itemized receipt, with visible constraints and a clear approval boundary. Complete light and dark appearances follow the system initially and remember the buyer's choice.
How we built it
The application uses Node.js, built-in SQLite and native HTML, CSS and JavaScript, with no runtime npm dependencies. A configurable OpenAI-compatible HTTP model endpoint returns a structured recommendation. The model receives the brief and demonstration catalog; it receives no payment secrets or tools. Application code validates its response independently. The free local path is verified with Ollama and qwen2.5:7b: a fresh call through the application adapter produced a $108 four-seat basket that passed all seven checks.
The PayPal adapter implements sandbox OAuth and Orders v2 creation, retrieval, approval redirects, capture and reconciliation. Prices use integer cents. A SHA256 fingerprint binds approval to the brief and basket. Session isolation, CSRF checks, explicit trusted return addresses and deterministic request identifiers protect the workflow.
AI assisted development across research, architecture, implementation, testing, interface work and documentation. The running application also uses AI to recommend products. Human approval remains a separate, explicit step.
Challenges we ran into
The difficult part was preserving the meaning of an approval across edits, redirects and uncertain network responses. A persuasive model explanation cannot substitute for an authoritative price check, and arriving back from PayPal cannot substitute for checking the provider's order state. We separated recommendation, validation, approval and payment into distinct states and tested invalid recommendations, stale approvals, repeated requests and changed provider orders.
We also made incomplete setup and failed requests usable: manual planning remains available, local rehearsal is clearly labeled, and a return in another browser explains the missing basket without disabling new planning.
Accomplishments that we're proud of
An actual AI recommendation produced a $108 basket for four volunteers within a $120 ceiling and passed all seven independent checks. A real PayPal sandbox order was created and retrieved. Capture was blocked before buyer approval; after approval, PayPal confirmed a completed USD 108 sandbox capture. The receipt can reconcile that completed order without another capture.
The demonstration shows real browser interactions, explicitly labels the saved actual AI result and rechecks the existing provider order. Both appearances, keyboard theme switching, remembered preferences, phone layouts, failed budgets and receipt states were exercised. Automated accessibility checks found no WCAG A/AA violations in the tested states; these checks do not replace assistive-technology testing.
What we learned
The useful role for an AI purchasing assistant is to make options and tradeoffs easier to review. Spending authority belongs in explicit product rules and a person's decision. Provider reconciliation, retry behavior and clear failure states matter as much as the recommendation itself.
This project also deepened my interest in backend engineering: designing a trustworthy state transition is a substantial part of making an AI feature useful. Working through the full application reinforced the value of understanding AI alongside the systems that constrain and verify it.
What's next for ClauseCart
The next test is a supervised purchasing exercise with realistic briefs and deliberately unsuitable suggestions. We would measure whether people identify mismatches before approving and whether the server catches numerical violations. No user study or purchasing-savings claim has been established.
This build uses fictional products and sandbox test money only. Real fulfillment, inventory, taxes, refunds, subscriptions, webhook reconciliation and authenticated multi-user operation are outside its current scope. Those capabilities would need deliberate implementation before a real merchant deployment.
