Your store is not stored with anyone else's
Every restaurant on the Hub gets its own database, its own keys and its own web address. Not one shared system with a filter separating customers.
That means there is no screen, no report and no export anywhere in the software that can read another store's records, because the records are not in the same place to begin with.
Before anyone new is given access to support your Hub, you are told their name first.
People see what their job needs
Everyone is placed in one of three levels, and the level decides which tools open.
| Level | What opens |
|---|---|
| Directors | Everything, including financials, the cash audit and personnel records |
| Shift leaders | The tools for running a shift. No financials, no pay, no personnel files |
| Team members | Their own information only. Nothing about anyone else, nothing about the business |
This is checked on the server every time a page is requested, not hidden in the interface. A link forwarded to the wrong person does not open for them.
Signing in, and leaving
- Each person signs in as themselves. There is no shared password
- Sessions expire on their own
- When someone is marked terminated, access stops on their next tap. Every request re-checks it. They do not stay in until something expires
- Changes to who is in HR, who gets notified, and who is signed out need more than a valid login. They need HR authority on top of it
Documents are not left on an open link
Signed paperwork, HR files and photographs are not sitting behind a web address that works for anyone holding it.
- Opening a document creates a pass for that one file, which expires shortly after
- That pass is separate from your sign-in, so one never becomes the other
- The address bar shows your own Hub address. Where the file is actually stored is never exposed, so nothing useful is left behind in the history of a shared tablet
What the public part of the system can do
Like every web application, the Hub sends a public identifier to the browser so pages can load. What matters is what that identifier is permitted to do.
- It cannot write anything. Nothing can be created, changed or deleted with it. Every write goes through the server
- PINs, evaluations, pay, personnel information and the roster are refused at the database itself
- Usage records and the HR store are closed to it entirely
The Hub tests its own protections every morning using the same public identifier an outsider would have. It does a control read first, so a test that failed to run cannot be mistaken for a clean result, and it reports records that hold no data yet rather than counting an empty answer as proof.
What leaves the system, and where it goes
Four outside services are sent anything about your store. This was checked by reading every outbound connection in the software rather than from documentation.
- Slack, for notifications and alerts, if your store uses it
- Resend, for email such as documents to sign and safety reports
- Anthropic, which writes your morning operations digest and translates training material into Spanish
- Google Sheets, which reads your weekly schedule
The same check found two more addresses the browser reaches, and neither is sent a figure, a name or a record: Google Fonts, which supplies the typefaces the pages are set in, and YouTube, which plays the training videos. They are named here so that finding them later does not raise a question this page should already have answered.
The digest is written by an AI service. It receives the day's figures against their goals, your open items, and the first names of whoever ran the best shift. It does not receive pay, personnel records, guest data or anything about individuals beyond that. It never writes to your records.
The Hub does not need it to run. If you would rather your store's data did not go to an AI service, say so and it stays off for you.
If something breaks
- Records and uploaded files are copied automatically to storage separate from the live database
- Every version that has ever gone live is kept. A bad change is rolled back in about a minute and it does not touch any data
How changes reach your restaurant
- Changes reach production only by merging to the main branch, which builds and promotes itself automatically. Every change goes through a pull request and automated checks. Only the owner can push directly, and GitHub records it when he does
- Automated tests run on every change, and a failing test blocks it
- Software libraries are installed from an exact locked list, so a tampered package cannot be pulled in
- Records are never edited by hand to correct a number. If a figure is wrong, the software that produced it is wrong, and that is what gets fixed
- A store can ask for updates to reach it only after close. The software has a closed-hours hold for exactly that, with a way through for an emergency fix