S6 — the AI till key: a short hint from the customer's own AI model
A cashier presses AI tip on a sale, and a short hint comes back in the till's own sheet; then the key's record in Desk.
A remote till key. The till calls this small service during a sale; the service builds a prompt from the sale's item codes, quantities and the store name, asks a provider the customer configures, and answers a message only. It is for a developer who wants to add a key to the till that is answered by their own service — here, a hint from an AI model the customer chooses and pays for. The recipe is recipes/ai_till_key.md.
When to use it: the cashier needs an answer, during the sale, that only your service can give.
What it looks like
The hint comes from the sample's stand-in AI service (no real AI model), and it names the sample's own test item.
| Step | Frame | Screenshot |
|---|---|---|
| 1. A sale on the till, with the AI tip key among the store's keys | the till, 1440 wide |  |
| 2. Pressed: the hint, in the till's own sheet (the till draws it; the service sends only words) | the till |  |
| 3. The key's record in Desk: enabled, message only, the partner's HTTPS address (cut above the signing secret) | Desk |  |
The files
| File | What |
|---|---|
core.py |
the pure core: SENT_FIELDS (the one list of what is sent), consent_text(), build_prompt(), message_from() |
providers.py |
stub (no network, no account) and chat (any chat-completions service the customer runs or pays for) |
service.py |
the HTTP service (standard library): signature check, size cap, one route POST /point/ai_tip, a log with no secret and no prompt |
stub_provider.py |
a local stand-in AI service for the sample and its tests (markers make it slow or failing) |
| — | start the service and the stub provider on your server, under your own process manager |
tests/ |
test_core.py, test_service.py (on a laptop, no account needed) |
Run it
python3 -m unittest discover -s samples/s6_ai_till_key/tests -v
What is refused, and why
The service refuses a call whose signature does not check, and a call larger than its size cap: only the shop may ask it, and only for a small answer. It sends the AI provider only what SENT_FIELDS lists. Its log keeps no secret and no prompt.
Technical notes
The walk
The GIF: a cashier presses AI tip on a sale; the till's server calls this service over HTTPS, and the hint comes back in the till's own sheet. Then the key's record in Desk (our bench run saved it, consent ticked, as a System Manager does there). Frames: the till (/pos?frame=terminal, 1440 wide), then Desk. Walked on our test bench on 2026-10-07, iVendNext POS app at 8dc36aab8. Built from the same screens as the stills below; every frame is cut above the record's signing secret.
The stills: walked in a real browser on our test bench, 2026-10-07, iVendNext POS app at 8dc36aab8: the first press of this key from a real till through the released Retail Remote App Key (the till's server called the service over HTTPS; recipes/ai_till_key.md, What was proven where). The cashier is the bench's Thabo Nkosi, the customer Naledi Khumalo; the hint is the stub provider's (no real AI model), and it names the sample's own test item.
The tests and the ports
Our test bench runs the service and the stub provider on ports 8126 and 8127. Beside the laptop tests (test_core.py, test_service.py, no account), our test bench has its own run, with the till's real validator; it is not in the kit.
Why this way (R6)
Pure core + a tiny service, provider behind one function (picked: ~240 lines in all; a developer reads it unaided; the same shape as S1) · a provider SDK (rejected: ties the sample to one vendor and adds an install) · the model call inside the shop as a hosted key (rejected: partner Python in the tenant, and no deadline on the call).