What a trust page cannot do
Most trust pages are written to close a sale. They collect badges, restate policy in the passive voice, and describe controls in language chosen so that no sentence can be falsified. This one is going to be less useful than that, on purpose.
A page cannot make a claim true
The usual failure is not lying. It is a policy written against the product someone meant to build. A privacy policy that mentions a data retention period for a service with no database is not dishonest exactly, but it is not about anything, and a reader who checks will find that out.
So the rule for this desk is narrow: every statement describes something that is shipped, and anything unconfirmed is published as unconfirmed.
Two rows on the subprocessor list are open right now. We do not know, in a form we are willing to publish, who runs DNS for the domain (V-1) or what the company email vendor is (V-6). Both are trivially guessable. Guessing is exactly what a trust page is for not doing. They stay marked open until the owner of product-facts.md confirms them, which is due 2026-10-03.
A page cannot substitute for an audit
There is no SOC 2 report behind this desk and we are not going to imply one with a graphic. What there is instead:
- A controls list where every row names its method and the date it
was last checked.
- Public repositories, so the code that serves these pages is readable.
- A commit history, so every change to the claims on this desk is a diff with
a date on it.
That is weaker than an audit. It is also checkable by one person in an afternoon, without asking us for anything, which an audit report is not.
A page cannot hide a failure for long
We publish findings, including the one on the record: a host serving a 404 for its Open Graph image after an icon set merged, found during a verification pass on 2026-09-19 and fixed (F-1, T-2). There is a softer finding from the same review that is recorded as noted rather than resolved (F-2), and it is going to stay described that way until it is actually resolved.
A findings list with nothing in it means nobody is looking.
What would have to change
If any of these becomes true, this desk changes before the feature ships:
- A tool starts sending anything to a server of ours. Then there is a data flow
to document, a retention period to state, and a deletion path to build.
- An account exists. Then there is a record with a person attached to it, and
the privacy policy stops being three short sections.
- Someone else gets repository or production access. Then the confidentiality
section of the addendum stops describing one person.
None of those are true today. Saying which ones would change the answer is more useful than another paragraph about how seriously we take security.