Ask a software company what their product doesn’t do, and two kinds of answer come back. The common one is fog: “security is our top priority,” “we take privacy seriously,” a paragraph that could be swapped between any two companies on earth without anyone noticing. The rare one is a list.
This post is the list — ours, current as of this writing, seven items long. But it’s also an argument about why the list is the answer worth wanting, from us or from anyone. Because there’s a paradox buried in vendor candor, easy to feel and rarely said out loud: the companies with the least to hide are the ones who tell you exactly what’s missing, and reassuring adjectives are what’s left to say when there’s no list to show — the vagueness is the information. “Nothing to hide” that arrives without a list is a claim. A list is evidence.
Why a flaw list beats a promise
The mechanism is simple: vague reassurance is unfalsifiable, and specific disclosure isn’t. “We take privacy seriously” can’t be checked, so it can’t be caught — which is precisely what makes it cheap to say. “Your data export doesn’t include your audit history” can be checked, dated, and held against us later. Publishing it costs something real: it hands every skeptical reader a stick to measure us with, and it forfeits the option of quietly never fixing it.
That cost is the point. Talk is cheap exactly when it can’t be falsified, and a company that voluntarily makes its claims falsifiable is offering the one form of reassurance that can’t be counterfeited safely: specifics. Anyone can copy this strategy. Few will, because the first draft of an honest gap list has to survive a meeting with whoever runs marketing. That’s why it works as a signal — and why, when you meet one in the wild, it deserves more of your trust than a wall of adjectives, not less.
One more reason, less strategic: you’re deciding what to put in this product. Journals, goals, the things you tell a coach. You can only size that decision correctly if you know what the machinery doesn’t do. A gap we publish is a decision we’ve handed back to you.
The list, current as of this writing
Seven items. Each one is stated plainly, with why telling you serves you — because a gap list you can’t use is just confession.
Your data export doesn’t cover everything. Export gives you your profile, goals, journal, coach sessions, and feedback — and the trust page says outright that it doesn’t yet cover every feature area. Among the omissions: your audit history and your consent-acceptance records. Why you should know: we’ve argued that easy leaving is a feature, so you deserve to know which parts of leaving are still heavy.
You can’t view your own audit trail. Every read of shared data writes an audit row, but there’s no self-serve screen where you can inspect your own trail — today the log serves internal accountability, not your direct inspection. Why it matters: until that closes, your consent is witnessed, and you’re trusting us to be the ones reading the witness. Better to extend that trust knowingly than to assume a feature that isn’t there.
Redaction is best-effort. Before your words reach an AI model, identifying details are filtered — and the trust page says, verbatim, “No filter is perfect.” Every AI data request is audited, but a perfect-redaction claim would be a lie in any product, ours included. Knowing the filter is fallible is what lets you decide what belongs in a journal entry in the first place.
Provider credentials are self-listed, not verified. The directory says it on the page: “Listed, not verified.” Today we verify no one’s credentials — every unverified profile says so on its face — and until that changes, the diligence is yours. A directory that let you assume otherwise would be borrowing your trust against nothing.
Deletion keeps one de-identified trace. Deleting your account removes it outright — but a de-identified access log remains, per the trust page. If “every trace, gone” is your requirement, you should know we don’t meet it, and why the accountability record is the trace that stays.
Revoking consent controls the future, not the past. Switch off a provider’s access and the system enforces the no from that moment forward. What they already saw, they’ve seen — no system can reach into memory and unsee it for someone. Any product implying otherwise is overpromising.
Tamper evidence has a scope. The audit chain can show that a record was altered or that an entry was deleted from the middle. We don’t claim it catches truncation of the tail. A security property stated bigger than it is would be the most dangerous sentence on the page.
That’s the list. What you won’t find in it is instructions — a gap named at the level of what it means for you, not a diagram of how to lean on it. Candor and blueprints are different genres, and a trustworthy gap list stays in the first one.
Why not just fix them first?
The reasonable objection: if you know about seven gaps, close them, then write the victory post. Publishing a to-do list looks like marketing your own homework.
Three honest answers. The first: fixed-first is unfalsifiable from where you sit — a company that only discloses closed gaps shows you a perfect record by construction, and you can’t know what’s sitting in the drawer. You’d be evaluating the edit, not the product. The second is time: some of these gaps will take a while to close, one never will, and you’re deciding today what to write in a journal, whether to connect a provider, how much to share. A disclosure that arrives after the fix arrives after every decision it should have informed. The third answer is the uncomfortable one: unpublished gaps rot. Inside a company, a limitation nobody external can see slides down the priority list forever, because the cost of not fixing it is invisible. Publishing is how we make our own gaps expensive to ignore. The list isn’t marketing our homework — it’s what keeps the homework assigned.
So the order is deliberate: disclose, then fix, then update the page. It’s slower-looking and worse for us on any given day, which is roughly the test an honest policy should pass.
We’ve been practicing this
None of this is new posture — it’s policy that’s been running in front of you for months. The portability post published what export leaves out back when it argued that leaving should be easy. The audit-log post named its own two gaps in-line, and the consent post carried them forward unprompted. Several items above are repeats, on purpose: a gap disclosed once and never mentioned again is a press release. A gap that shows up every time the relevant feature does is a policy.
The precedent taught us what this post is generalizing. The posts that named their limits are the ones we’d ask to be measured by. The doctrine came after the practice, which is the right order for doctrines.
You’ve been reading under these rules all along
Here’s the part of the list that isn’t about the product. This blog runs on its own published constraints, and if you’ve read much of the series, you’ve been inside them without necessarily noticing.
We make no usage claims — no “users tell us,” no “the pattern we keep seeing” — because the product is pre-launch and there’s nobody yet whose usage could back such a sentence, so any version of it would be fiction. We don’t say “in our experience” either; that frame implies a depth of practice we don’t have yet, so claims stand as argument, get owned as opinion, or turn into something you can check yourself. And every study cited anywhere in the series sits in a verified source ledger — where we couldn’t verify a claim at the strength a post needed, the post shipped without it, and said so.
Those rules cost us regularly. They’re why the practices in these posts arrive labeled “our design” instead of dressed in borrowed evidence. But they’re the same move as the product gap list: constraints published in advance are the only kind you can hold us to. The blog isn’t just describing the trust policy. It’s written under it.
The test, aimed at anyone
Everything above compresses into a portable question: what doesn’t it do yet? Ask it of any vendor holding something you care about — the answer sorts into three grades.
A refusal or a subject change is the worst grade, and the most informative. A vague reassurance — “we’re always improving” — is the middle grade: not necessarily hiding something, but telling you the company hasn’t built the muscle of self-description, which predicts how you’ll find out about the gaps that matter. And a specific answer, with nouns in it, is the grade you’re looking for — almost regardless of what the specifics are. A company that can say “export doesn’t cover X yet” has an internal list, keeps it honestly, and lets it out. Those three habits protect you more than most features do.
This pairs with the seven questions we published for evaluating wellness apps — that post asks what a product does with your data. This one adds the meta-question: how does the company behave when the answer is unflattering? Ask us both, first, whenever you like.
What publishing is not
Now the limit of the whole doctrine, stated as plainly as the gaps were. Publishing a gap doesn’t fix it. Every item above is still true after you finish reading, and candor that mistakes itself for repair is just a warmer kind of stalling. Some of these gaps are being worked, some sit behind other priorities, and one — revocation’s forward-only reach — is physics and will be on the list forever. A published list can even become its own comfort, a way of feeling honest instead of shipping. We know. That risk is why this list is dated — and why the durable disclosures also live on the trust page, which is where drift gets fixed before anywhere else. This post is the full list as of its date; the page holds the standing commitments.
So read the promise at its exact size: not that the list will be short, but that it will be honest. Gaps will close and come off. New features will add new ones. What we’re committing to is that the list you can see and the list that’s true stay the same list.
Durable disclosures like these live at /trust — the page this post follows, and the one that gets corrected first when anything above changes. If you ever catch the two disagreeing, believe the trust page, and tell us. Holding us to our own list is the whole reason we published it.
—
This post is part of a series on how to evaluate apps that hold sensitive personal data. The seven gaps above were verified against the live system at the time of writing, and the blog follows the privacy page: the trust page carries standing disclosures like these and is corrected first when anything drifts — this post’s list is complete as of its date, and where a post and that page ever differ, the page is the one to believe. No external studies are cited. Educational content about evaluating software, not legal or security advice.