Batchloom

Private AI turns maker requests into reviewed small batches, with conditional PayPal reservations.

Comment

Inspiration

For an independent printmaker, a few enthusiastic messages can look like a production order. Then the details disagree: different colors, an unclear count, a total budget mistaken for a unit price, or a deadline the maker cannot meet.

Batchloom explores the gap between that scattered interest and a buyer's actual permission to pay. The question is specific: can a maker assemble one considered production run while keeping the original intent, human decisions and payment state understandable?

What it does

Batchloom is a production desk for a fictional risograph notebook studio.

The request library offers three working contexts: a writing circle, a vermilion print workshop and a bookshop restock, with 24 original fictional requests in total. Each context includes clear interest, conflicting terms and incomplete details. Search, sorting and status filters surface what needs attention; separate tab-local drafts retain edits across context changes and reloads, while restored inputs always require fresh analysis and review. Distinct generated scenes establish each context, and the collection register and payment journal show actual ledger state and next actions.

A maker reviews synthetic customer requests with local AI assistance. The model proposes the product, quantity, colorway, explicit per-unit budget and date, alongside quotations from the source. The interface puts those words next to the interpretation so a person can inspect it. Missing or incompatible details can be held for review rather than treated as confirmed demand.

The maker then approves one fixed collection: $24.00 per notebook, a minimum of 12 units, a visible capacity and a 48-hour reservation window. Expressions of interest are kept separate from payment authorizations.

Buyers receive a public reservation page. They choose a quantity, review the exact amount and approve their own PayPal sandbox hold. An authorization is not a charge. The maker manually starts settlement; only provider-confirmed payment records count. The journal distinguishes captures, cancelled holds, refunds and outcomes that still need reconciliation.

How it was built

The browser interface uses React and TypeScript with a restrained paper-and-ink visual system. Decorative product photography, paper button textures and the studio stamp were generated for this fictional collection.

Qwen3 runs through WebLLM in a browser worker. It downloads model assets on first use and needs a compatible WebGPU device. There is no paid cloud AI key or cloud inference fallback. In the local-model publishing flow, original messages and evidence quotations stay in the browser; the server receives the maker's approved product terms, model identifier and aggregate counts.

Application rules remain outside the model. The server validates fixed terms, capacity and timing. Browser analysis is self-reported, not a server-attested fact, and it never grants payment permission.

PayPal's sandbox Orders API creates AUTHORIZE orders. The server records authorization and settlement operations in a versioned Cloudflare D1 journal. Capture, void and refund paths use reconciliation and stable operation identifiers where supported, so an interrupted response is treated as uncertain instead of automatically becoming success or a fresh transaction.

What is working

A verified workflow on the public site connected actual local model output to payment on the same collection. Qwen3 analyzed eight synthetic requests and identified three compatible requests totaling 12 potential units. The observed desktop run took 74 seconds including loading; this is one device measurement, not a speed guarantee.

After source-evidence review and explicit maker approval, that collection opened with zero reservations. One buyer then approved a PayPal sandbox authorization for 12 notebooks at $24.00 each. Maker-initiated settlement on the same collection reached COMMITTED with $288.00 captured, and the reserving buyer’s refreshed receipt showed the completed sandbox charge. Twelve units do not imply twelve customers. The authored illustrative sample remains distinct from actual model output.

The public demonstration is a fictional-product, test-environment integration. It establishes this observed workflow, not revenue or a production reliability guarantee.

Challenges and limits

A small local model can misunderstand language even when its output is valid JSON. Exact quotations help a reviewer investigate a claim; they do not prove that every negation, ambiguous count or instruction attack was understood. On six unseen synthetic English requests, four complete records were correct and two were held for review. No incorrect non-null field survived whole-record validation in that small test. These counts do not establish general accuracy, production safety or Korean-language support.

Payment operations also do not succeed atomically across separate buyers. Recovery logic includes releasing holds and refunding completed captures after partial failure, and unresolved outcomes remain visible. A controlled deadline test also confirmed an actual PayPal sandbox void and a subsequent VOIDED lookup, without capture. The deadline was advanced in an isolated in-memory ledger; no real 48-hour wait or application database change occurred. A separate controlled external-invalidation recovery test then confirmed an actual sandbox refund: after a first capture completed, the harness voided a second authorization and the original settlement engine refunded the completed charge. Provider lookups confirmed the capture as REFUNDED, the refund as COMPLETED and the other authorization as VOIDED. This used a real clock and an isolated in-memory ledger without changing the application database; it was not a full application UI refund workflow.

The prototype uses synthetic people and products. Nothing is manufactured or shipped, settlement is initiated manually, and compatible desktop graphics hardware is required for local AI.

Lessons from the build

The most important boundary is between interpretation and permission. A plausible AI summary cannot authorize a purchase. A browser redirect cannot prove payment success. And a missing provider response cannot prove that nothing happened.

Making those boundaries visible became part of the product, not just its backend.

What's next

Expand the published model evaluation with more independent requests, Korean cases and required abstentions. Exercise end-to-end UI recovery and a wider range of provider failures. Improve clarification and correction workflows, then study the process with consenting makers before considering real inventory or live payments.

Workspace refinement

The live workspace and the newest gallery image include the expanded request library and tab-local drafts. The video preserves the earlier recorded interface and the verified same-collection AI-to-PayPal Sandbox workflow. Raw draft text is saved in tab-scoped browser storage; it is not application-encrypted and can be cleared from the Studio guide. Use fictional data only.

Share this project:

Updates

Submission history