Help · Hearths
Home-proximity checks — when and how they fire.
Proximity checks against a Hearth address are event-triggered, never background, and never continuous. This article documents every scenario in which a check can fire.
Home-proximity checks against a Hearth address are event-triggered, never background, and never continuous — a check fires only when a cell member explicitly taps something that needs the answer. That includes a which-house-tonight prompt during a custody-schedule transition, a kid starting an Important Date check-in, a sitter session opening with a Hearth scope, or an after-school check-in the kid taps. There's never a timer or a background check.
When a check fires, we ask the OS for a coarse-only (approximate) location reading, your device computes the distance to the Hearth's stored approximate location, and we record only a distance bucket — "home," "near," or "far." The raw coordinates are discarded within the same request, so the precise position never persists. Bucket entries age out automatically on a per-region schedule, and clearing the address removes them within minutes.
Only on explicit cell actions
A proximity check fires only when a cell member explicitly taps something that needs the answer. That includes: a which-house-tonight prompt during a custody-schedule transition, a kid initiating an Important Date check-in, a sitter session opening with a Hearth scope, or an after-school check-in the kid taps themselves. We never check proximity in the background, never on a timer, and never without a user tap initiating it.
Coarse-only location permission
When a check fires, we ask the OS for a coarse-only location reading — the OS-level permission you grant is for approximate location, not precise. Your device computes the distance to the Hearth's stored approximate location, and we record only the distance bucket (e.g. "home", "near", "far"). The raw coordinates are discarded within the same request.
Distance buckets, not raw position
What lands on the cell timeline is the distance bucket — never the kid's actual position. "Home" means within a small radius of the Hearth, "near" means within walking distance, "far" means elsewhere. Anyone reading the timeline (including us, if compelled by court order) can only see the bucket; the precise position never persisted.
Retention follows your region
Distance-bucket entries age out automatically: US / Australia / RoW after 30 days; Brazil after 14 days; Canada / Quebec / EEA / UK after 7 days; California after 14 days. The retention matches Emergency check-in geolocation — same windows, same per-region rules.
Clearing or revoking
Clearing the Hearth's address removes both the stored approximate location and any historical distance-bucket entries within minutes. Revoking the OS-level coarse-location permission stops new checks from working; the existing distance-bucket history then ages out on its own per the retention table above.
Frequently asked questions
Does ConKarma track my kid's location in the background?
No. Proximity checks are event-triggered only — they fire when a cell member explicitly taps something that needs the answer, like a which-house-tonight prompt or an after-school check-in. We never check proximity in the background, on a timer, or without a user tap.
What location data actually gets saved?
Only a distance bucket — "home," "near," or "far" — lands on the cell timeline, never the actual position. The check uses a coarse-only OS reading, your device computes the distance, and the raw coordinates are discarded within the same request.
How long are proximity entries kept?
Distance-bucket entries age out automatically by region: 30 days for US, Australia, and Rest of World; 14 days for Brazil and California; and 7 days for Canada, Quebec, EEA, and the UK. These windows match the Emergency check-in geolocation rules.
How do I stop proximity checks entirely?
Clearing the Hearth's address removes both the stored approximate location and any historical distance-bucket entries within minutes. Revoking the OS-level coarse-location permission stops new checks from working, and any existing history then ages out on its own per the retention table.