Safe for a reason nobody wrote down
A line in our menu importer updates a dish without naming the venue. It is completely safe — because of something that happens in a different function, sixty lines away. The most fragile code is the code that is correct by accident of context.
You can paste a spreadsheet of your menu into this product and have it work out what is new, what has changed price, and what is already correct. It shows you the plan, you confirm it, and it writes.
The line that does the writing updates a dish by its number, and says nothing at all about which venue it belongs to.
In a product whose entire job is keeping ten kitchens in one building apart, that is the sort of line that stops you mid-scroll. Two vendors in the same hall both selling a margherita is not unusual; it is Tuesday.
It is safe, and here is the whole reason
The number cannot refer to a dish outside your venue, because of where the number came from. The plan is built by a function that reads the menu with the venue fixed. Nothing outside your venue ever enters the list, so nothing outside your venue can come out of it.
That is a real guarantee. It is also a guarantee held by two functions jointly, with nothing anywhere stating that they depend on each other.
Why that is the dangerous kind of correct
Imagine somebody later decides that the preview should also show near-matches from the whole company, to help with duplicates. A sensible feature. They widen the read. The preview gets better. And the write, sixty lines away, silently becomes capable of repricing another vendor's dish.
Nothing in the widened function mentions the write. Nothing in the write mentions the read. No test failed, because no test knew the two were related. The guarantee was in somebody's head on the day, and heads are not version controlled.
What we did about it, and what we did not
We did not bolt a venue check onto the write. It would look like belt and braces, and in isolation it would be. But a check that is never the thing actually protecting you is a check people stop reading, and this product already has places where an identifier taken from a document the caller owns is correct exactly as it stands.
What was missing was not the clause. It was the statement.
So there is now a test that creates the same dish name in two venues, imports a sheet for one of them, and checks that the other one's price did not move — plus its control, which imports the same sheet for the other venue and checks that it did. Without that second half, the first passes against an importer that writes nothing at all, which is the feature being broken rather than being safe.
The wider version of this
Every operation has rules that hold because of something upstream. The stock count balances because the delivery was booked in before the shift. The rota covers the kitchen because somebody checks holidays before publishing. The takings reconcile because the float is counted at the same point every night.
Those are all real guarantees, and they are all invisible. The way they break is never dramatic: somebody improves the upstream step, in good faith, without knowing that something downstream was leaning on it.
The cheap defence is not more checks. It is writing down, next to the thing that depends, what it depends on — so that the person changing the upstream step is told, at the moment they change it, what else was relying on the old behaviour.