Field notes

Most product docs tell you where the buttons are. This is not that.

These pages collect the internal quirks of how SafeMeet actually works — the deliberate asymmetries, the failure-mode choices, the small oddities that only make sense once you know the reasoning. Nothing here is marketing. Some of it is us admitting trade-offs out loud.

Why publish this? Because SafeMeet's whole pitch is that safety happens before delivery, invisibly. Invisible systems earn trust by being explained, not by being taken on faith.

What's inside

• Moderation quirks — messages are born invisible, outages block rather than leak, and why a truncated answer is treated as a wrong answer.
• The punitive surface — there is exactly one code path that can restrict a user, and everything else is built to stay away from it.
• Architecture quirks — the two halves of the system never call each other, and broken events return "success" on purpose.
• Bots, disclosed — the one boolean that is not allowed to be configurable.
• Little things — Windows killed our emoji flags, and other small stories.

Where it runs is a decision too: SafeMeet ships as a website rather than a store app, and the child safety standard that store policies ask for is published at child safety standards either way.

One honest caveat up front: these notes describe behavior and reasoning, not operational detail. Specific thresholds, providers, and infrastructure are deliberately absent — describing the shape of a safety system is transparency; publishing its dials is a jailbreak manual.