A food hall is not one business
Seven kitchens under one roof share a landlord, a card machine policy and a set of opening hours. They do not share a receipt policy, a manager PIN, or a view about buzzers — and a POS that assumes they do will surprise somebody.
We went to set one kitchen's till to stop printing paper receipts, and found we could not say it. The setting existed at two levels — the platform's and the hall's — and that kitchen shares its hall with six others. The only row available to write was the hall's, and the hall's row is all seven of them.
Two layers is the natural mistake
Most systems that grow into multi-tenancy end up with exactly this shape, and for a good reason at each step. You start with one venue, so settings are global. You add a second hall and discover the first hall's receipt footer is printing on the second hall's paper, so you add a hall layer. That fixes the bug in front of you, and it is genuinely the right fix — halls do need their own answers.
What it misses is that the hall was never the smallest unit. A food hall is several separate businesses sharing a roof, a bin store and a card machine policy. They have different customers, different kitchens and different views about whether a receipt should print. The tenant, not the building, is the thing that has a settings screen.
Defaults down, overrides up
So there are three layers now: the platform's answer, then the hall's, then the vendor's. The hall sets the default for its kitchens — which is the useful thing a hall operator actually wants, one place to say "we all use buzzers" — and any vendor can override it for themselves. A vendor that has decided nothing resolves exactly as it did before, so adding the layer changed nobody's behaviour on the day it shipped.
An empty answer is a decision at every level, not an absence. That sounds like a detail until you try to let a vendor turn off something their hall turned on: if blank means "inherit", then "off" becomes unsayable and the vendor is stuck with the hall's choice forever.
The quieter bug underneath
The same change fixed something we had not gone looking for. A till saving its own register settings was writing them to its hall — so a vendor flipping a switch on their own counter was reconfiguring six neighbours who would never know why their screen changed. It now writes to its own venue, and the settings screen says whose settings they are, by name, at the top.
If you run a hall, that is the question worth asking whoever is selling you a POS: when one of my vendors changes something on their till, what exactly did they just change?