06
The platform build
While the retail question was being researched, the software it would need was built by one principal over 76 days and tested to destruction.
The platform is a production-grade payments and inventory system: 173 commits from April 30 to July 14, 2026; 57 API route handlers; 20 database tables, every one carrying row-level security; 48 schema migrations; 44 automated regression suites.1 It ships four ways to move money: a code-confirmed shopper checkout, a cash and external-card walk-in register, tap-to-pay through a card processor’s terminal rails, and an unattended charge-on-exit loop for a store with nobody in it.
Money state machines, built for missing webhooks
The design assumption throughout: the network is unreliable and event delivery is optional. Every money mutation takes a mandatory idempotency key through a reserve-then-complete envelope; every webhook is deduplicated by event identity; and a reconciliation job converges any stuck payment or refund against the processor’s truth through the same idempotent operations, so webhook delivery is a latency optimization rather than a correctness dependency. Refunds on the terminal path are two-phase and confirmed by event, with an atomic claim so two concurrent refund attempts cannot both fire.
That posture was then attacked on purpose. Nineteen adversarial scenarios, 71 checks: oversell races, idempotency storms, duplicate-webhook floods, cron-versus-webhook finalize races, decline storms with inventory restore, out-of-order refund events, reconciliation cap saturation. All nineteen held. The destruction pass surfaced exactly one real defect, an idempotency key that leaked across two transactions; it was fixed and the pass re-run clean.2
| # | Scenario | Suite | Result |
|---|---|---|---|
| A | Oversell race | local concurrency | held |
| B | Idempotency storm | local concurrency | held |
| C | Rate-limit burst | local concurrency | held |
| D | Concurrent refund | local concurrency | held |
| E | Checkout key storm | local concurrency | held |
| F | Refund-initiate storm | live payment rails | held |
| G | Cron ∥ webhook race | live payment rails | held |
| H | Duplicate webhooks | live payment rails | held |
| I | Persist-race adopt | live payment rails | held |
| J | Decline storm | live payment rails | held |
| K | Webhook-drop converge | live payment rails | held |
| L | Cron-only backstop | live payment rails | held |
| M | Rate-limit isolation | live payment rails | held |
| N | Reconcile cap | live payment rails | held |
| O | Cross-path collision | live payment rails | held |
| P | Pending refund arc | live payment rails | held |
| Q | Out-of-order events | live payment rails | held |
| R | Two-cron race | live payment rails | held |
| S | Key reuse across transactions | live payment rails | held · found the one real defect (fixed, re-run clean) |
The live transaction
The loop was proven with money. A physical bench unit, a single-board computer driving a real lock behind a small touchscreen, rang up a live $1.99 purchase by phone wallet against production infrastructure on July 9, 2026: charged on the practice’s own merchant account and receipted with no personal data, then refunded by hand from the processor’s dashboard. The refund exposed a gap the program recorded rather than closed: nothing ingests a dashboard-initiated refund, so the platform’s own ledger still reads the sale as succeeded.3








The edge experiment
A parallel spike asked whether store intelligence could live in the store. On a $250-class edge computer with 8 GB of memory, a 3-billion-parameter language model and a speech-to-text model run co-resident; voice commands in the common case complete end to end in about 2.6 seconds, under the program’s 4-second bar.4 Two software levers did the work: a deterministic fast path that skips the model entirely for unambiguous commands, and grammar-constrained decoding against an indexed stock list, which cut the model’s proposal latency from 8.8 to 2.9 seconds.4 The edge device never holds payment authority; the cloud stays the ledger of record.

The platform, the money state machines, the chaos suites, and the edge pattern are assets of the practice, independent of any particular corner.
Notes
- Counts audited at the program’s close-out commit, 2026-07-14: commits, route handlers, tables with row-level security, migrations, and regression suites counted directly from the repository tree and git history.
- Chaos suites: 23 checks across five local concurrency scenarios; 48 checks across fourteen adversarial scenarios against live test-mode payment rails, all fourteen held, one defect found (cross-transaction idempotency-key leak), fixed and re-verified, June 2026.
- Live-mode verification, 2026-07-09: $1.99 wallet purchase on the bench unit against production, charged and subsequently refunded on the practice’s own merchant account.
- Edge spike, June 3–9, 2026, on an 8 GB Jetson-class single-board computer: 3B-parameter instruct model plus whisper-class speech-to-text co-resident; English end-to-end voice ~2.6 s, Mandarin ~3.7 s, Tamil ~5.9 s (the documented miss); grammar-constrained decode 8.8 s → 2.9 s.