The safety net was on the whole time.

Neeos keeps everyone's data in one database. To make sure one person's information can never show up in another person's account, even if there's a bug in our code, the database itself has a rule that filters every request down to the person asking. Think of it as a second lock behind the front door.

The scare

On August 14th I tested that lock from my laptop and it seemed not to be working at all. Every test I ran said the same thing: the rule is installed, and it doesn't filter anything. I measured it again and got the same answer. By that evening I had written it into three documents as a known problem.

What was actually wrong

Nothing, except my test. My laptop connects to the database using a different login than the live app does. The login on my laptop is one the filter deliberately doesn't apply to, because it exists for maintenance. The live app uses a different login, and that one was being filtered the whole time. I had run a careful, repeatable test, and every time it was careful and repeatable about the wrong thing.

What settled it was one question to the database: who is connected right now, and as what? That showed the live app, using its own login, with the filter doing its job. It took a few seconds, and I should have asked it on day one.

The close call

Before we knew that, there was a plan on the table to reset the password on the login the real app uses, as part of "fixing" the problem. That script crashed on a typo before it could run. If it hadn't, we would have knocked the live app offline while trying to repair something that wasn't broken. I'll take that kind of luck, but I'd rather not rely on it.

The lesson I wrote down: when you measure something, first prove you're measuring the real thing. A careful measurement of the wrong subject is worse than a sloppy one, because you believe it.

Written October 21, 2026 from the build log, and dated to when this happened.