Handsfree

What we hold, what we never hold, and the two risks we would rather you heard from us.

Written for the IT manager who has to approve this before a pilot. Everything below is a property of the code, and the full one-page version — the one with the test file names against each claim, so you can ask us to run them in front of you — is what we send to your security team on request.

Where it sits

headset / handset browser  ──HTTPS+WSS──▶  our backend  ──HTTPS──▶  your Oracle WMS pod
      (mic, scanner)                        (Node.js)              (lgfapi/htmlrf)
                                                 │
                                                 ├─▶ speech-to-text vendor (audio only)
                                                 └─▶ our database (tenants, settings,
                                                      sealed secrets, pick telemetry)

Three things follow from that picture, and they are the three that matter:

Credentials, and how long each one lives

CredentialWhere it livesLifetime
Picker's Oracle username and password Process memory only, keyed by session Their shift, plus a 10-minute grace so a Wi-Fi drop is not a re-login. Never written to disk, never in a log at any level, never in a backup.
Your Oracle service account (entity queries) Our database, sealed with AES-256-GCM under a master key held outside it Until you rotate it. Write-only over the API — it can be replaced, never read back.
Picker session token The device, in memory 12 hours — one shift — and scoped to the pick socket only.
Admin panel session token The browser tab, in memory. Never localStorage, never a cookie 8 hours. A page refresh signs you in again, which we accept as the cost.

A picker's credentials are validated against your pod at login, so a wrong password is refused at the sign-in screen rather than three screens into a task. And disabling an account takes effect within five seconds, not at the next login — an eight-hour token would otherwise outlive a dismissal by most of a working day.

Audio, and what happens to what a picker says

Isolation between customers

Every database query runs inside a transaction that pins the tenant and drops to an unprivileged role, under PostgreSQL row-level security with FORCE on every table. A query that forgets its filter returns nothing; it does not return someone else's rows. Isolation is a property of the database, not of the next developer remembering. Picker identities are namespaced per tenant, so two customers' jsmith are two sessions. Concurrent multi-tenant picking with zero cross-talk is proven end to end by automated tests that run on every change — not asserted in a brochure.

The audit trail

Every administrative change — settings, users, secrets, tenant status, billing — writes a row in the same transaction as the change itself, so there is no window where one happened and the other did not. The application role has no UPDATE and no DELETE on the audit table: the process that writes the trail cannot rewrite it. When we access your tenant to help you, that is a distinct, time-boxed one-hour token, and every row it writes is stamped with our own operator's name — support access is visible to you, not invisible to you.

Network

Two residual risks, stated rather than found

You would find these in a penetration test. We would rather you heard them from us, and both are pinned by tests so they cannot quietly get worse.

Availability, honestly

We promise graceful degradation, not uptime. If voice is unavailable for any reason — our service, the speech vendor, your site's Wi-Fi — your pickers pick with the RF guns exactly as they do today. Nothing we run sits between your warehouse and Oracle for scanning. There is no failure mode of ours that stops a shift; there is only a failure mode that costs you the hands-free advantage until it is fixed. We would rather contract for something true than promise an uptime number we cannot staff.

Current component states, and the incident history when there is one, are on the status page.

Support, without the pretence

We are a small company and we will not pretend otherwise. Business hours, Monday to Friday, with a one-business-day response is the standard plan, and it is what we can staff honestly today. Round-the-clock cover and named response times are an Enterprise line item, priced for what it costs to actually staff rather than included by default and quietly unstaffed. What makes a business-hours model defensible for a warehouse is the paragraph above: you are never blocked on us to keep picking. Security issues reach us directly, and we will confirm receipt the same business day and tell you what we know — including when the answer is "we do not know yet".

Compliance, as it stands today

Ask for the full one-pager. It is one page, has no marketing in it, and names the automated test behind each claim so your team can ask us to run them. Contact: [address — not yet set] — the support address is still being set up, and this page will not invent one.