Claim · evidence · boundary
How to check an app claim: five questions before you trust it
A polished sentence can be accurate, incomplete, outdated, or too broad. Keep the exact words, then ask what the available evidence really supports.
Published 7 August 2026 · 7 minute read · By the Vibbrancy team
This guide is published by the Vibbrancy team, so it is not an independent review of Vibbrancy or any other app. We use the same method on our own public wording and link our current answers below. The method is meant to help you ask narrower questions—not award a score, badge, endorsement, or legal conclusion.
Use only public wording and fictional entries while testing. Do not paste or upload mood, journal, health, diagnosis, treatment, trauma, account, identifying, or third-party data. A synthetic-data check can reveal observable behaviour without exposing a real person's private record.
The short version
- Copy one claim exactly and record where and when you found it.
- Write down what evidence would support that exact wording.
- Check a dated public source and, where safe, run one synthetic-data test.
- State what the evidence shows and what it does not prove.
- Keep a correction route so the note can change when the product or evidence changes.
1. What are the exact words?
Save the complete sentence, page title, public URL, and date checked. Small qualifiers matter. “Core check-ins work offline” is narrower than “the app works offline.” “No account required to begin” is narrower than “anonymous.” Do not quietly replace the original wording with a stronger or weaker paraphrase.
If the claim is inside an app, record the version and platform. Store pages, help pages, privacy policies, and product screens can change at different times. A dated note makes it possible to distinguish an outdated statement from a current one.
2. What evidence would support that wording?
Decide what you would need to observe before looking for a convenient screenshot. A claim about exporting data needs an export attempt and inspection of the resulting file. A claim about using a core feature without an account needs a fresh-install test. A claim about data handling may also require the current privacy policy, store disclosure, and documented architecture; tapping around the interface is not enough.
Match the evidence to the scope. One successful test on one Android version does not prove the same behaviour on every supported device, operating-system version, configuration, or future release.
3. Can you run a small synthetic-data check?
Use a fictional entry such as “score 6 · calm · demo walk,” then perform one observable action. Turn on airplane mode before making a core entry. Export the fictional record and check its fields. Decline an optional permission and see what remains available. Delete the synthetic entry and check the visible result.
Record the setup as carefully as the outcome: app version, platform, device state, account state, permission choices, and the exact steps. Reproducibility is more useful than a vague “worked for me.” Keep screenshots free of notifications, account details, real entries, faces, contact names, or other private material.
4. What does the result not prove?
Every useful note needs a boundary. Making an entry in airplane mode shows that the tested action completed without a connection at that moment. It does not prove that the app never connects later or that no other feature uses a server. Beginning without an account does not by itself prove that no device, store, diagnostic, or network identifiers exist.
A successful export shows what the tested export contained; it does not prove that every internal record is included. A privacy-policy sentence describes a published commitment; it does not independently verify implementation. A short personal observation cannot establish diagnosis, treatment effectiveness, wellbeing improvement, or causation.
5. Where can a correction go?
Add a public contact route or issue link and a “last checked” date. If a reader points out a reproducible mismatch, update the wording and preserve the boundary. The purpose is a more accurate public record, not coverage, praise, or a debate win.
If you contact a developer, disclose your affiliation and ask one narrow question. Share the exact claim, source, steps, and limitation. Do not send private entries, demand an endorsement, or imply that a small check is a complete product or security assessment.
Free worksheet
Review one public claim on one page
The Claim Boundary Card keeps the exact wording, evidence, synthetic check, scope, and correction route together. It has no form, account, upload, or answer submission.
A useful conclusion can stay narrow
“I could reproduce this action under these conditions” is a worthwhile result. So is “the current public source does not answer this question.” You do not need to turn either result into a verdict about the whole app.
Keep the claim, evidence, date, scope, and boundary beside one another. That small discipline makes product language easier to inspect, correct, and trust for the right reasons.