Reality IntegrityAll toolsReality Labels

Privacy Pledge

Plain-language commitments — not legal boilerplate — for every tool we ship. These are structural constraints, not policies. They are built into the architecture.

Commitments

What we commit to

01

No content inspection

We analyze patterns — time, frequency, duration, app focus. We do not read the content of your messages, pages, or browsing history. Ever.

02

No user data exfiltration

Nothing leaves your device without an explicit action on your part. Manual export is always available. No background uploads.

03

No default cloud

All processing runs locally. Cloud is opt-in and scoped. If a future feature requires a network call, it will be explicitly labeled and off by default.

04

No telemetry or analytics SDKs

We do not load behavioral telemetry, usage analytics, or third-party tracking SDKs in any RR tool. This is not a policy — it is an architectural constraint.

05

No required accounts

Identity is optional. Every RR tool works without a login. If an account ever becomes available, it will be for user-initiated sync only.

06

Optional signed recipe updates only

You may download new recipe packs to update the rules engine. During this process, nothing is uploaded. The download is signed and verified locally.

07

User-controlled retention

You control what is stored and for how long. Clear and export are always available in settings. We do not retain data after you clear it.

08

Signed updates only

Recipe packs are signed with an Ed25519 key. The engine verifies the signature before applying any update. Invalid signatures are rejected silently — the previous version remains active.

Anti-goals

What we refuse to build

These are not missing features. They are deliberate omissions.

  • Monitoring tools that report your usage to third parties
  • Accountability-partner features that share data without explicit per-share consent
  • Streak or purity metrics framing restraint as moral achievement
  • Shame-based interventions or failure framing
  • Surveillance features disguised as wellness
  • Any feature that uploads behavioral data to a cloud service by default

Rationale

Why local-first is a structural commitment

These constraints are not privacy-policy boilerplate. They reflect a core thesis: the problem with digital environments is too much optimization pressure — too much measurement, too much feedback, too much behavioral engineering in the name of “engagement.”

Adding more monitoring infrastructure — even well-intentioned — recreates the same Pressure Field we are trying to help users navigate. A wellness tool that uploads your usage data is structurally identical to the platforms it claims to counteract.

Local-first is how we stay on the right side of that line. It is not a limitation. It is the design.

You can inspect the code

Reality Labels will be open source. Recipe packs are open-format JSON — you can read every rule before it runs. The signing key is published. We will publish a transparency report annually.