The workload is more than transaction count.
High-pressure retail combines actions that a quiet demo tends to separate: scans arrive while the UI changes, cashiers move quickly between tenders, peripherals respond on their own timing, and background synchronization continues while customers wait.
The important questions are about overlapping events. Does a late scan enter the next session? Does a changed cart invalidate an in-flight payment? Does a sync backlog monopolize the process? Does a customer display steal the cashier’s touch mapping? Does the printed receipt belong to the sale the operator selected?
VayaOS development uses these conditions to define acceptance work. This site does not publish an invented transactions-per-second result, uptime percentage, or blanket “certified” label.
The engineering casebook.
CASE / 01Catalog size meets checkout speed
The issue: large catalogs and background work can make local interactions feel slower than their underlying lookup requires.
The response: indexed local barcode queries, bounded search results, quick-menu-only product loading, and synchronization that yields between batches.
The evidence: the performance pilot includes these changes. Synthetic catalog tests support the implementation work; physical multi-register and terminal acceptance remain distinct checks.
Read the local data pathCASE / 02Payment and basket state diverge
The issue: a Windows register sends $10 to PAX, accepts another item, and shows a $15 basket while the terminal approves the original amount.
The requirement: preserve the submitted checkout’s identity, control cart mutation, and reconcile the existing financial response.
The status: current source includes checkout guard mechanisms. The reported sequence is a regression case that must be reproduced and verified on the installed release and actual device.
Read transaction integrityCASE / 03The scanner outlives the screen
The issue: input arriving across logout, PIN entry, or a modal transition can belong to an earlier context.
The response: scanner polling considers session and timing. Withheld scans prompt an operator review instead of silently entering the wrong ticket.
The acceptance case: rapid scans around login / exit cycles and during checkout state changes.
CASE / 04A scale speaks an unexpected dialect
The issue: different scanner/scale families return different frames, and short responses can expose assumptions in a parser.
The response: capture and inspect the actual protocol; validate units and decimal placement against known weights.
The status: a Magellan compatible path has reported VayaOS field success. The short Honeywell weight-response issue remains open; NCR and Zebra VayaOS validation is not presented as complete.
Read integration statusCASE / 05Local lanes, shared records
The issue: a synchronization backlog and duplicate barcode constraints can delay the store’s shared view.
The response: inspect pending work and errors, preserve lane identity, and check recovery after reconnection.
The acceptance case: transactions created during disconnection appear once in the intended store scope after recovery, with totals that match the source records.
CASE / 06A working desktop session is not a finished appliance
The issue: a manually launched customer display can work while the boot sequence still places a window or touch device incorrectly.
The response: validate the display outputs, kiosk startup, separate browser context, and touch mapping as one startup workflow.
The acceptance case: reboot the HP Engage system with its actual cables and peripherals, then verify the whole lane.
Four kinds of evidence. Four different meanings.
| Evidence | What it establishes | What it does not establish |
|---|---|---|
| Source review | An implementation or guard exists in the inspected source | That every path or deployed build behaves correctly |
| Automated / synthetic test | Defined cases passed in a controlled test environment | Physical scale accuracy or a processor’s real response |
| Physical device test | A named hardware / transport combination worked in the tested case | Every model, firmware, cable, or future release |
| Store pilot | Operational feedback under the store’s real workload | Universal throughput, availability, or certification |
A useful issue report identifies the installed build, station, device model, transport, sequence of actions, expected result, and observed result. A fix then has a concrete regression case rather than only a description such as “sometimes hangs.”
Release status should travel with the claim.
This technical overview is grounded in Core Vaya source supplied in September 2026, including application version 2.19.58, build RELEASE-2.19.58-RSUP2, related VayaOS build notes, and reported store / device checks. The named source build is a reference point for this site; it is not a claim that every customer register runs it.
Reported PAX payments on Linux/VayaOS and Windows, SAM4S receipt printing, and the Magellan-compatible scale path are distinguished from new-image installation acceptance and pending device work. A new ISO builder is not the same as a successfully built, booted, and tested image.
Current source notes retain limitations for the Honeywell short-weight response, physical Windows acceptance, and the new remote-support image’s offline enrollment / recovery sequence. Those limitations should remain associated with the relevant release.
Hardware imagery is attributed to HP on the hardware page. POS images are actual development / operating captures from September 2026 and may differ from the current installed layout. None of the diagrams represent live store telemetry.