Skip to main content

Help · Updates

What we update + when we have to block an old version.

ConKarma ships updates regularly. This article explains the honest-why posture (we tag every release by category), the rare force-block reservation (and the two-eye gate that governs it), the data-export and cancellation paths that always work, and the per-quarter transparency report on force-block invocations.

ConKarma ships updates regularly and tags every release as security, safety, compliance, or feature, with the full narrative on the changelog rather than vague "bug fixes and improvements." Most updates are a soft prompt — you see a banner next time you open the app and choose when to install — and streaks pause through update windows so a delay isn't punished.

Force-blocking a version is rare and reserved for security, safety, and compliance only, never feature adoption or experiment cohorts; it requires a two-eye gate where two operators sign off into an audit log published in aggregate. Even on a blocked version, data export and account deletion always work, with a direct path offered in the block message. A per-quarter transparency report publishes force-block counts per category — never per-user, never named.

What changes, by category

Every update note carries one of four tags: security, safety, compliance, or feature. The /changelog has the full narrative — not just 'bug fixes and improvements,' but what the change actually does and why. The same tagging drives the per-quarter transparency report at /build-in-public.

Soft-prompt updates

Most updates are a soft prompt: you'll see a banner the next time you open the app, and you choose when to install. Streaks pause through update windows; the daily loop doesn't punish a delay. Your subscription, your data, and your cell continue working on the version you're on.

The rare force-block

Reserved for security, safety, and compliance only — never for feature adoption, never for an experiment cohort. Force-blocking a version requires a two-eye gate: two operators must sign off, with their decisions written to an audit log we publish in aggregate on /build-in-public. The bar is high on purpose.

What you keep when a version is blocked

Data export and account deletion always work, on any version, including a blocked one — your data is never trapped behind an update wall. The block message tells you exactly what's required to continue and offers a direct path to both export and cancellation, so neither is gated by 'update first.'

What we deliberately don't do

No force-block for feature adoption. No force-block for A/B tests or experiment cohorts. No escalating soft-prompt cadence (the prompt asks once per session, never harder). No guilt or shame framing on update copy. No per-user version tracking for marketing. No push notifications for updates. No in-app sideload or store-bypass. The per-quarter B-i-P transparency report publishes the count of force-block invocations per category plus anonymous reason summaries — never per-user, never with names.

Frequently asked questions

Will I be forced to install every update?
When can ConKarma actually block an old version?
If my version gets blocked, can I still get my data out?
How do I know what actually changed in an update?