Your data is yours. Here is the standard a pilot must prove.
StoreRounds is pre-production. Its read-only, outbound-only core and server-enforced account boundaries have been exercised with simulated data, but no named POS adapter has passed a real-store production proof and the installer is unsigned. This page separates those prototype controls from the gates still required before a customer pilot.
Last updated 2026-07-15 · storerounds.com/trust
The intended connector would hold one read-only credential to a named set of POS tables and send minimized totals outbound only over TLS, with no inbound ports. That boundary is lab-proven on simulated data, not production-proven for a named POS. Local credential revoke is part of the design; data export and deletion remain manual requests. The separate phone capture path can accept bank and personal details, so no real document should enter it until the pilot controls in The capture path are approved.
The promise: your data is yours
StoreRounds was shaped by the family businesses we come from, so we wrote the data rules the way we would want them written for our own stores. Three promises, in plain words, that shape everything below.
Yours to keep, export, and delete
The numbers belong to the owner. Until self-serve controls ship, email [email protected] for an export or deletion request; the founder will confirm its scope and completion timeline.
Never sold. Not to anyone, not at any price.
We do not sell application data or hand it to data brokers, advertisers, or competitors. A future pilot would carry the same rule for customer data. Our intended business model is paid software, but no subscription or checkout is active today. The Data Processing Addendum that would write this promise into a customer contract is under counsel review, and StoreRounds will not accept payment before the required paper is ready. Until then, this is our public practice for website and application data and the proposed rule for a pilot, not an executed customer contract.
Never trains a shared model without your consent
Application data is not used to train a shared model. No StoreRounds Index is active. A future account-walled chain memory would use only that chain's approved data. If a cross-chain benchmark program is built later In the works, it would remain off by default and require explicit, written, revocable owner consent. It would publish only aggregated, de-identified benchmarks, and we would not call that data "anonymized" unless it met the legal standard. Withdrawing consent would stop future inclusion, though it could not un-compute a benchmark already published; that limit would be disclosed before consent.
What a pilot connector may read, and what must stay in your store
This section describes the intended connector boundary. In the simulated-data prototype, it reads a narrow, named set of sales and store tables and aggregates the day's totals on the store machine before anything is sent. No named POS adapter is generally available. Each pilot adapter must prove this exact boundary against that store's schema and close report before real data moves. The separate phone capture path has a different data profile and is disclosed in The capture path.
Allowed read set for a pilot
- Daily sales header: date, store, totals, transaction count.
- Sales lines, for category and product-level totals.
- Tender split: cash versus card totals, for reconciliation.
- Store codes and names, to label each location.
Outside the allowed read set
- Payment card numbers, PAN, or track data. Never read, at all.
- Any table the read-only user was not explicitly granted.
- Employee records and customer personal data. Not in the connector's allowed read set. A future capture pilot would be the separate path where staff-attributed and bank details could enter, disclosed in full below.
- A full export of your database. Only the aggregated totals go out.
Object names are specific to each point-of-sale and would be disclosed to the owner before a pilot grants access. The validation blueprint and example grant statements are in the on-premise SQL guide, stage 1; they are instructions, not proof that an adapter is production-ready.
| In transit | Pilot requirement: TLS 1.2 or higher, outbound only, with totals aggregated locally before sending. |
| At rest | Pilot requirement: received totals stored encrypted. Payment card data stays outside the allowed read set. |
| Credential storage | Pilot requirement: the DB password remains in the machine's protected credential store, not a plaintext file. |
| Ownership | The data is the owner's. Export and deletion are manual requests until self-serve controls ship. |
| After revoke | Pilot requirement: dropping the read-only credential stops new reads as the owner's own action. |
The connector security model
The current connector package is an unsigned prototype, so Windows may show an unknown-publisher warning. Code signing is a paid-launch gate. In the simulated-data flow, the connector runs on the back-office computer, signs in as a read-only user, aggregates only the named stores, and sends the minimized result over one encrypted connection. No named adapter is generally available, and a pilot will not grant StoreRounds a remote session on the machine.
In the prototype flow, it can
- Run SELECT queries against the named table groups only.
- Open one outbound TLS connection to a single StoreRounds host on 443.
- Aggregate the day's totals locally and send those totals out.
- Report its own health, reconnect after a dropped session, and log both as receipts.
By design, it cannot
- Insert, update, delete, or alter any row or object. Writes are denied at the database.
- Accept any inbound connection. It opens and listens on no port.
- Give anyone at StoreRounds a shell, RDP, or interactive session on the machine.
- Move laterally. It holds one read-only credential to one database and no domain rights.
- Read payment card data or any table it was not granted.
Why the model looks this way
The prototype is built to be the least-privileged thing that could do the job and to aggregate at the edge so less data moves. Its simulated-data flow writes connector events to a local, human-readable log. Offline queue recovery, self-repair, and a live dashboard mirror are not published customer capabilities; each must be verified before it can be promised for a real pilot.
If your IT person or MSP wants the whole model on one printable page, with the exact grants and audit queries, hand them the connector security one-pager. It is written to answer a skeptical admin honestly, and it invites them to stop the install if any line does not match what they see on the network.
The capture path, and the bank and personal data it handles
The prototype also has a tested capture path for photographed deposit slips, check deposits, invoices, shortages, and damaged items. No real non-canary chain uses it today. If enabled for a pilot, those photographs would be a different kind of data than the connector's totals, so the capture path must pass the stricter controls below before any real financial document enters it.
A deposit or check slip can carry a bank account number and a routing number, and an invoice can carry a name. If a pilot enables capture, each upload would be attributed to the signed-in staff member. This path can therefore handle personal and bank information, the exact class of data the connector is designed not to read. No real customer document is in the prototype today; this is the stricter standard required before one is accepted.
Controls proven in the test-data capture path
- Every upload is validated at the server: the real image type is checked by content and magic bytes, size is limited, the image is re-encoded through a hardened library, EXIF and location data are stripped, and SVG is refused.
- Stored encrypted at rest, under keys scoped to your chain, with retention limited to the reconciliation window rather than kept forever.
- Who can open a raw slip is scoped, and account and routing numbers are masked at rest where the reconciliation does not need them in the clear.
- Attribution is by login, never by face or fingerprint. No biometric is read from the photo.
Rules a pilot capture must keep
- It does not auto-confirm a figure. The amount a machine reads from a photo is a draft a person confirms, never a number acted on unseen.
- It does not let text inside a photo instruct the system. Read text is data to reconcile, never a command the software obeys.
- It does not, on its own, prove money reached the bank. A photograph is not a bank statement.
- It does not name a person as at fault. A mismatch is an item to look into, tagged by who snapped it, never an accusation.
Why "VERIFIED" waits for the bank
Matching a slip photo to the register's tender total is not the same as confirming the deposit cleared the bank. A live bank-settlement feed is On the roadmap, not built today. If capture is enabled for a pilot before that feed exists, a slip-only reconciliation must stay provisional and must never be stamped VERIFIED on the strength of a photograph alone.
These rules are the standard the capture path must meet before it ingests a single real financial document, the same discipline the rest of this page keeps: say what is not ready at the same volume as what is. The bank-settlement leg and customer-managed keys are listed in Now vs the roadmap, and any pilot capture store would have to be covered by the Data Processing Addendum described there.
Least privilege, from the proven owner API to the intended role model
The production owner API already enforces tenant and owner boundaries. The broader roles below are the access contract StoreRounds intends to verify before enabling them with real customer data.
- The owner would see every store and the money and would be the only role able to grant money visibility to anyone else.
- A regional or HQ manager would see a defined set of stores, with no financials unless the owner explicitly enables them.
- A store manager would see only their store, complete assigned rounds, and submit receipts.
- Staff and cashiers would get no dashboard and no standing access; a task would reach them as one scoped link.
The intended pilot contract is that every grant, revocation, and sensitive view lands in an audit trail. A task should close with proof the work is done and the number is right, not a log of who was watched. Receipts, never surveillance.
Don't take our word for it. Audit it, and revoke it.
An approved pilot must make each connector boundary directly auditable and locally revocable before real store data moves.
Audit
- Confirm the account is read-only. List every permission the storerounds_ro login holds and expect only SELECT on the named tables, plus explicit write denials. The exact queries for SQL Server and MySQL are in the one-pager, audit section.
- Watch the outbound path. Confirm the connector reaches only the TLS destination disclosed for that pilot, on port 443, at your firewall or endpoint monitor.
- Review the database sessions. The storerounds_ro sessions show up in your normal DB views and run only SELECT. You can log every statement it runs.
- Read the connector log. The prototype writes poll and send events locally. A live owner-dashboard mirror is not a published capability.
Revoke
Immediately, and it is your action, not a support request. Two independent switches, either one enough on its own.
-- SQL Server USE [<YOUR_POS_DB>]; DROP USER [storerounds_ro]; USE [master]; DROP LOGIN [storerounds_ro]; -- MySQL / MariaDB DROP USER 'storerounds_ro'@'10.0.0.%'; FLUSH PRIVILEGES;
Or remove the prototype software from the machine. A dashboard pause control is not a published capability. The pilot must prove that the POS database remains unchanged because the connector credential has no write grant.
You end up holding a receipt, not a promise. That is the whole idea of this company, applied to its own security. Verified by you
Subprocessors
Current infrastructure vendors are Cloudflare (site hosting, cookieless Web Analytics, and prototype object storage), Railway (prototype application hosting), Neon (prototype database hosting), Resend (prototype transactional email), and Kit (pilot-application emails). No payment processor receives data today.
Website visitor or application data touches Cloudflare for hosting and cookieless analytics, and Kit for application emails. The other named vendors support prototype infrastructure and test data. No real non-canary chain is connected. Before a pilot connects a store, this disclosure will state exactly which vendors can touch that pilot's data and where the relevant processing occurs.
| Vendor | Current purpose | Current data scope | Status |
|---|---|---|---|
| Cloudflare | Site hosting, cookieless Web Analytics, and prototype object storage. | Website requests and cookieless traffic measurements; prototype objects contain no real chain data. | Active |
| Railway | Prototype application hosting. | Prototype application traffic and test-store data. | Active |
| Neon | Prototype database hosting. | Prototype account records and test-store data. | Active |
| Resend | Prototype transactional email. | Email delivery metadata for prototype account messages. | Active |
| Kit | Pilot-application email collection and communication. | Email address, required store-count band, and campaign tags when present. | Active |
A signed Data Processing Addendum and notice of customer-data subprocessor changes remain paid-launch gates below.
What exists now, and what is on the roadmap
We would rather tell you what we have not built than let you assume we have. Here is the honest split. We hold ourselves to the same rule the product does: say what is not ready, at the same volume as what is.
- TLS 1.2 or higher in transit, encryption at rest.
- Read-only, least-privilege database access to named tables.
- Outbound-only connection, no inbound ports opened.
- Database credential held in the machine's protected credential store.
- Audit trail on access, plus a local connector event log.
- Local credential revoke. Data export and deletion are manual requests today.
- Server-enforced tenant and owner boundaries on the production owner API, with cross-tenant release tests.
- Signed installer. The current prototype package is unsigned; code signing remains a production launch gate and a paid-launch gate.
- Bank-settlement confirmation for deposit reconciliation. Until it lands, a slip-only reconciliation stays provisional and is never stamped VERIFIED on a photo alone.
- SOC 2 Type II. We are not SOC 2 certified today. It is on the roadmap. We will publish the report date when we hold it, and not one day before.
- Independent third-party penetration test, with a summary published.
- Signed Data Processing Addendum (DPA), covering the connector and the capture store, and email notice of subprocessor changes.
- Single sign-on (SAML / SSO) for larger chains.
- Customer-managed encryption keys.
- A published coordinated-disclosure policy for security researchers.
Plenty of young software will imply a certification it does not hold. We will not. A roadmap item is a roadmap item until it is real and checkable, at which point it moves to the left column with a date. If a page ever claims otherwise, it is wrong, and this line is the one to trust.
Found something? Tell us.
If you or your technician find a security problem, report it. We read these, we respond, and we do not pursue good-faith research that follows responsible disclosure. A formal coordinated-disclosure policy is on the roadmap above; until it is published, this address reaches a human.
For a store owner's routine questions, start with the IT one-pager or the on-premise SQL validation blueprint. For an export or deletion request, email [email protected]; self-serve data controls are not live.