The retail experiment closed. The platform that ran it is live.

Corner’s venue died on the evidence, and the record says so in full. The software and hardware built to run it did not die. What survives is a production payments and inventory system with a 71-check adversarial record, a physical checkout unit that charged and refunded a live dollar on the practice’s own merchant rails, and an on-device AI stack validated on a $250-class edge computer. This page is the account of what runs today, what is designed and waiting, and how small the gap to a working till actually is.

The checkout unit is a single-board computer driving a small touchscreen, assembled on a printed stand, with the store’s lock circuit hanging off its header pins. It is the machine that rang the program’s live dollar. Every photograph here is the practice’s own hardware, photographed as it sits.

Four ways to move money, all shipped: 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. Underneath all four, one posture: the network is unreliable and event delivery is optional. Every money mutation takes a mandatory idempotency key through a reserve-then-complete envelope. Every processor event is deduplicated by identity. A reconciliation job converges any stuck payment or refund against the processor’s truth, so a missed event is a latency problem and never a correctness problem.

That posture was attacked on purpose before any launch: oversell races, idempotency storms, duplicate-event floods, out-of-order refunds, decline storms. Nineteen scenarios, 71 checks, one real defect found, fixed, and re-run clean. Chapter 06 carries the full destruction record.

And it is not a test-mode story. On July 9, 2026 the bench unit rang a live $1.99 purchase by phone wallet against production infrastructure, with the practice as its own merchant of record, and the charge was refunded through the same system.

The on-device work answers one question: how much of a store’s intelligence can live in the store, on a $250-class computer, with the cloud kept as the ledger of record? The validated answer is most of the routine, at conversational speed.

A 3-billion-parameter language model and a whisper-class speech-to-text model run co-resident in the computer’s 8 GB, with measured headroom. The language model is both router and reasoner. Voice commands about stock, in plain speech, are grounded against the store’s actual inventory before anything is proposed, so the model cannot invent an item that is not on the shelf. Three techniques carry the latency. Decoding is grammar-constrained against an indexed stock list, which cut proposal time from 8.8 seconds to 2.9 on the same run. A deterministic fast path answers the clearest commands in effectively zero time, and after a multilingual alias pass it covers 60 percent of the routine corpus at one hundred percent accuracy. And the cloud is reserved for judgment calls, at about 1.3 seconds of measured round-trip, so escalation stays inside the conversational window too.

End to end, on the box: about 2.6 seconds for English voice, about 3.7 for Mandarin, both under the program’s 4-second bar. Tamil reads remain the documented miss at about 5.9 seconds, though the later alias pass brought clear Tamil commands under the bar. The stack was also hardened adversarially: a 36-utterance attack panel of negations, questions, and trick quantities initially fooled the fast path entirely, and a refuse-token layer killed 35 of the 36 without losing a single legitimate command. All of it is written up, with the misses kept in.

Why it matters for a store: the routine loop never leaves the room. A keeper restocking shelves talks to the counter, in their own language, and the answer arrives before they finish reaching for the next case. No per-utterance cloud cost, no network dependency for the common case, and nothing about the store’s day leaves the store unless a harder question needs the cloud. Payments stay online by design; the edge never holds payment authority.

The honest labels: technically validated on the bench, and deliberately parked as a product direction while the program closed. The toolchain knowledge, the grammar-constrained decoding, the fast-path and refuse-token techniques, and the measured latency envelope are assets of the practice, ready for the next deployment that needs compute to live on site.

From one unit to hundreds

A single working unit is an anecdote. The design question that matters is the second unit, and the hundredth. That pathway is written, and its first stage is running.

Nothing in the third row is exotic. It is the same discipline the money paths already proved, idempotent state machines and reconcile-against-truth, applied to devices instead of payments. The platform’s cloud was built as a control plane from the start; the fleet work is the part a funded team builds while the first corridor of stores comes online.

The acceptance gap

The distance between this platform and a live till is smaller than it looks, and it is measured in parts, not in years. Tap-to-pay already runs end to end against the card processor’s test rails, through a hardware seam built for exactly this: the register does not care whether the reader is a simulator or a certified device, because both sit behind the same interface.

The certified device is the whole remaining gap, and it is a catalogue item. In Canada, the cheapest processor-certified reader that takes both tap and chip insert, with a physical PIN pad for debit, lists at CA$79. It arrives carrying every certification the till needs, hardware security, contact and contactless kernels, the domestic debit network, all inherited from the processor, with nothing left for the integrator to certify. Zero-hardware tap acceptance on a phone exists as well, and in the most tap-saturated card market in the world it covers most transactions on its own; the $79 reader closes the rest, the over-limit taps and the chip-and-PIN debit cards a phone cannot serve. There is no legitimate cheaper path: an uncertified reader module costs less as a board and then costs the certification program back at thirty to one hundred times the hardware price.

So the honest sentence is this one. For about eighty dollars of certified hardware per counter, the platform’s register, inventory, refunds, receipts, and reconciliation are in front of a real shopper, on rails that already survived the destruction pass.

The program now

The thesis that survives the close-out is the one Corner started with: independent corner stores are a distributed retail asset nobody can reproduce, and what they lack is scale economics, not locations. The platform’s working form of that thesis is plain. Software free to the keeper: one register, one ledger, one inventory truth, replenishment of only what sold. Revenue from payment economics rather than software fees, so the keeper’s cost of saying yes is zero. A city corridor has dozens of such stores in walking distance, and the platform was built from day one to hold all of them on one schema.

What was never proved is demand, and the practice does not soften that: no keeper ever onboarded, because the program closed before launch. The record keeps that plainly. What changed since the close-out is the arithmetic of trying: the build is done, the destruction pass is passed, the hardware is on the bench, and the certified gap is a catalogue part. The remaining work is a processor partnership on the payment spread, the fleet build above, and a first corridor of keepers, which is a funding question and a sales question, not an engineering one.

If that question interests you, write to the practice.

The Corner record →
What was built, what killed the venue, and what was never proved, in one account.

Chapter 06 → the platform and the destruction pass
The build record behind this page, with the chaos table and the live-dollar account.